Introduzione

Il DNS, o Domain Name System, è spesso un componente difficile da capire quando si impara a configurare siti e server. Mentre la maggior parte delle persone probabilmente sceglierà di utilizzare i server DNS forniti dalla loro società di hosting o dal loro registrar di domini, ci sono alcuni vantaggi nel creare i propri server DNS.

In questa guida, discuteremo come installare e configurare il server DNS Bind9 come server DNS autoritativo su macchine Ubuntu 14.04. Imposteremo due server Bind per il nostro dominio in una configurazione primaria-secondaria.

Prequisiti e obiettivi

Per completare questa guida, è necessario innanzitutto avere familiarità con alcuni termini DNS comuni. Date un’occhiata a questa guida per conoscere i concetti che implementeremo in questa guida.

Avrete anche bisogno di almeno due server. Uno sarà il server DNS “primario” da cui avranno origine i file di zona per il nostro dominio e uno sarà il server “secondario” che riceverà i dati di zona tramite trasferimenti e sarà disponibile nel caso in cui l’altro server vada giù. Questo evita il pericolo di avere un singolo punto di fallimento per i vostri server DNS.

A differenza dei server DNS di caching o di inoltro o di un server DNS multiuso, i server solo autoritativi rispondono solo alle query iterative per le zone per le quali sono autoritativi. Questo significa che se il server non conosce la risposta, dirà semplicemente al client (di solito un qualche tipo di server DNS di risoluzione) che non conosce la risposta e darà un riferimento a un server che potrebbe saperne di più.

I server DNS autoritativi sono spesso una buona configurazione per alte prestazioni perché non hanno l’overhead di risolvere le query ricorsive dei client. Si preoccupano solo delle zone che sono progettati per servire.

Per gli scopi di questa guida, faremo riferimento a tre server. I due name server menzionati sopra, più un server web che vogliamo configurare come host nella nostra zona.

Utilizzeremo il dominio fittizio example.com per questa guida. Dovreste sostituirlo con il dominio che state configurando. Questi sono i dettagli delle macchine che configureremo:

Scopo	DNS FQDN	Indirizzo IP
Server primario del nome	ns1.example.com.	192.0.2.1
Secondary name server	ns2.example.com.	192.0.2.2
Web Server	www.example.com.	192.0.2.3

Dopo aver completato questa guida, dovresti avere due name server autoritativi configurati per le tue zone di dominio. I nomi nella colonna centrale della tabella qui sopra potranno essere utilizzati per raggiungere i vostri vari host. Usando questa configurazione, un server DNS ricorsivo sarà in grado di restituire dati sul dominio ai clienti.

Impostazione dell’hostname sui server dei nomi

Prima di entrare nella configurazione dei nostri server dei nomi, dobbiamo assicurarci che il nostro hostname sia configurato correttamente sia sul nostro server DNS primario che su quello secondario.

Iniziare esaminando il file /etc/hosts. Aprite il file con i privilegi di sudo nel vostro editor di testo:

sudo nano /etc/hosts

Dobbiamo configurarlo in modo che identifichi correttamente l’hostname e il FQDN di ciascun server. Per il name server primario, il file sarà simile a questo inizialmente:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Dovremmo modificare la seconda linea per fare riferimento alla nostra specifica combinazione di host e dominio e puntarla al nostro indirizzo IP pubblico e statico. Possiamo poi aggiungere il nome non qualificato come alias alla fine. Per il server primario in questo esempio, dovreste cambiare la seconda linea in questo modo:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Salvare e chiudere il file quando avete finito.

Dovremmo anche modificare il file /etc/hostname per contenere il nostro hostname non qualificato:

sudo nano /etc/hostname

ns1

Possiamo leggere questo valore nel sistema attualmente in esecuzione digitando:

sudo hostname -F /etc/hostname

Vogliamo completare la stessa procedura sul nostro server secondario.

Iniziamo con il file /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Salva e chiudi il file quando hai finito.

Poi, modifica il file /etc/hostname. Ricorda di usare solo l’host reale (solo ns2 nel nostro esempio) per questo file:

sudo nano /etc/hostname

ns2

Di nuovo, leggi il file per modificare il sistema attuale:

sudo hostname -F /etc/hostname

I tuoi server dovrebbero ora avere le loro definizioni di host impostate correttamente.

Installare Bind su entrambi i server di nomi

Su ciascuno dei tuoi server di nomi, puoi ora installare Bind, il server DNS che useremo.

Il software Bind è disponibile nei repository di default di Ubuntu, quindi abbiamo solo bisogno di aggiornare il nostro indice locale dei pacchetti e installare il software usando apt. Includeremo anche la documentazione e alcune utilità comuni:

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Esegui questo comando di installazione sul tuo server DNS primario e secondario per acquisire i file appropriati.

Configura il server Bind primario

Ora che abbiamo installato il software, possiamo iniziare a configurare il nostro server DNS sul server primario.

Configurazione del file delle opzioni

La prima cosa che configureremo per iniziare è il file named.conf.options.

Il server DNS Bind è anche conosciuto come named. Il file di configurazione principale si trova a /etc/bind/named.conf. Questo file richiama gli altri file che effettivamente configureremo.

Apri il file delle opzioni con i privilegi di sudo nel tuo editor:

sudo nano /etc/bind/named.conf.options

Di seguito, la maggior parte delle linee commentate sono state eliminate per brevità, ma in generale il file dovrebbe avere questo aspetto dopo l’installazione:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

La cosa principale che dobbiamo configurare in questo file è la ricorsione. Poiché stiamo cercando di impostare un server solo autoritativo, non vogliamo abilitare la ricorsione su questo server. Possiamo disattivarla all’interno del blocco options.

Abbiamo anche deciso di non permettere trasferimenti. Lo sovrascriveremo più tardi nelle specifiche delle singole zone:

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Quando hai finito, salva e chiudi il file.

Configurazione del file locale

Il prossimo passo che dobbiamo fare è specificare le zone che vogliamo controllare questo server. Una zona è qualsiasi porzione di dominio che è delegata per la gestione a un server di nomi che non è stata sub-delegata ad altri server.

Stiamo configurando il dominio example.com e non abbiamo intenzione di sub-delegare la responsabilità per qualsiasi porzione del dominio ad altri server. Quindi la zona coprirà il nostro intero dominio.

Per configurare le nostre zone, dobbiamo aprire il file /etc/bind/named.conf.local con i privilegi di sudo:

sudo nano /etc/bind/named.conf.local

Questo file sarà inizialmente vuoto a parte i commenti. Ci sono altre zone che il nostro server conosce per la gestione generale, ma queste sono specificate nel file named.conf.default-zones.

Per iniziare, dobbiamo configurare la zona forward per il nostro dominio example.com. Le forward zone sono la risoluzione convenzionale nome-IP a cui la maggior parte di noi pensa quando si parla di DNS. Creiamo un blocco di configurazione che definisce la zona di dominio che vogliamo configurare:

zone "example.com" {};

Nota: Molti strumenti DNS, i loro file di configurazione e la documentazione utilizzano i termini “master” e “slave” mentre DigitalOcean generalmente preferisce descrittori alternativi. Per evitare confusione abbiamo scelto di usare i termini “primario” e “secondario” per indicare le relazioni tra i server, e usare “master” o “slave” solo quando una direttiva di configurazione lo richiede.

All’interno di questo blocco, aggiungiamo le informazioni di gestione su questa zona. Specifichiamo la relazione di questo server DNS con la zona. Questo è type master; nell’esempio di zona che segue, poiché stiamo configurando questa macchina come server di nomi primario per tutte le nostre zone. Puntiamo anche Bind al file che contiene i record di risorse effettivi che definiscono la zona.

Teniamo i nostri file di zona primaria in una sottodirectory chiamata zones all’interno della directory di configurazione Bind. Chiameremo il nostro file db.example.com per prendere in prestito la convenzione dagli altri file di zona nella directory Bind. Il nostro blocco sarà ora simile a questo:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com";};

Vogliamo permettere che questa zona sia trasferita al nostro server secondario, dobbiamo aggiungere una linea come questa:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

Prossimo, stiamo per definire la zona inversa per il nostro dominio.

Un po’ di informazioni sulle zone inverse

Se l’organizzazione che vi ha dato i vostri indirizzi IP non vi ha dato un intervallo di rete e non vi ha delegato la responsabilità di tale intervallo, allora il vostro file di zona inversa non sarà referenziato e sarà gestito dall’organizzazione stessa.

Con i provider di hosting, la mappatura inversa è solitamente curata dalla società stessa. Per esempio, con DigitalOcean, le mappature inverse per i vostri server saranno create automaticamente se usate il FQDN della macchina come nome del server nel pannello di controllo. Per esempio, le mappature inverse per questo tutorial potrebbero essere create nominando i server in questo modo:

In casi come questi, poiché non vi è stato assegnato un gruppo di indirizzi da amministrare, dovreste usare questa strategia. La strategia delineata di seguito è coperta per completezza e per renderla applicabile se vi è stato delegato il controllo su gruppi più grandi di indirizzi contigui.

Le zone inverse sono usate per collegare un indirizzo IP a un nome di dominio. Tuttavia, il sistema dei nomi di dominio è stato progettato originariamente per le mappature in avanti, quindi è necessario pensare ad adattarlo per permettere le mappature inverse.

Le informazioni che dovete tenere a mente per capire le mappature inverse sono:

• In un dominio, la parte più specifica dell’indirizzo è a sinistra. Per un indirizzo IP, la parte più specifica è a destra.
• La parte più specifica di una specifica di dominio è un sottodominio o un nome host. Questo è definito nel file di zona per il dominio.
• Ogni sottodominio può, a sua volta, definire più sottodomini o host.

Tutti i mappaggi di zona inversa sono definiti sotto il dominio speciale in-addr.arpa, che è controllato dalla Internet Assigned Numbers Authority (IANA). Sotto questo dominio, esiste un albero che usa i sottodomini per mappare ciascuno degli ottetti di un indirizzo IP. Per assicurarsi che la specificità degli indirizzi IP rispecchi quella dei domini normali, gli ottetti degli indirizzi IP sono effettivamente invertiti.

Così il nostro server DNS primario, con un indirizzo IP di 192.0.2.1, verrebbe invertito per essere letto come 1.2.0.192. Quando aggiungiamo questa specifica dell’host come una gerarchia esistente sotto il dominio in-addr.arpa, l’host specifico può essere referenziato come 1.2.0.192.in-addr.arpa.

Siccome definiamo i singoli host (come il “1” iniziale qui) all’interno del file di zona stesso quando usiamo il DNS, la zona che staremmo configurando sarebbe 2.0.192.in-addr.arpa. Se il nostro provider di rete ci ha dato un blocco di indirizzi /24, diciamo 192.0.2.0/24, ci avrebbe delegato questa porzione in-addr.arpa.

Ora che sapete come specificare il nome della zona inversa, la definizione effettiva è esattamente la stessa della zona forward. Sotto la definizione della zona example.com, fate una zona inversa per la rete che vi è stata data. Di nuovo, questo è probabilmente necessario solo se ti è stato delegato il controllo su un blocco di indirizzi:

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

Abbiamo scelto di chiamare il file db.192.0.2. Questo è specifico su ciò che la zona configura ed è più leggibile della notazione inversa.

Salva e chiudi il file quando hai finito.

Crea il file della zona Forward

Abbiamo detto a Bind delle nostre zone forward e reverse, ma non abbiamo ancora creato i file che definiranno queste zone.

Se ti ricordi, abbiamo specificato la posizione dei file in una sottodirectory chiamata zones. Dobbiamo creare questa directory:

sudo mkdir /etc/bind/zones

Ora, possiamo usare alcuni dei file di zona preesistenti nella directory Bind come modelli per i file di zona che vogliamo creare. Per la zona forward, il file db.local sarà vicino a quello di cui abbiamo bisogno. Copia quel file nella sottodirectory zones con il nome usato nel file named.conf.local.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

Mentre facciamo questo, possiamo copiare anche un modello per la zona inversa. Useremo il file db.127, dal momento che è molto simile a quello di cui abbiamo bisogno:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

Ora, aprite il file della zona inversa con i privilegi di sudo nel vostro editor di testo:

sudo nano /etc/bind/zones/db.example.com

Il file sarà simile a questo:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

La prima cosa che vogliamo fare è modificare il record SOA (inizio di autorità) che inizia con il primo simbolo @ e continua fino alla parentesi di chiusura.

Dobbiamo sostituire il localhost. con il nome del FQDN di questa macchina. Questa parte del record serve a definire qualsiasi server di nomi che risponderà in modo autorevole per la zona che si sta definendo. Questa sarà la macchina che stiamo configurando ora, ns1.example.com. nel nostro caso (notare il punto finale. Questo è importante perché la nostra voce si registri correttamente!)

Vogliamo anche cambiare il prossimo pezzo, che è in realtà un indirizzo email appositamente formattato con il @ sostituito da un punto. Vogliamo che le nostre email vadano a un amministratore del dominio, quindi l’email tradizionale è [email protected]. Dovremmo tradurre questo in modo che appaia come admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

Il prossimo pezzo che dobbiamo modificare è il numero di serie. Il valore del numero di serie è il modo in cui Bind dice se ha bisogno di inviare informazioni aggiornate al server secondario.

Nota: Non incrementare il numero di serie è uno degli errori più comuni che porta a problemi con gli aggiornamenti di zona. Ogni volta che si fa una modifica, è necessario urtare il numero di serie.

Una pratica comune è quella di usare una convenzione per incrementare il numero. Un approccio è quello di usare la data nel formato YYYYMMDD con un numero di revisione per il giorno aggiunto alla fine. Così la prima revisione fatta il 05 giugno 2014 potrebbe avere un numero di serie di 2014060501 e un aggiornamento fatto più tardi quel giorno potrebbe avere un numero di serie di 2014060502. Il valore può essere un numero di 10 cifre.

Vale la pena adottare una convenzione per facilità d’uso, ma per mantenere le cose semplici per la nostra dimostrazione, imposteremo la nostra su 5 per ora:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

Poi, possiamo sbarazzarci delle ultime tre righe del file (quelle in basso che iniziano con @) perché ne faremo una nostra.

La prima cosa che vogliamo stabilire dopo il record SOA sono i name server per la nostra zona. Specifichiamo il dominio e poi i nostri due name server autoritativi per la zona, per nome. Poiché questi name server saranno host all’interno del dominio stesso, sembrerà un po’ autoreferenziale.

Per la nostra guida, sarà così. Di nuovo, fate attenzione ai punti finali!:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Siccome lo scopo di un file di zona è principalmente quello di mappare i nomi degli host e dei servizi a indirizzi specifici, non abbiamo ancora finito. Qualsiasi software che legge questo file di zona vorrà sapere dove sono i server ns1 e ns2 per accedere alle zone autoritative.

Poi dobbiamo creare i record A che assoceranno i nomi dei name server agli indirizzi IP reali dei nostri name server:

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Ora che abbiamo i record A per risolvere con successo i nostri name server ai loro indirizzi IP corretti, possiamo aggiungere qualsiasi altro record. Ricordate, abbiamo un server web su uno dei nostri host che vogliamo usare per servire il nostro sito. Indirizzeremo le richieste per il dominio generale (example.com nel nostro caso) a questo host, così come le richieste per l’host www. Sarà così:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Puoi aggiungere altri host che hai bisogno di definire creando ulteriori record A. Fai riferimento alla nostra guida DNS di base per familiarizzare con alcune delle tue opzioni con la creazione di record aggiuntivi.

Quando hai finito, il tuo file dovrebbe assomigliare a questo:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Salva e chiudi il file quando hai finito.

Crea il file della zona inversa

Ora, abbiamo la zona in avanti configurata, ma dobbiamo impostare il file della zona inversa che abbiamo specificato nel nostro file di configurazione. Abbiamo già creato il file all’inizio dell’ultima sezione.

Apri il file nel tuo editor di testo con i privilegi di sudo:

sudo nano db.192.0.2

Il file dovrebbe assomigliare a questo:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Seguiremo gran parte della stessa procedura che abbiamo fatto con la zona in avanti. Per prima cosa, modificate il nome del dominio, l’email dell’amministratore e il numero di serie in modo che corrisponda esattamente a quello che avevate nell’ultimo file (il numero di serie può essere diverso, ma dovrebbe essere incrementato):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

Ancora una volta, cancellate le linee sotto la parentesi di chiusura del record SOA. Prenderemo l’ultimo ottetto di ogni indirizzo IP nel nostro intervallo di rete e lo mapperemo al FQDN di quell’host usando un record PTR. Ogni indirizzo IP dovrebbe avere solo un singolo record PTR per evitare problemi in alcuni software, quindi dovete scegliere il nome dell’host a cui volete fare la mappatura inversa.

Per esempio, se avete un server di posta impostato, probabilmente volete impostare la mappatura inversa sul nome della posta, poiché molti sistemi usano la mappatura inversa per validare gli indirizzi.

Prima di tutto, abbiamo bisogno di impostare di nuovo i nostri name server:

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

Poi, userete l’ultimo ottetto dell’indirizzo IP a cui vi state riferendo e lo punterete al nome di dominio pienamente qualificato con cui volete tornare. Per il nostro esempio, useremo questo:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Quando hai finito, il file dovrebbe essere simile a questo:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Salva e chiudi il file quando hai finito.

Testare i file e riavviare il servizio

La configurazione per il server primario è ora completa, ma dobbiamo ancora implementare le nostre modifiche.

Prima di riavviare il servizio, dovremmo testare tutti i nostri file di configurazione per assicurarci che siano configurati correttamente. Abbiamo alcuni strumenti che possono controllare la sintassi di ciascuno dei nostri file.

Primo, possiamo controllare i file named.conf.local e named.conf.options usando il comando named-checkconf. Dal momento che entrambi questi file sono fonte del file scheletro named.conf, esso testerà la sintassi dei file che abbiamo modificato.

sudo named-checkconf

Se questo ritorna senza alcun messaggio, significa che i file named.conf.local e named.conf.options sono sintatticamente validi.

Poi, puoi controllare i tuoi singoli file di zona passando il dominio che la zona gestisce e la posizione del file di zona al comando named-checkzone. Quindi, per la nostra guida, potreste controllare il file di zona forward digitando:

sudo named-checkzone example.com /etc/bind/zones/db.example.com

Se il vostro file non ha problemi, dovrebbe dirvi che ha caricato il numero di serie corretto e dare il messaggio “OK”;

zone example.com/IN: loaded serial 5OK

Se incontrate altri messaggi, significa che avete un problema con il vostro file di zona. Di solito, il messaggio è abbastanza descrittivo su quale parte non è valida.

Puoi controllare la zona inversa passando l’indirizzo in-addr.arpa e il nome del file. Per la nostra dimostrazione, dovremmo digitare questo:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

Anche questo dovrebbe darti un messaggio simile sul caricamento del numero di serie corretto:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Se tutti i tuoi file vengono controllati, puoi riavviare il servizio Bind:

sudo service bind9 restart

Dovresti controllare i log digitando:

sudo tail -f /var/log/syslog

Tieni d’occhio questo log per essere sicuro che non ci siano errori.

Configura il Bind Server secondario

Ora che abbiamo configurato il server primario, possiamo andare avanti e configurare il server secondario. Questo sarà significativamente più facile del server primario.

Configurare il file delle opzioni

Ancora una volta, inizieremo con il file named.conf.options. Aprilo con i privilegi di sudo nel tuo editor di testo:

sudo nano /etc/bind/named.conf.options

Faremo le stesse identiche modifiche a questo file che abbiamo fatto al file del nostro server primario.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Salva e chiudi il file quando hai finito.

Configurazione del file di configurazione locale

In seguito, configureremo il file named.conf.local sul server secondario. Aprilo con i privilegi di sudo nel tuo editor di testo:

sudo nano /etc/bind/named.conf.local

Qui, creeremo ciascuna delle nostre specifiche di zona come abbiamo fatto sul nostro server primario. Tuttavia, i valori e alcuni dei parametri saranno diversi.

Primo, lavoreremo sulla zona di inoltro. Iniziate nello stesso modo in cui avete fatto nel file primario:

zone "example.com" {};

Questa volta, imposteremo il type a slave poiché questo server sta agendo come secondario per questa zona. Questo significa semplicemente che riceve i suoi file di zona tramite trasferimento piuttosto che un file sul sistema locale. Inoltre, specificheremo solo il nome del file relativo invece del percorso assoluto del file di zona.

La ragione di questo è che, per le zone secondarie, Bind memorizza i file /var/cache/bind. Bind è già configurato per cercare in questa directory, quindi non abbiamo bisogno di specificare il percorso.

Per la nostra zona forward, questi dettagli saranno così:

zone "example.com" { type slave; file "db.example.com";};

Infine, invece della direttiva allow-transfer, specificheremo i server primari, per indirizzo IP, da cui questo server accetterà trasferimenti di zona. Questo viene fatto in una direttiva chiamata masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

Questo completa la nostra specifica della zona di inoltro. Possiamo usare lo stesso identico formato per occuparci della nostra specifica della zona inversa:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

Quando hai finito, puoi salvare e chiudere il file.

Testare i file e riavviare il servizio

In realtà non dobbiamo fare alcuna creazione di file di zona sulla macchina secondaria perché, come abbiamo detto prima, questo server riceverà i file di zona dal server primario. Quindi siamo pronti per il test.

Ancora una volta, dovremmo controllare la sintassi del file di configurazione. Poiché non abbiamo alcun file di zona da controllare, dobbiamo solo usare lo strumento named-checkconf:

sudo named-checkconf

Se questo ritorna senza errori, significa che i file che hai modificato non hanno errori di sintassi.

Se questo è il caso, puoi riavviare il tuo servizio Bind:

sudo service bind9 restart

Controlla i log su entrambi i server primario e secondario usando:

sudo tail -f /var/log/syslog

Dovresti vedere alcune voci che indicano che i file di zona sono stati trasferiti correttamente.

Delega l’autorità ai tuoi name server

I tuoi name server autoritativi dovrebbero ora essere completamente configurati. Tuttavia, hai ancora bisogno di delegare l’autorità per il tuo dominio ai tuoi name server.

Per fare questo, dovrai andare sul sito web dove hai acquistato il tuo nome di dominio. L’interfaccia e forse la terminologia saranno diverse a seconda del registrar di nomi di dominio che hai usato.

Nelle impostazioni del tuo dominio, cerca un’opzione che ti permetterà di specificare i name server che desideri utilizzare. Poiché i nostri name server sono all’interno del nostro dominio, questo è un caso speciale.

Invece di delegare semplicemente l’autorità per la zona attraverso l’uso di record NS, la società di registrazione dovrà creare un glue record. Un glue record è un record A che specifica gli indirizzi IP per i name server dopo aver specificato i name server a cui sta delegando l’autorità.

Di solito, la delega elenca solo i name server che gestiranno l’autorità del dominio, ma quando i name server sono all’interno del dominio stesso, è necessario un record A per i name server nella zona madre. Se questo non accadesse, i resolver DNS rimarrebbero bloccati in un loop perché non sarebbero mai in grado di trovare l’indirizzo IP dei name server del dominio per seguire il percorso di delega.

Quindi è necessario trovare una sezione del pannello di controllo della propria società di registrazione del dominio che permetta di specificare i name server e i loro indirizzi IP.

A titolo di dimostrazione, la società di registrazione Namecheap ha due diverse sezioni di name server.

C’è una sezione chiamata “Nameserver Registration” che permette di specificare gli indirizzi IP per i name server all’interno del vostro dominio:

All’interno, potrete inserire gli indirizzi IP dei name server che esistono all’interno del dominio:

Questo creerà i record A che servono come record collante di cui avete bisogno nel file della zona madre.

Dopo aver fatto questo, dovresti essere in grado di cambiare i name server attivi con quelli del tuo dominio. In NameCheap, questo viene fatto usando l’opzione di menu “Domain Name Server Setup”:

Qui, puoi dirgli di usare i name server che hai aggiunto come server autoritativi per il tuo sito:

I cambiamenti potrebbero richiedere un po’ di tempo per propagarsi, ma dovresti vedere i dati dei tuoi name server essere usati entro le prossime 24-48 ore per la maggior parte dei registrar.

Conclusione

Ora dovresti avere due server DNS solo autoritativi configurati per servire i tuoi domini. Questi possono essere usati per memorizzare le informazioni di zona per altri domini man mano che ne acquisisci altri.

Configurare e gestire i tuoi server DNS ti dà il massimo controllo su come vengono gestiti i record DNS. Potete apportare modifiche ed essere sicuri che tutti i pezzi rilevanti dei dati DNS siano aggiornati alla fonte. Anche se altre soluzioni DNS possono rendere questo processo più facile, è importante sapere che avete delle opzioni e capire cosa succede nelle soluzioni più confezionate.

Si può fare in modo che i dati DNS siano aggiornati alla fonte.