Come configurare BIND come server DNS di rete privata su CentOS 7

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:

/etc / named.conf-1 di 4
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:

/etc/named.conf-2 of 4
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”:

/etc/named.conf-3 di 4

Alla fine del file, aggiungere la seguente riga:

/etc / named.conf-4 di 4
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):

/etc/named / named.conf.local-1 of 2
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”):

/etc/named/named.conf.local — 2 of 2
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:

/etc/named/zones / db.nyc3.esempio.com-1 di 3

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”:

/etc/named/zones/db.nyc3.example.com — 2 of 3
; 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:

/etc/named/zones/db.nyc3.example.com — 3 di 3

Salvare ed uscire dal filedb.nyc3.example.com.

Il nostro file di zona forward di esempio finale è simile al seguente:

/etc/named/zones/db.nyc3.example.com — complete

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:

/etc/named/zones / db.10.128-1 di 3

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”:

/etc/named/zones / db.10.128-2 di 3
; 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:

/etc/named/zones / db.10.128-3 di 3

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:

/etc/named/zones/db.10.128-complete

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:

/etc / named.conf-1 di 4
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:

/etc/named.conf-2 di 4
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”:

/etc/named.conf-3 of 4
...options {... allow-query { trusted; }; # allows queries from "trusted" clients...

Alla fine del file, aggiungere la seguente riga:

/etc/named.conf-4 di 4
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:

/etc/named/named.conf.locale

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):

/etc / resolv.conf
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):

/etc/resolvconf / resolv.conf.d/testa
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 usandonslookup

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.

Related Posts

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *