Usando le solite guide e le relative fonti (qui e qui), anche la configurazione di base del "Caching name server" è molto semplice.
Di default, l'installazione è già configurata per operare in questa modalità: E' comunque necessario specificare a bind alcuni server DNS definiti "Forwarders" a cui il mio server può indirizzare le richieste che non ha in cache. In sostanza, se il nostro server non conosce già la risposta da dare al client perchè non ce l'ha nella propria cache locale, interrogherà uno di questi forwarders. Le versioni più vecchie di Bind usavano i forwarders nell'ordine in cui erano indicati, la nostra versione credo utilizzi il più veloce ma la cosa non fà una grande differenza.
Questa configurazione si fà nel file named.conf.options:
codice:
nano /etc/bind/named.conf.options
codice:
options {
directory "/var/cache/bind";
...
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Praticamente non c'è nulla: Il percorso della directory in cui Bind salva la propria cache, un utilissimo suggerimento e la riga per impostare i Forwarders.
Perchè il suggerimento è utilissimo? Quali DNS indicare come forwarders?
Un scelta sicuramente non sbagliata sarebbe indicare dei root name server: Sono sicuramente sempre raggiungibili, sono la base della risoluzione dei nomi a livello mondiale quindi una risposta alla nostra interrogazione ce l'hanno di sicuro. Il problema è che sono più sovraccarichi, più lontani e quindi generalmente più lenti. Inoltre l'intero DNS ha una struttura di funzionamento "ad albero" ed i root name servers, essendo la radice, sono anche solitamente gli ultimi a ricevere le modifiche ai valori registrati. Quindi se un server cambia indirizzo IP uno degli ultimo a saperlo potrebbe essere proprio il root name server e questo non li rende la scelta migliore per l'utilizzo di tutti i giorni.
Di massima si preferisce quindi indicare come forwarders i DNS del nostro provider o delle autorità nazionali immediatamente superiori (per l'Italia il NIC), senza risalire fino ai root name server che vengono lasciati appunto all'interrogazione da parte delle autorità nazionali. In alternativa, anche società private come Google forniscono un servizio DNS.
Elenchi dei principali DNS Italiani se ne trovano un pò ovunque, l'indicazione corretta si trova sicuramente anche nella sezione tecnica delle FAQ del nostro provider. Una buona scelta potrebbe essere quindi quella di indicare due DNS del nostro provider ed un DNS del NIC, oppure un DNS del nostro provider e due del NIC... In rete si trovano anche delle comparazioni di velocità tra i vari DNS quindi la scelta si può fare in base alle proprie necessità.
Personalmente, a causa di questo, preferisco adottare dei DNS magari più lenti ma non nazionali.
I miei forwarders sono quindi 208.67.222.222 e 208.67.220.220 (di OpenDNS) e 193.205.245.5 (dns.nic.it) Con Open DNS mi sono sempre trovato bene, sono società note e soprattutto non soggette alla legislazione italiana. Il DNS del NIC è l'ultima spiaggia nel caso OpenDNS non rispondesse all'interrogazione.
codice:
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
forwarders {
208.67.222.222;
193.205.245.5;
};
};
Il file di configurazione di bind è posizionale: praticamente è necessario che la sezione "forwarders" venga dopo le due direttive "auth-nxdomain no;" e "listen-on-v6 { any; };". Se per pigrizia vi venisse voglia di decommentare la sezione "forwarders" presente nell'esempio invece che riscriverla in fondo preparatevi a un potente mal di testa: Bind non si avvia restituendo un errore piuttosto generico:
codice:
Stopping domain name service...: bind9rndc: connect failed: 127.0.0.1#953: connection refused
Generalmente se c'è un errore nel file di configurazione il servizio dà un messaggio di errore un pò più specifico ma in questo caso ho ottenuto solo questo... E sono riuscito a risolverlo solo facendo seguire la sezione "Forwarders" alla altre due direttive...
Riavvio il demone, anche per verificare che funzioni tutto: Il nome del servizio è diverso da quello che si trova su ubuntu, quindi il comando è:
codice:
sudo /etc/init.d/bind9 restart
Questa configurazione mi permette di avere il mio server DNS in modalità "caching name server" configurato e funzionante. Per far sì che il server stesso interroghi se stesso come DNS devo però aggiornare anche il file /etc/resolv.conf, utilizzato in precedenza per configurare i DNS del server.
codice:
sudo nano /etc/resolv.conf
e sostituire agli IP registrati come nameserver l'IP del server, meglio se utilizzando l'IP del localhost. Il mio resolv.conf diventa quindi:
codice:
nameserver 127.0.0.1
Si potrebbe indicarne anche più di uno (basta elencarli di uno per riga allo stesso modo) per permettere al server di navigare comunque anche in caso di problemi con bind ma, se non diventa necessario, preferisco fare così.
A questo punto, posso fare un test per verificare la velocità del DNS. Ovviamente quello che stò utilizzando è uno strumento di caching: quindi la prima volta che interrogo il DNS relativamente ad un dominio specifico la risposta potrebbe non essere superlativa. Il vantaggi maggiori si ottengono in LAN con più client (l'interrogazione di uno è valida per fare caching anche per tutti gli altri) ma dalle successive, il risultato è decisamente migliore.
Il primo screen riporta il tempo impiegato dal DNS 151.99.125.2, di Telecom Italia ed il secondo il tempo di risposta del mio DNS, ovviamente dopo la seconda interrogazione:
Il riavvio di bind ne azzera la cache sarà necessario rigenerarla ad ogni riavvio del servizio.
Verificato che il servizio funziona egregiamente posso modificare le impostazioni del DHCP per distribuire ai client della mia LAN l'IP del server con DNS primario e magari come secondario un altro DNS.
Nel file di configurazione del DHCP quindi modifichiamo questa riga
codice:
option domain-name-servers 208.67.222.222, 208.67.220.220;
in
codice:
option domain-name-servers 192.168.100.150, 208.67.222.222, 193.205.245.5;
In questo modo, se il servizio DNS sul nostro serverino dovesse smettere di funzionare i client potrebbero comunque navigare su internet, in quando avrebbero la possibilità di interrogare il DNS secondario o terziario. Di massima, dopo un periodo iniziale di test o affinamento è meglio però lasciare come DNS solo il mio server, soprattutto se si intende implementare anche la funzionalità di master dns server descritta di seguito.
In ultimo, apportiamo anche le seguenti modifiche al file /etc/network/interface:
codice:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface - Outside -
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.50.2
netmask 255.255.255.0
gateway 192.168.50.1
dns-nameservers 208.57.222.222 151.99.125.2 8.8.8.8
broadcast 192.168.50.255
pre-up /etc/firewall
# Scheda di rete secondaria - Inside -
auto eth1
allow-hotplug eth1
iface eth1 inet static
address 192.168.100.150
netmask 255.255.255.0
dns-search fracassetti.lan
dns-nameservers 192.168.100.150
broadcast 192.168.100.255
5_ Installazione e configurazione del server DNS e di rndc
Rispondi quotando
