- Introduzione
- Prerequisiti
- Esempio Host
- Il nostro obiettivo
- Installa BIND sui server DNS
- Configura il server DNS primario
- Configura Bind
- Configura il file locale
- Crea file di zona Forward
- Crea file di zona inversa
- Check BIND Configuration Syntax
- Avvia BIND
- Configura server DNS secondario
- Configura i client DNS
- Client CentOS
- Client Ubuntu
- Prova i client
- Ricerca diretta
- Ricerca Inversa
- Mantenimento dei record DNS
- Aggiunta di host a DNS
- Nameserver Primario
- Secondario
- Configura un nuovo host per utilizzare il tuo DNS
- Rimozione dell’host dal DNS
- Conclusione
Introduzione
Una parte importante della gestione della configurazione e dell’infrastruttura del server include il mantenimento di un modo semplice per cercare le interfacce di rete e gli indirizzi IP per nome, impostando un DNS (Domain Name System) appropriato. L’utilizzo di nomi di dominio completi (FQDN), invece degli indirizzi IP, per specificare gli indirizzi di rete facilita la configurazione di servizi e applicazioni e aumenta la manutenibilità dei file di configurazione. Impostare il proprio DNS per la rete privata è un ottimo modo per migliorare la gestione dei server.
In questo tutorial, andremo oltre come impostare un server DNS interno, utilizzando il software BIND name server (BIND9) su CentOS 7, che può essere utilizzato dai server privati virtuali (VPS) per risolvere i nomi host privati e gli indirizzi IP privati. Ciò fornisce un modo centrale per gestire i nomi host interni e gli indirizzi IP privati, che è indispensabile quando l’ambiente si espande a più di pochi host.
La versione Ubuntu di questo tutorial può essere trovata qui.
Prerequisiti
Per completare questa esercitazione, è necessario il seguente:
- Alcuni server sono in esecuzione nello stesso datacenter, e sono dotate di rete abilitato
- Un nuovo VPS per servire come server DNS Primario, ns1
- Opzionale: Un nuovo VPS per servire come un server DNS Secondario, ns2
- accesso Root per tutti i passaggi 1-4 qui)
Se non si ha familiarità con DNS concetti, si consiglia di leggere almeno le prime tre parti della nostra Introduzione alla Gestione del DNS.
Esempio Host
Per esempio, supponiamo il seguente:
- Abbiamo due VPS esistenti chiamato “host1” e “host2”
- Sia VPS esiste nel nyc3 datacenter
- Entrambi i VPS sono reti private attivate (e sono 10.128.0.0/16 subnet)
- Entrambi i VPS sono in qualche modo legati alla nostra applicazione web che gira su “example.com”
Con questi presupposti, siamo noi a decidere che ha senso utilizzare uno schema di denominazione che usa “nyc3.example.com” per fare riferimento alla nostra subnet privata o di zona. Pertanto, host1 privato con Nome di Dominio completo (FQDN) sarà “host1.nyc3.example.com”. Fare riferimento alla tabella riportata di seguito i dettagli:
Host | Ruolo | nome FQDN Privato | Indirizzo IP Privato |
---|---|---|---|
host1 | Generic Host 1 | host1.nyc3.example.com | 10.128.100.101 |
host2 | Generic Host 2 | host2.nyc3.example.com | 10.128.200.102 |
Nota: la configurazione esistente sarà diversa, ma i nomi di esempio e gli indirizzi IP verranno utilizzati per dimostrare come configurare un server DNS per fornire un DNS interno funzionante. Dovresti essere in grado di adattare facilmente questa configurazione al tuo ambiente sostituendo i nomi host e gli indirizzi IP privati con i tuoi. Non è necessario utilizzare il nome della regione del datacenter nello schema di denominazione, ma lo usiamo qui per indicare che questi host appartengono alla rete privata di un particolare datacenter. Se si utilizzano più datacenter, è possibile impostare un DNS interno all’interno di ciascun datacenter.
Il nostro obiettivo
Alla fine di questo tutorial, avremo un server DNS primario, ns1, e opzionalmente un server DNS secondario, ns2, che servirà come backup.
di seguito è una tabella con esempi di nomi e indirizzi IP:
Host | Ruolo | nome FQDN Privato | Indirizzo IP Privato |
---|---|---|---|
ns1 | Server DNS Primario | ns1.nyc3.example.com | 10.128.10.11 |
ns2 | Server DNS Secondario | ns2.nyc3.example.com | 10.128.20.12 |
si può iniziare con l’installazione del server DNS Primario, ns1.
Installa BIND sui server DNS
Nota: il testo evidenziato in rosso è importante! Sarà spesso usato per indicare qualcosa che deve essere sostituito con le proprie impostazioni o che dovrebbe essere modificato o aggiunto a un file di configurazione. Ad esempio, se vedi qualcosa come host1.nyc3.esempio.com, sostituiscilo con l’FQDN del tuo server. Allo stesso modo, se vedi host1_private_IP, sostituiscilo con l’indirizzo IP privato del tuo server.
Su entrambi i server DNS, ns1 e ns2, installare BIND con yum:
- sudo yum install bind bind-utils
Confermare il prompt inserendoy
.
Ora che BIND è installato, configuriamo il server DNS primario.
Configura il server DNS primario
La configurazione di BIND è composta da più file, inclusi nel file di configurazione principale,named.conf
. Questi nomi di file iniziano con “named” perché è il nome del processo che esegue il BIND. Inizieremo con la configurazione del file di opzioni.
Configura Bind
Il processo di BIND è noto come named. Come tale, molti dei file si riferiscono a ” named “invece di”BIND”.
Su ns1, aprire il filenamed.conf
per la modifica:
- sudo vi /etc/named.conf
Sopra il bloccooptions
esistente, creare un nuovo blocco ACL chiamato “trusted”. Questo è dove definiremo l’elenco dei client da cui consentiremo le query DNS ricorsive (cioè i server che si trovano nello stesso datacenter di ns1). Usando i nostri indirizzi IP privati di esempio, aggiungeremo ns1, ns2, host1 e host2 alla nostra lista di client fidati:
acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};
Ora che abbiamo la nostra lista di client DNS attendibili, vorremo modificare il bloccooptions
. Aggiungi l’indirizzo IP privato di ns1 alla direttivalisten-on port 53
e commenta la rigalisten-on-v6
:
options { listen-on port 53 { 127.0.0.1; 10.128.10.11; };# listen-on-v6 port 53 { ::1; };...
Al di sotto di queste voci, modificare la direttivaallow-transfer
da” none ” all’indirizzo IP privato di ns2. Inoltre, cambia la direttivaallow-query
da “localhost” a “trusted”:
Alla fine del file, aggiungere la seguente riga:
include "/etc/named/named.conf.local";
Ora salvare e uscirenamed.conf
. La configurazione di cui sopra specifica che solo i propri server (quelli “attendibili”) saranno in grado di interrogare il server DNS.
Successivamente, configureremo il file locale, per specificare le nostre zone DNS.
Configura il file locale
Su ns1, apri il filenamed.conf.local
per la modifica:
- sudo vi /etc/named/named.conf.local
Il file dovrebbe essere vuoto. Qui, specificheremo le nostre zone avanti e indietro.
Aggiungi la zona in avanti con le seguenti righe (sostituisci il nome della zona con il tuo):
zone "nyc3.example.com" { type master; file "/etc/named/zones/db.nyc3.example.com"; # zone file path};
Supponendo che la nostra sottorete privata sia 10.128.0.0/16, aggiungi la zona inversa con le seguenti righe (nota che il nostro nome della zona inversa inizia con “128.10 “che è l’inversione dell’ottetto di”10.128”):
zone "128.10.in-addr.arpa" { type master; file "/etc/named/zones/db.10.128"; # 10.128.0.0/16 subnet };
Se i server si estendono su più sottoreti private ma si trovano nello stesso datacenter, assicurarsi di specificare una zona e un file di zona aggiuntivi per ogni sottorete distinta. Quando hai finito di aggiungere tutte le zone desiderate, salva ed esci dal filenamed.conf.local
.
Ora che le nostre zone sono specificate in BIND, dobbiamo creare i corrispondenti file di zona in avanti e indietro.
Crea file di zona Forward
Il file di zona forward è dove definiamo i record DNS per le ricerche DNS forward. Cioè, quando il DNS riceve una query nome, “host1.nyc3.example.com” ad esempio, cercherà nel file di zona in avanti per risolvere l’indirizzo IP privato corrispondente di host1.
Creiamo la directory in cui risiederanno i nostri file di zona. Secondo il nostro nome.conf.configurazione locale, quella posizione dovrebbe essere /etc/named/zones
:
- sudo chmod 755 /etc/named
- sudo mkdir /etc/named/zones
Ora modifichiamo il nostro file di zona in avanti:
- sudo vi /etc/named/zones/db.nyc3.example.com
Per prima cosa, vorrai aggiungere il record SOA. Sostituire l’FQDN ns1 evidenziato con il proprio FQDN, quindi sostituire il secondo “nyc3.example.com” con il tuo dominio. Ogni volta che si modifica un file di zona, è necessario incrementare il valore seriale prima di riavviare il processo named
–lo incrementeremo a “3”. Dovrebbe essere simile a questo:
Successivamente, aggiungi i tuoi record nameserver con le seguenti righe (sostituisci i nomi con i tuoi). Si noti che la seconda colonna specifica che si tratta di record “NS”:
; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.
Quindi aggiungere i record A per gli host che appartengono a questa zona. Questo include qualsiasi server il cui nome vogliamo terminare con”. nyc3.example.com ” (sostituire i nomi e gli indirizzi IP privati). Usando i nostri nomi di esempio e gli indirizzi IP privati, aggiungeremo un record per ns1, ns2, host1 e host2 in questo modo:
Salvare ed uscire dal filedb.nyc3.example.com
.
Il nostro file di zona forward di esempio finale è simile al seguente:
Ora passiamo ai file di zona inversa.
Crea file di zona inversa
I file di zona inversa sono dove definiamo i record DNS PTR per le ricerche DNS inverse. Cioè, quando il DNS riceve una query per indirizzo IP, “10.128.100.101”, ad esempio, cercherà nei file di zona inversa per risolvere il FQDN corrispondente, “host1.nyc3.example.com ” in questo caso.
Su ns1, per ogni zona inversa specificata nel filenamed.conf.local
, creare un file di zona inversa.
Modificare il file di zona inversa che corrisponde alle zone inverse definite innamed.conf.local
:
- sudo vi /etc/named/zones/db.10.128
Nello stesso modo del file di zona diretta, sostituire l’FQDN ns1 evidenziato con il proprio FQDN, quindi sostituire il secondo FQDN “nyc3.example.com” con il tuo dominio. Ogni volta che si modifica un file di zona, è necessario incrementare il valore seriale prima di riavviare il processo named
–lo incrementeremo a “3”. Dovrebbe essere simile a questo:
Successivamente, aggiungi i tuoi record nameserver con le seguenti righe (sostituisci i nomi con i tuoi). Si noti che la seconda colonna specifica che questi sono record “NS”:
; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.
Quindi aggiungerePTR
record per tutti i server i cui indirizzi IP si trovano nella sottorete del file di zona che si sta modificando. Nel nostro esempio, questo include tutti i nostri host perché sono tutti sulla sottorete 10.128.0.0 / 16. Si noti che la prima colonna è costituita dagli ultimi due ottetti degli indirizzi IP privati dei server in ordine inverso. Assicurati di sostituire nomi e indirizzi IP privati per abbinare i tuoi server:
Salvare ed uscire dal file di zona inversa (ripetere questa sezione se è necessario aggiungere altri file di zona inversa).
Il nostro file di zona inversa di esempio finale è simile al seguente:
Check BIND Configuration Syntax
Esegui il seguente comando per controllare la sintassi dei file named.conf*
:
- sudo named-checkconf
Se i file di configurazione con nome non presentano errori di sintassi, tornerai al prompt della shell e non vedrai messaggi di errore. In caso di problemi con i file di configurazione, rivedere il messaggio di errore e la sezione Configura server DNS primario, quindi riprovare named-checkconf
.
Il comando named-checkzone
può essere utilizzato per verificare la correttezza dei file di zona. Il suo primo argomento specifica un nome di zona e il secondo argomento specifica il file di zona corrispondente, entrambi definiti in named.conf.local
.
Ad esempio, per controllare il “nyc3.example.com” forward zone configuration, eseguire il seguente comando (modificare i nomi per abbinare la vostra zona in avanti e il file):
- sudo named-checkzone nyc3.example.com /etc/named/zones/db.nyc3.example.com
E per controllare il “128.10.in-addr.arpa” configurazione della zona inversa, eseguire il seguente comando (modificare i numeri in modo che corrispondano alla zona inversa e al file):
- sudo named-checkzone 128.10.in-addr.arpa /etc/named/zones/db.10.128
Quando tutti i file di configurazione e di zona non presentano errori, è necessario essere pronti per riavviare il servizio BIND.
Avvia BIND
Avvia BIND:
- sudo systemctl start named
Ora vorrai abilitarlo, quindi inizierà all’avvio:
- sudo systemctl enable named
Il tuo server DNS primario è ora configurato e pronto a rispondere alle query DNS. Passiamo alla creazione del server DNS secondario.
Configura server DNS secondario
Nella maggior parte degli ambienti, è una buona idea impostare un server DNS secondario che risponderà alle richieste se il primario non è disponibile. Fortunatamente, il server DNS secondario è molto più facile da configurare.
Su ns2, modificare il filenamed.conf
:
- sudo vi /etc/named.conf
Nota: se si preferisce ignorare queste istruzioni, è possibile copiare il filenamed.conf
di ns1 e modificarlo per ascoltare l’indirizzo IP privato di ns2 e non consentire i trasferimenti.
Sopra il bloccooptions
esistente, creare un nuovo blocco ACL chiamato “trusted”. Qui è dove definiremo l’elenco dei client da cui consentiremo query DNS ricorsive (cioè i tuoi server che si trovano nello stesso datacenter di ns1). Usando i nostri indirizzi IP privati di esempio, aggiungeremo ns1, ns2, host1 e host2 alla nostra lista di client fidati:
acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};
Ora che abbiamo la nostra lista di client DNS attendibili, vorremo modificare il bloccooptions
. Aggiungi l’indirizzo IP privato di ns1 alla direttivalisten-on port 53
e commenta la rigalisten-on-v6
:
options { listen-on port 53 { 127.0.0.1; 10.128.20.12; };# listen-on-v6 port 53 { ::1; };...
Modificaallow-query
direttiva da “localhost” a “trusted”:
...options {... allow-query { trusted; }; # allows queries from "trusted" clients...
Alla fine del file, aggiungere la seguente riga:
include "/etc/named/named.conf.local";
Ora salvare e uscirenamed.conf
. La configurazione di cui sopra specifica che solo i propri server (quelli “attendibili”) saranno in grado di interrogare il server DNS.
Successivamente, configureremo il file locale, per specificare le nostre zone DNS.
Salva ed esci da named.conf
.
Ora modificare ilnamed.conf.local
file:
- sudo chmod 755 /etc/named
- sudo vi /etc/named/named.conf.local
Definire le zone slave che corrispondono alle zone master sul server DNS primario. Si noti che il tipo è “slave”, il file non contiene un percorso e c’è una direttiva masters
che dovrebbe essere impostata sull’IP privato del server DNS primario. Se hai definito più zone inverse nel server DNS primario, assicurati di aggiungerle tutte qui:
Ora salvare e uscirenamed.conf.local
.
Eseguire il seguente comando per verificare la validità del file di configurazione:
- sudo named-checkconf
una Volta che si verifica, start BIND:
- sudo systemctl start named
Consentire di ASSOCIARE ad avviare il boot:
sudo systemctl enable named
Ora avete server DNS primario e secondario per il privato il nome di rete e la risoluzione dell’indirizzo IP. Ora è necessario configurare i server per utilizzare i server DNS privati.
Configura i client DNS
Prima che tutti i tuoi server nell’ACL “attendibile” possano interrogare i tuoi server DNS, devi configurare ciascuno di essi per utilizzare ns1 e ns2 come server dei nomi. Questo processo varia a seconda del sistema operativo, ma per la maggior parte delle distribuzioni Linux comporta l’aggiunta dei name server al file/etc/resolv.conf
.
Client CentOS
Su CentOS, RedHat e Fedora Linux VPS, è sufficiente modificare il fileresolv.conf
:
- sudo vi /etc/resolv.conf
Quindi aggiungi le seguenti righe nella PARTE SUPERIORE del file (sostituisci il tuo dominio privato e gli indirizzi IP privati ns1 e ns2):
search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address
Ora salva ed esci. Il client è ora configurato per utilizzare i server DNS.
Client Ubuntu
Su Ubuntu e Debian Linux VPS, è possibile modificare il file head
, che viene anteposto a resolv.conf
all’avvio:
- sudo vi /etc/resolvconf/resolv.conf.d/head
Aggiungi le seguenti righe al file (sostituisci il tuo dominio privato e gli indirizzi IP privati ns1 e ns2):
search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address
esegui resolvconf
per generare un nuovo resolv.conf
file:
- sudo resolvconf -u
il Tuo client è ora configurato per l’utilizzo di server DNS.
Prova i client
Usanslookup
—incluso nel pacchetto “bind-utils”—per verificare se i tuoi client possono interrogare i tuoi name server. Dovresti essere in grado di farlo su tutti i client che hai configurato e che si trovano nell’ACL “attendibile”.
Ricerca diretta
Per esempio, siamo in grado di eseguire una ricerca diretta per recuperare l’indirizzo IP di host1.nyc3.example.com eseguendo il seguente comando:
- nslookup host1
Query “host1” espande “host1.nyc3.example.com a causa del search
opzione è impostata al tuo sottodominio, e le query DNS tenterà di look che di sottodominio, prima di guardare per l’host altrove. L’output del comando di cui sopra è il seguente:
Output:Server: 10.128.10.11Address: 10.128.10.11#53Name: host1.nyc3.example.comAddress: 10.128.100.101
Ricerca Inversa
Per testare la ricerca inversa, interrogare il server DNS con host1 indirizzo IP privato:
- nslookup 10.128.100.101
Si dovrebbe avere un risultato simile al seguente:
Output:Server: 10.128.10.11Address: 10.128.10.11#5311.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
Se tutti i nomi e gli indirizzi IP risolvere i valori corretti, il che significa che il vostro file di zona sono configurati correttamente. Se si ricevono valori imprevisti, controllare i file di zona sul server DNS primario (ad es. db.nyc3.example.com
e db.10.128
).
Congratulazioni! I server DNS interni sono ora impostati correttamente! Ora ci occuperemo di mantenere i record di zona.
Mantenimento dei record DNS
Ora che hai un DNS interno funzionante, devi mantenere i tuoi record DNS in modo che riflettano accuratamente il tuo ambiente server.
Aggiunta di host a DNS
Ogni volta che aggiungi un host al tuo ambiente (nello stesso datacenter), dovrai aggiungerlo a DNS. Ecco un elenco di passaggi che è necessario prendere:
Nameserver Primario
- Avanti file di zona: Aggiungere Un record “a” per il nuovo host, l’incremento del valore di “Seriale”
- Invertire il file di zona: Aggiungere un “PTR” per il nuovo host, incrementare il valore di “Seriale”
- Aggiungi il tuo nuovo host dell’indirizzo IP privato del “trusted” ACL (
named.conf.options
)
ricaricare BIND:
- sudo systemctl reload named
Secondario
- Aggiungi il tuo nuovo host dell’indirizzo IP privato del “trusted” ACL (
named.conf.options
)
ricaricare BIND:
- sudo systemctl reload named
Configura un nuovo host per utilizzare il tuo DNS
- Configura resolv.conf per utilizzare i server DNS
- Prova usando
nslookup
Rimozione dell’host dal DNS
Se rimuovi un host dal tuo ambiente o vuoi semplicemente toglierlo dal DNS, rimuovi tutte le cose che sono state aggiunte quando hai aggiunto il server al DNS (cioè il contrario dei passaggi precedenti).
Conclusione
Ora puoi fare riferimento alle interfacce di rete private dei tuoi server per nome, piuttosto che per indirizzo IP. Ciò semplifica la configurazione di servizi e applicazioni perché non è più necessario ricordare gli indirizzi IP privati e i file saranno più facili da leggere e comprendere. Inoltre, ora è possibile modificare le configurazioni per puntare a un nuovo server in un unico luogo, il server DNS primario, invece di dover modificare una varietà di file di configurazione distribuiti, che facilita la manutenzione.
Una volta impostato il DNS interno e i file di configurazione utilizzano FQDN privati per specificare le connessioni di rete, è fondamentale che i server DNS siano mantenuti correttamente. Se entrambi diventano non disponibili, i servizi e le applicazioni che si basano su di essi cesseranno di funzionare correttamente. Questo è il motivo per cui si consiglia di impostare il DNS con almeno un server secondario, e di mantenere i backup di lavoro di tutti loro.