No more maintained.
Now just a test in a lab.
Configurazione di BIND
Configurazione di BIND - In particolare la versione 9.x
Named.conf sintassi e direttive
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
La configurazione di bind, versione 9.x.x viene gestista dal file named.conf generalmente posto in /etc o in /etc/bind. Questo file che è un normale file di testo ASCII contiene direttive e commenti. Specifica inoltre i file delle zone e la loro ubicazione nel filesystem.
Per un elenco completo delle direttive utilizzabili (ne esistono realmente tante) e dei loro valori di default consultare il manuale ufficiale di BIND, generalmente posto in /usr/doc o /usr/share/doc. Le principali distribuzioni personalizzano la posizione di questi file, rivolgersi alla documentazione della propria distribuzione per la loro localizzazione.
Molti parametri possono essere lasciati al loro valore di default ma è bene specificare i più importanti anche perchè possono essere vitali ai fini della sicurezza del servizio.
Da ricordare: Ogni direttiva termina con un ";". Tra parentesi graffe si inseriscono le direttive relative ad una direttiva principale. I commenti sono gli stessi che si utilizzano in linguaggio C, "//"per aprire e chiudere o "/*" per aprire e "*/" per chiudere.
Vediamo le direttive principali e la loro sintassi:
acl: Access Control List. Questa direttiva permette di assegnare un nome arbitrario ad un determinato range di indirizzi per facilitarne poi la loro gestione in altre specifiche del named.conf.
La sua sintassi è la seguente:
acl nome-acl {
lista_di_indirizzi
};
Da notare: La acl e il suo rispettivo range di indirizzi va definito all'interno del file prima che possa essere utilizzata in qualunque altra direttiva. In sostanza named legge il suo file di configurazione dal principio alla fine e non ha la capacità di fare l'inverso.
Alcune acl sono implementate di default:
any: Tutti gli host.
none: Nessun host.
localhost: Corrispondenza per l'host locale.
localnets: Corrispondenza per ogni host presente nella rete in cui named è in ascolto.
controls: Permette la definizione di un canale usato dal system administrator per gestire il servizio. Questi canali sono principalmente usati dall'utility rndc per inviare comandi al server.
controls {
inet ( indirizzo_ip | * ) [ port numero_porta ] allow { acl }
keys { lista_chiavi };
};
key: Definisce una chiave segreta per l'autenticazione mediante signature (TSIG, DNSSEC) viene detta shared perchè è condivisa dal server e delle applicazioni che ne fanno uso.
key nome_chiave {
algorithm stringa;
secret stringa;
};
Il nome della chiave è arbitrario, va poi ovviamente ripetuto uguale in tutte le direttive che lo richiedono.
La direttiva algorithm in teoria potrebbe essere di tipo qualunque ma attualmente (BIND 9.2.2, marzo 2003) named supporta esclusivamente hmac-md5.
La direttiva secret specifica una stringa a 64 bit utilizzata da algorithm per il signing delle connessioni.
include: Permette di definire un file esterno da cui estrapolare ulteriori direttive.
include nome_del_file;
Può essere utile nel caso in cui si ha necessità di dare l'accesso in lettura al named.conf a un gruppo di utenti ma non si vuole che la secret key sia accessibile. Si specifica così il parametro key in un file esterno non leggibile e lo si "include" nel named.conf.
option: Sarebbe necessario redarre un how-to separato per descrivere tutte le opzioni possibili che sono numerosissime, rimando ancora alla documentazione ufficiale inclusa col pacchetto named per un'overview più dettagliata.
La sintassi è:
option {
directory /var/named;
listen-on { indirizzo_interfaccia; };
ulteriori opzioni ...;
};
Nel campo option si fanno rientrare numerose direttive:
directory: Specifica la directory di lavoro di named. Se non dichiarata named userà la directory da cui viene lanciato. Di norma si indica la directory dove si trovano i file di zona. Uno standard comune è che sia /var/named ma non è obbligatorio.
pid-file: Si usa se si vuole utilizzare una directory differente dalla default /var/run per salvare il pid-file. Named quando parte avvia più di un processo, il pid-file è usato da alcune applicazioni per conoscere il numero del processo "parente" quello cioè che ha poi generato gli altri processi "figli".
port: Serve a specificare una porta udp/tcp diversa dalla standard 53. E' inteso per l'utilizzo nei test di debug visto che un server che lavora su una porta diversa dalla 53 sarà completamente impossibilitato a comunicare con il resto del Domain Name System globale.
notify: Questa opzione ha una sintassi definibile come "booleana" in quanto accetta parametri come yes o no. Serve a impedire o permettere che il server notifichi i cambiamenti dei suoi file di zona ai server presenti nel record di risorsa NS e ai server specificati con l'opzione also-notify. Può essere specificato anche come opzione per singolo file di zona. Il suo valore di default è yes.
recursion: Anch'essa di sintassi booleana, se posta come yes il server cercherà di elaborare una risposta ad una query del client anche se non presente nella sua cache. Notare che se posta come no non impedisce ai client di ottenere una risposta dalla cache del servizio, l'unica cosa sarà che non vi saranno aggiunte nella cache in seguito a query dei clients. Il suo valore se non specificato è yes. Questa opzione può difendere il named da attacchi tipo DNS-poisoning che utilizzano la funzione di recursive quering.
forwarders: Con questa opzione posso definire gli indirizzi di altri server DNS ai quali il named si appoggerà per le risposte a query di cui non ha autorità e solitamente si definiscono i DNS del proprio Internet Service Provider. Di norma quando il server non ha la risposta in cache si appoggia ai root servers a meno che non si sia specificata questa opzione, in questo caso si possono tranquillamente eliminare i riferimenti alla zona radice "." nel named.conf.
forward: Serve a specificare la policy da usare in caso una richiesta non autoritativa non sia presente nella cache e si siano specificati dei forwarders. I suoi parametri sono first e only.
allow-notify: Permette di specificare una lista di indirizzi (o anche una precedentemente definita acl) a cui è permesso notificare i cambiamenti di un file di zona. Può essere specificata come opzione di una singola direttiva di zona e in tal caso sovrascrive la direttiva globale.
allow-transfer: Permette la specifica di una lista di indirizzi (o una acl) a cui è concesso effettuare un trasferimento di zona. Può essere specificato per un singolo file di zona e in tal caso sovrascrive l'opzione globale.
allow-recursion: Specifica la lista di indirizzi o l'eventuale acl ai quali è concesso effettuare query ricorsive. Si ricordi che non permettere ad un host di avere risposte a query ricorsive non impedisce che le ottenga se presenti in cache.
listen-on: Quando viene lanciato il named si mette in ascolto su tutte le interfacce disponibili per cui se un host ha tre schede di rete e quindi tre indirizzi ascolterà su tutti e tre più la loopback. Con questa opzione si può dire a named su quali indirizzi ascoltare e su quali no. Non si può specificare il nome dell'interfaccia (es. eth0) ma si deve usare il suo indirizzo IP.
Per finire il named.conf contiene le direttive dei file di zona che altro non sono che la loro dichiarazione e l'associazione al corrispettivo file del database DNS.
La sintassi è la seguente:
zone "db.esempio" {
type master;
file "/var/named/db.esempio";
};
Dove zone è la dichiarazione per la zona la quale comprende l'opzione type che ne identifica il tipo, master o slave, e l'opzione file che indica dove si trova il corrispettivo file del database.
Occorre che vi sia una direttiva per ogni file di zona più la specifica per la zona radice e una per i record PTR di localhost.
Dichiarazione per la zona radice:
zone "." IN {
type master;
file "/var/named/root.hint";
};
Dichiarazione per localhost:
zone "0.0.127.in-addr.arpa" IN {
type master;
file "/var/named/127.0.0.db";
};
Come già detto la direttiva per la zona radice può essere omessa nel caso in cui si sia specificata l'opzione forwarders. Il file root.hint è il file contenente le informazioni sui server radice del sistema DNS, potrebbe essere il caso di aggiornarlo ed è recuperabile all'indirizzo ftp://ftp.rs.internic.net.
Configurazione rndc
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
Per eseguire un semplice service named status occorre configurare l'utility rndc.
1. Inserire in /etc/rndc.conf le righe:
options {
default-server localhost;
default-key "rndckey";
};
server localhost {
key "rndckey";
};
key "rndckey" {
algorithm "hmac-md5";
secret "secret key here";
};
2. Creazione della chiave
dnssec-keygen -a HMAC-MD5 -b 256 -n HOST rndc
3. Inserire la chiave privata (contenuta in Krndc.+157+13856.private) in /etc/rndc.conf nel campo secret. Poi cancellare i file creati da Keygen.
4. Inserire in testa al file /etc/named.conf quanto segue:
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
key "rndckey" {
algorithm "hmac-md5";
secret "secret key here";
};
5. Far ripartire named e provare rndc status o service named status
Configurare named per l'aggiornamento dinamico mediante DHCP
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE
A meno da non acquistare dei costosi libri, la documentazione che spiega chiaramente come far si che il DHCP aggiorni i file di zona del DNS è realmente scarna e criptica.
Vediamo brevemente cosa si deve fare dal lato named per prepararlo a questo tipo di aggiornamenti.
Un server DHCP per comunicare con named e fargli aggiornare i file di zona utilizza il DNS Dynamic Update. Se si vuole approfondire l'argomento la request for comments interessata è la rfc 2136. Questo è disponibile dalla versione 8 del BIND e superiori, in precedenza non si era prevista questa funzione visto che si considerava il DNS un database per dati statici e che subivano pochi cambiamenti tranquillamente gestibili a mano dall'amministratore. Con l'ingrandirsi delle reti e l'ampiamento dell'uso di sistemi per l'assegnazione automatica degli ip si è reso necessario trovare uno strumento in grado di tenere traccia di questi cambiamenti, di inserire nuovi records e di cancellarli.
Qui vedremo quali direttive si rendono necessarie nel named.conf per implementare l'update dinamico di un server DHCP presente sulla stessa macchina.
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
Nonostante sia possibile con l'istruzione allow-update specificare un lista di indirizzi ip o una acl per controllare gli update dinamici è sconsigliato per ragioni di sicurezza e preferibile utilizzare TSIG per le autenticazioni. Pertanto si crea l'istanza per la chiave che il server DHCP userà per autenticare i suoi update. Nel dhcpd.conf si dovrà creare l'istanza per la chiave corrispondente
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "DHCP_UPDATER"; };
};
Stabilisco il canale di controllo attraverso il quale il mio server DHCP si connetterà per inviare i dati da aggiornare. In questo caso solo localhost ha la possibilità di accedervi.
options {
directory "/var/named";
pid-file "/var/run/named.pid";
};
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.db";
allow-update { key DHCP_UPDATER; };
};
Per singolo file di zona delineo la direttiva che conceda la possibilità di update solo ai possessori della chiave giusta.
zone "esempio.com" IN {
type master;
file "esempio.com.db";
allow-update { key DHCP_UPDATER; };
};
Vediamo ora come named processa le richieste di update. Come immaginabile dovrebbe incrementare il numero di serie ogni volta che viene aggiunto o eliminato un record. Quando una richiesta di update arriva al server quest'ultimo dovrebbe andare ad aggiornare il relativo file di zona. Riscrivere un file di zona ogni volta che un update viene processato in casi in cui ci si trovi in un contesto di rete molto grosso e con molti update come immaginabile diventa un lavoro realmente oneroso per il server con il rischio che non sia possibile riuscire a processarli tutti. Infatti sia BIND 8 che BIND 9 quando ricevono una richiesta di update dinamico salvano questo record su un file di log che serve a tenere traccia dei nuovi record. In questo modo il nameserver ha sempre in memoria un file di zona con tutti i nuovi record ma si appresta a riscrivere i file di zona a intervalli (generalmente un'ora) prestabiliti. BIND 8 in seguito cancella questi file mentre BIND 9 li conserva perchè vengono utilizzati anche per gli incremental zone transfers. In BIND 9 questi file sono salvati con come nome il nome del file di zona e con estensione .jnl, infatti vengono chiamati journal files. Non c'è da stupirsi infatti se ci si ritrova la directory contenente i file di zona piena di questi jnl files.
Per finire vediamo in breve quello che si dovrebbe aggiungere al dhcpd.conf per il nostro esempio.
Innanzi tutto la direttiva ddns-update-style va settata utilizzando il metodo "interim". Esiste anche il metodo ad-hoc ma è deprecato e considerato obsoleto. Se si desidera approfondire l'argomento leggere il man per il dhcpd.conf.
Infine vanno date le specifiche per l'uso della chiave per l'autenticazione sicura.
La sintassi è la seguente:
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
zone esempio.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
In questo caso come si vede con l'istruzione primary definisco dove si trova il nameserver che in questo caso è localhost ma che va modificato se il dhcp e il DNS sono su due host differenti. Notare anche che nella direttiva zone si deve aggiungere il punto finale anche se in caso non presente il dhcp server dovrebbe aggiungerlo da solo.
Uso delle views con named
Tipo Infobox: TIPS - Skill: 4- ADVANCED
Spesso succede che per necessità ci si trovi costretti a utilizzare il proprio nameserver sia per gestire le richieste della rete interna che le richieste provenienti da Internet.
Ci sono diversi modi di configurare il BIND per questo tipo di lavoro e uno dei più innovativi implementato dalla versione 9.1.x in su è l'uso dell'istruzione view.
Le views permettono di presentare una configurazione del nameserver per una comunità di host e una differente configurazione per un'altro gruppo di host. La sua sintassi è la seguente:
view "internal" {
};
Il nome che si da alla view è arbitrario e è buona norma che sia descrittivo per il tipo di lavoro che andiamo ad eseguire. Non è obbligatorio che sia quotato tra virgolette ma è consigliabile visto che si potrebbero usare nomi che collidono con direttive interne al named. Per specificare quali hosts vedono cosa e quali vedono altro si utilizza l'istruzione match-clients
view "internal" {
match-clients { 192.168.0.0/24; };
}
Volendo si può utilizzare una acl precedentemente assegnata:
acl "intranet" { 192.168.0.0/24; };
view "internal" {
match-clients { "intranet"; };
};
All'interno dell'istruzione view si possono definire molte direttive, si possono specificare le direttive per le zone, descrivere i nameserver remoti con l'istruzione server o configurare direttive key per l'uso di TSIG.
Si possono inoltre definire all'interno dell'istruzione view praticamente quasi tutte le options ricordando che sovrascriveranno ogni opzione globale precedentemente specificata per quegli host che rientrano nella direttiva match-clients
acl "intranet" { 192.168.0.0/24; };
view "internal" {
match-clients { "intranet"; };
recursion yes;
};
Vediamo ora un esempio di configurazione utilizzando le views:
acl "intranet" { 192.168.0.0/24; };
Definisco un Access Control List per gli host della rete interna
options {
directory /var/named;
pid-file /var/run/named.pid;
};
L'opzione directory può essere inclusa nella direttiva view nel caso ad esempio si abbiano molti file di zona e si voglia mantenere in directory separate i file interni e i file esterni.
view "internal" {
match-clients { "intranet"; };
Non specifico una opzione recursion perchè il suo valore di default è yes.
zone "esempio.com" {
type master;
file "esempio.com.db";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.db";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "esempio.com" {
type master;
file "esempio.com.db.external";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.db.external";
};
};
In questo caso si può notare che si utilizzano diversi file di zona per la view internal e per la external; questo non è necessariamente obbligatorio ad esempio si possono comunque utilizzare gli stessi file e definire solo chi ha la possibilità di effettuare recursive quering.
Quando ci si appresta a scrivere file di configurazione che utilizzano le direttive view bisogna prestare attenzione ad alcune regole:
Innanzi tutto l'ordine in cui si specificano le direttive, nel nostro caso per esempio se avessimo specificato prima la direttiva "external" questa avrebbe inevitabilmente occluso la direttiva interna perchè la direttiva esterna ha come match-clients chiunque.
E' importante inoltre ricordare che anche se si specifica una sola direttiva view tutte le direttive zone vanno poi specificate al suo interno.
File di zona per la risoluzione inversa, da indirizzi a nomi
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Abbiamo visto il file di zona per il dominio esempio.com ora vediamo il suo corrispettivo file per la risoluzione inversa. Anche questa volta lascio l'intero file disponibile per poi addentrarmi nelle sue caratteristiche.
Vediamo il file 192.168.0.db:
$TTL 2D
0.168.192.in-addr.arpa. IN SOA ns1.esempio.com. root.ns1.esempio.com. (
2003021502 ;serial
28800 ;refresh
7200 ;retry
604800 ;expire
28800 ) ;minimum
IN NS ns1.esempio.com.
1 IN PTR ns1.esempio.com.
2 IN PTR mac.esempio.com.
3 IN PTR linux.esempio.com.
4 IN PTR windows.esempio.com.
5 IN PTR webftp.esempio.com.
6 IN PTR mail.esempio.com.
Innanzi tutto occorre fare una premessa. Come si può vedere e come già trattato altre volte in questo file non ci sono in realtà riferimenti numerici bensì troviamo questo strano "in-addr.arpa".
Se volessimo cercare, conoscendo un indirizzo ip, il suo corrispettivo nome DNS il nameserver sarebbe costretto a cercare nell'intero albero DNS dal suo dominio di competenza fino alla radice per poi ridiscendere al dominio a cui appartiene l'ip eseguendo una ricerca all'interno dei file delle zone singolo record per singolo record. Come si può immaginare, visto il grande numero di indirizzi numerici esistenti, visto che molti amministratori creano subnet diverse nelle loro reti delegandole poi ad altri DNS, visto che gli indirizzi ip sono di diverse classi, privati e pubblici questo lavoro sarebbe impossibile per il DNS. In più il Domain Name Space indicizza i suoi dati, incluso quelli numerici per nome. Per questo visto che è semplice trovare le informazioni quando si fornisce il nome del dominio che mantiene i dati, gli sviluppatori hanno pensato di creare un dominio a se, che tratta gli indirizzi numerici come "etichette", in-addr.arpa. In questo modo il dominio in-addr.arpa comprenderà 256 sotto-domini i quali includeranno altri 256 sotto-domini il quale includerà altri 256 sotto-domini fino all'ultimo campo numerico di un ip che fornirà il nome di dominio completo per un dato host. La sua rappresentazione così diviene invertita, 192.168.0.1 diventa 1.0.168.192.in-addr.arpa., questo perchè si segue la relazione con il dominio radice ".". In questo modo l'indirizzo ip sarà letto correttamente nel nome di dominio.
192.168.0.1 = 1.0.168.192.in-addr.arpa. = ns1.esempio.com.
Analizziamo ora il nostro file:
$TTL 2D
0.168.192.in-addr.arpa. IN SOA ns1.esempio.com. root.ns1.esempio.com.
In questo caso il primo campo dopo il TTL poteva essere rappresentato con un @ facente riferimento all'origine specificata nella direttiva "zone" del named.conf e che viene appesa a tutti i nomi nel file che non terminano con un punto finale (
2003021502 ;serial
28800 ;refresh
7200 ;retry
604800 ;expire
28800 ) ;minimum
Questi campi hanno lo stesso significato spiegato nel file di zona "esempio.com.db".
IN NS ns1.esempio.com.
Si definisce il o i DNS autoritativi per la zona
1 IN PTR ns1.esempio.com.
2 IN PTR mac.esempio.com.
3 IN PTR linux.esempio.com.
4 IN PTR windows.esempio.com.
5 IN PTR webftp.esempio.com.
6 IN PTR mail.esempio.com.
Infine si specificano i nomi numerici delle macchine e i loro relativi nomi di dominio. Il flag PTR sta per Pointer e indica che si tratta di record per la risoluzione da indirizzo a nome. In questo esempio ho lasciato il flag IN diversamente da quanto fatto nel precedente esempio questo perchè la sua presenza, in specialmodo per i record delle macchine è implicita. Sta alla preferenza dell'amministratore e di solito lo si usa perchè si ottengono dei file più completi ed esaustivi. Come si nota ho usato solo il campo dell'ip che identifica l'host tralasciando il resto che viene automaticamente appeso ad ogni record che non termina con un punto.
File di zona per la risoluzione da nomi a indirizzi
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Vista la struttura e la sintassi del named.conf passiamo ora ad analizzare i file di zona, semplici file di testo in cui si specificano le informazioni necessarie per la risoluzione dei nomi di dominio in indirizzi numerici e viceversa. Anche in questo caso si ha una sintassi specifica e alcune convenzioni da conoscere.
Vediamo in primis la struttura di un file di zona per la risoluzione dei nomi di dominio in indirizzi numerici. Questo file si vedrà essere il più importante in quanto contiene tutti i dati e i record necessari per la configurazione del dominio, del server di posta e degli alias, per citarne alcuni. Il file in questione si chiama esempio.com.db.
Per chiarezza lascerò come esempio l'intero file dopo di che mi addentrerò nella spiegazione della sua struttura.
$ORIGIN .
$TTL 172800 ; 2 days
esempio.com IN SOA ns1.esempio.com. root.ns1.esempio.com. (
2003021512 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns1.esempio.com.
$ORIGIN esempio.com.
$TTL 3600 ; 1 hour
dhcpclient A 192.168.0.98
TXT "311e98e7bea987126c3037d1b1f4c7b99d"
$TTL 172800 ; 2 days
ns1 A 192.168.0.1
mac A 192.168.0.2
linux A 192.168.0.3
windows A 192.168.0.4
webftp A 192.168.0.5
mail A 192.168.0.6
;Aliases
www.esempio.com. CNAME webftp.esempio.com.
ftp.esempio.com. CNAME webftp.esempio.com.
win.esempio.com. CNAME windows.esempio.com.
;Definisco il mail server per il dominio
esempio.com. MX 10 mail.esempio.com.
esempio.com. MX 20 mail.nostroisp.com.
$ORIGIN .
Questo flag indica un nome di dominio che viene automaticamente appeso a tutti i nomi del file di zona che non terminano con un punto finale. In questo esempio si può vedere che sono specificate due direttive $ORIGIN. La prima va a completare la direttiva "esempio.com" mentre la seconda specifica il completamento per i nomi degli host. Alcuni la considerano obsoleta ma vale la pena conoscerla e capirne il significato.
$TTL 172800 ; 2 days
Questo campo indica il default time-to-live. Come si vede si applica globalmente a tutti i record che precedono qualunque altra direttiva di TTL, che può essere indicata anche per singolo host. Il nameserver specifica questo valore in tutte le risposte per la zona o il dato record indicando per quanto tempo gli altri nameservers possono tenerlo in cache. Se si ha un file di zona che subisce poche modifiche è consigliabile specificare un valore alto anche se è sconsigliabile superare la settimana.
esempio.com IN SOA ns1.esempio.com. root.ns1.esempio.com.
Questa è la parte principale del file di zona e serve a indicare lo Start of Authority per la zona esempio.com. In questo caso ns1.esempio.com è il nome del server autoritativo per la zona. Se ne può specificare uno solo e non di più. A seguire abbiamo un record che può creare confusione. Indica l'indirizzo del responsabile della gestione per la zona. I nameservers non utilizzaranno mai questa risorsa che è ad uso esclusivo di chi vuole comunicare con il gestore del dominio. Non si specifica l'indirizzo comune "root@ns1..." ma si deve sostituire l'@ con il punto, questo perchè la sintassi dei file di zona vuole che il simbolo @ si usi come il flag $ORIGIN. Può essere specificato un host differente da quello autoritativo ad esempio root.mail.esempio.com.
I campi chiusi tra le parentesi sono principalmente per gli slave server.
(
2003021512 ; serial
Indicazione del numero di serie. Importante aggiornarlo quando si eseguono modifiche al file per far sapere agli slave che si sono effettuati dei cambiamenti.
28800 ; refresh (8 hours)
Indica agli slave della zona ogni quanto devono verificare che i file sul master sono o meno cambiati. Va prestata attenzione al valore che si da soprattutto nel caso sia basso. Si sappia che uno slave effettua una SOA query per ogni zona ad intervalli specificati nel refresh e si tratta di una operazione molto intensiva in termini di utilizzo di CPU
7200 ; retry (2 hours)
Questo campo indica allo slave ogni quanto tempo riprovare a connettersi al master in caso un refresh non sia andato a buon fine (potrebbe essere momentaneamente down)
604800 ; expire (1 week)
Con expire indico allo slave dopo quanto tempo deve considerare una data zona non più valida. Deve necessariamente essere maggiore dei valori di refresh e di expire altrimenti considererebbe espirati i valori di una zona prima di averla caricata.
86400 ; minimum (1 day)
Questo campo è un TTL. Serve ad indicare quanto tempo un risposta negativa ad una query va tenuta dal nameserver nella cache.
)
NS ns1.esempio.com.
NS, nameserver, indica il nameserver o i nameservers autoritativi per una zona. In caso vi siano due o più DNS per una data zona vanno specificati qua.
$ORIGIN esempio.com.
$TTL 3600 ; 1 hour
dhcpclient A 192.168.0.98
TXT "311e98e7bea987126c3037d1b1f4c7b99d"
Questo record è per un host che utilizza il DHCP. Viene inserito dal server DHCP tramite update dinamico delle zone. Il campo TXT indica una stringa identificativa per il dato host ed è per uso interno al server DHCP ma può essere utilizzata per qualunque tipo di informazione si voglia specificare. In questo caso il TTL è al minimo visto che un record per un client non dotato di un indirizzo statico è soggetto a cambiamenti frequenti.
$TTL 172800 ; 2 days
ns1 A 192.168.0.1
mac A 192.168.0.2
linux A 192.168.0.3
windows A 192.168.0.4
webftp A 192.168.0.5
mail A 192.168.0.6
Questa è la parte che associa i nomi delle macchine ai loro ip. Il flag A sta per Address e indica che si tratta di record per la risoluzione da nome ad indirizzo.
;Aliases
www.esempio.com. CNAME webftp.esempio.com.
ftp.esempio.com. CNAME webftp.esempio.com.
win.esempio.com. CNAME windows.esempio.com.
Con questi campi invece definisco gli alias per alcuni host del dominio. L'esempio dimostra che è possibile assegnare più nomi ad un host. In questo caso il server web e ftp sono la stessa macchina raggiungibile sia se la si cerca come "www.esempio.com" che come "ftp.esempio.com".
;Definisco il mail server per il dominio
esempio.com. MX 10 mail.esempio.com.
esempio.com. MX 20 mail.nostroisp.com.
Con i record MX specifico quali host si occupano dell'instradamento della posta per il dominio esempio.com. Il valore numerico che segue il record MX indica la priorità. In questo caso se invio una mail ad un utente che si trova nel dominio esempio.com il mio client mail cercherà di inviare al server mail.esempio.com per primo. In caso questo fosse troppo occupato o comunque non disponibile il mio mailer si appoggerebbe a mail.nostroisp.com un server fornito dall'Internet Service Provider di esempio.com. Si possono specificare più server con lo stesso valore di priorità ed è consigliabile utilizzare valore numerici che abbiano un certo margine tra loro, questo solo per fini di comodità nell'amministrazione. Ad esempio se in questa zona si decide di implementare un nuovo mail server che poniamo sia una macchina molto potente e posta su un link molto veloce basterebbe dargli un valore di 5 o di 15 a seconda delle preferenze ma se avessimo usato valori tipo 1,2,3.. ci troveremmo obbligati a ristudiare il nostro file di zona. Se si vuole definire un server con priorità massima si può utilizzare il valore 0.
Per finire alcune note. In questo esempio si sono utilizzati valori numerici per indicare i TTL, i refresh, l'expire.. e sono posti con come unità il secondo quindi una settimana diventa 608400 secondi. Dalla versione 8 di BIND in poi si possono specificare anche con degli "argomenti" quindi 3600 secondi diventano 1h e così via si possono specificare valori di 2h35m, due ore e trentacinque minuti, 1d, un giorno, 2w, due settimane. Notare inoltre che la sintassi del file delle zone vuole che i commenti inizino con un ";". Va ricordato infine che vi sono molti record di cui non ho parlato, alcuni obsoleti altri poco usati, se si vuole averne un prospetto più chiaro fare riferimento alla documentazione ufficiale del bind.
/etc/named.conf : server autoritativo
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE
Vediamo la configurazione di un server DNS autoritativo: primario (master) per la zona esempio.com e secondario (slave) per la zona extra.esempio.com.
acl "slaves" { numero_ip_slave1; numero_ip_slave2; };
Definisco una acl per i server slave del master per la zona esempio.com
key rndc-key {
algorithm hmac-md5;
secret "fFh4kjMNL=\spI";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
In questo caso il canale di controllo è posto solo sulla loopback. Resta comunque valida l'ipotesi di inserire una acl che stabilisca quali host amministrativi hanno accesso.
logging {
channel security_info {
file "/var/log/named-auth.log";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category security { security_info; };
};
Abilito il log per i messaggi della categoria security nel file /var/log/named-auth.log e faccio in modo che salvi i messaggi dalla priorità info in su stampando il tipo, la severità e l'ora.
options {
directory "/var/named/";
pid-file "/var/named/run/named.pid";
query-source address * port 53;
allow-query { any; };
listen-on-v6 { "none"; };
recursion no;
};
In questo caso l'opzione allow-query è settata in modo globale ma va ricordato che è preferibile inserirlo come direttive per singolo file di zona e nel nostro caso per la zona su cui ha autorità il server, esempio.com. Specificando "recursion no" disabilito la possibilità che richieste ricorsive vengano processate dal server.
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
notify no;
};
Disabilito la notifica alla zona dell'host locale
zone "1.168.192.in-addr.arpa" IN {
type master;
file "192.168.1.db";
allow-transfer { "slaves"; };
};
Specifica per la risoluzione inversa della zona esempio.com
zone "0.0.10.in-addr.arpa" IN {
type slave;
file "10.0.0.db";
masters 10.0.0.54
};
Specifica per la risoluzione inversa della zona extra.esempio.com, indicando 10.0.0.54 come server DNS primario
zone "esempio.com" IN {
type master;
file "esempio.com.db";
allow-transfer { "slaves"; };
};
Specifica per la zona su cui il server ha autorità e di cui solo gli host presenti nella acl "slaves" hanno il permesso di eseguire un trasferimento di zona
zone "extra.esempio.com" IN {
type slave;
file "extra.esempio.com.db";
masters 10.0.0.54
};
Specifico l'indirizzo del server master per la zona extra.esempio.com
/etc/named.conf : caching-only nameserver
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE
Il file di gestione principale per la configurazione di Bind può essere molto diverso a seconda del tipo di server che si intende implementare.
La sua posizione standard è nella directory /etc ma talvolta alcune distribuzioni lo collocano in /etc/bind/. Se si compila dai sorgenti si può decidere dove collocarlo con il flag --sysconfdir.
Vediamo un esempio per un server caching-only o recursive che dir si voglia, un server che non è autoritativo per domini pubblici e demanda la risoluzione dei nomi ai server dell'Internet Service Provider mantenendo una cache dei record richiesti diminuendo il traffico di rete e i tempi di query DNS.
In fondo alla configurazione sono presenti degli esempi per delle zone relative alla rete locale in cui si trova il server.
acl "local" { 192.168.0.0/24; };
Definire una acl è una cosa che facilita parecchio la gestione del file di configurazione anche se non è obbligatoria, è comoda nel caso il server si trovi in una rete complessa e si abbia da configurare gli accessi in modo fine..
key rndc-key {
algorithm hmac-md5;
secret "fFh4kjMNL=\spI";
};
Dichiarazione di una shared key. La stessa stringa dovrebbe trovarsi anche all'interno dell'rndc.conf per permettere la gestione sicura mediante autenticazione degli accessi. Si possono specificare più chiavi per diversi tipi d'uso o avvalersi solo di una chiave per tutte le operazioni.
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
inet 192.168.0.1 port 953
allow { local; } keys { rndc-key };
};
Definizione di un canale per le comunicazioni amministrative con il server. In questo caso con inet si stabilisce la socket TCP di ascolto e la sua porta il cui valore di default è 953. Nel secondo caso il canale di controllo è settato per restare in ascolto sull'interfaccia con indirizzo 192.168.0.1. Con allow definisco invece chi è autorizzato a collegarsi al canale di controllo in questo caso da localhost e dagli host appartenenti alla acl "local" a patto che abbiano la definizione della chiave rndc-key nel rndc.conf.
options {
directory "/var/named/";
pid-file "/var/named/run/named.pid";
forwarders { DNS1_ISP; DNS2_ISP; };
DNS1_ISP e DNS2_ISP vanno sostituiti con gli indirizzi IP dei server DNS a cui il nostre server rivolgerà tutte le richieste
#forward first;
In questo caso è inserito un commento perchè forward first è il valore di default. Se invece si specifica forward only o forward-only si impedisce ogni query del nameserver a DNS diversi dai forwarders.
listen-on { 127.0.0.1; 192.168.0.1; };
Stabilisce gli indirizzi ip delle interfacce presenti sul server in cui si deve porre in ascolto per delle richieste, in questo caso esclusivamente sulla rete locale e la loopback. Se non specificato di default ascolterà su tutte le interfacce disponibili.
query-source address * port 53;
Con una wildcard * definisco gli indirizzi delle interfacce che named userà per rivolgere le richieste che non hanno ancora un record nella cache e definisco che utilizzi la porta 53. Questo è utile nel caso il server si trovi dietro un firewall che filtra i pacchetti UDP anche se non è valido per quanto riguarda le operazioni che implicano l'uso del TCP in cui usa sempre una porta casuale tra la 1024 e la 65535.
allow-query { 127.0.0.1; "local"; };
listen-on-v6 { "none"; };
notify no;
};
Stabilisce il comportamento del server in caso di cambiamenti nei file di zona di default è yes e che nel caso di un server cache-only non serve visto che non comunica con altri nameserver fuorchè i suoi forwarders.
//zone "." in {
// type hint;
// file "named.root";
//};
In questo caso è commentato vista la presenza dell'opzione forwarders non è più necessario che il nameserver utilizzi i server del dominio radice per le richieste non presenti in cache. Questo è fattibile per la verità solo se si specifica forward-only perchè altrimenti se i forwarders non hanno la risposta o comunque tardano a rispondere di default named interpellerà i DNS del dominio radice.
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
};
Si definisce la zona per la risoluzione inversa di "localhost". Notare che non necessita del flag IN perchè la loopback è in realtà una rete virtuale che nulla ha a che vedere con Internet.
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.db";
};
Occorrenza per il file incaricato della risoluzione inversa per la rete 192.168.0.0/24
zone "local" IN {
type master;
file "local";
};
Va definita per indicare al nameserver che la zona local non contiene nessun record.
zone "esempio.local" IN {
type master;
file "esempio.local";
};
Definisce il file dei nomi di dominio per la rete esempio.local
Esempio di configurazione delle View con Bind
Tipo Infobox: SAMPLE - Skill: 3- INTERMEDIATE
Segue un esempio di configurazione del server DNS Bind con il supporto delle View per risolvere gli indirizzi del dominio "miodominio.it" in diverso modo a seconda se i client hanno IP 192.168.0.0/24 o no.
Ovviamente l'esempio è configurabile ed adattabile a diversi casi, sono inoltre inclusi settaggi particolari, adatti per ogni occasione, per il logging e la gestione di chi può eseguire query sul server.
Sono evidenziati i parametri che vanno cambiati e adattati al proprio caso, altri parametri non usati sono generalmente validi ma possono comunque essere rifiniti.
Esempio di /ETC/NAMED.CONF
options {
// Directory di default in cui vanno scritti i file di zona e altri dati. DA SPECIFICARE
directory "/var/named";
// Eventuale Indirizzo IP del server DNS a cui il server locale rivolge tutte le query (commentato)
// forwarders {
// 10.42.42.1;
// };
// File in cui viene registrato il dump della cache quando si esegue "rndc dump"
dump-file "/var/named/dumpdb";
// File in cui sono scritte varie statistiche quando si esegue "rndc stat"
statistics-file "/var/named/stats";
// IP da cui di DEFAULT si accettano query DNS
// Attenzione: Per domini di cui si è autoritativi, si deve accettare query da ogni IP
allow-query {
10.42.42.0/24;
192.168.0.0/24;
};
// IP da cui si accettano query ricorsive: il server locale effettua query in rete per conto del client
allow-recursion {
10.42.42.0/24;
192.168.0.0/24;
};
// IP di default da cui si accettano zone-transfer: sono gli IP dei server secondari
allow-transfer {
10.42.42.1;
};
// Notifica ai server secondary eventuali modifiche ai file di zone per cui si è primari
notify yes;
// Modifica la visualizzazione della versione di Bind (possibile tramite query tipo:
dig @ns.miodominio.it version.bind chaos txt . In questo caso non si visualizza nulla
version "" ;
};
// Abilita il logging di TUTTE le query DNS sul file /var/log/named-query.log e di ogni informazioni relative la sicurezza (in particolare zone transfer negati) su /var/log/named-auth.log
logging {
channel "security_info" {
file "/var/log/named-auth.log" versions 3 size 20m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel "query_logging" {
file "/var/log/named-query.log" versions 3 size 20m;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category "security" { "security_info"; };
category "queries" { "query_logging"; };
};
// View per client Pubblici - Usa un file di zona con gli IP pubblici: /var/named/miodominio.it-public
// Si applica a tutti gli IP esclusi 192.168.0.0/24
// Include, come la view private, un file di configurazione con impostazioni comuni
view public {
match-clients {
! 192.168.0.0/24 ;
any;
};
zone "miodominio.it" {
type master;
file "/var/named/miodominio.it-public";
allow-query {
0/0;
};
};
include "/etc/named.common" ;
};
// View per client Interni - Usa un file di zona separato: /var/named/miodominio.it-private
view inter {
match-clients {
192.168.0.0/24;
};
zone "miodominio.it" {
type master;
file "/var/named/miodominio.it-private";
};
};
include "/etc/named.common" ;
};
Esempio di file di configurazione che viene incluso (in comune alle diverse view): /ETC/NAMED.COMMON
zone "." {
type hint;
file "/var/named/db.cache";
};
zone "localhost" {
type master;
file "localhost";
allow-update{none;};
};
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.reverse";
allow-update{none;};
};
Esempio di file di zona /VAR/NAMED/MIODOMINIO.IT-PUBLIC
Questo è un esempio di file di zona, configurato per la view pubblica. Da notare:
- I due server NS autoritativi sono su due reti separate per migliore ridondanza
- I CNAME (alias) e gli altri record in cui si usa un hostname, hanno un punto alla fine del nome dell'hostname
- Tutti i parametri relativi a nomi di host, dominio e indirizzi IP vanno ovviamente modificati e adattati al proprio caso
$ORIGIN .
$TTL 86400 ; 1 day
miodominio.it IN SOA ns.miodominio.it. root.miodominio.it. (
2004102501 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
2592000 ; expire (4 weeks 2 days)
86400 ; minimum (1 day)
)
NS ns.miodominio.it.
NS ns2.miodominio.it.
MX 10 mail.miodominio.it.
MX 20 mailbackup.miodominio.it.
$ORIGIN miodominio.it.
ftp CNAME www.miodominio.it.
www A 213.215.144.244
ns A 213.215.144.245
ns2 A 217.56.35.9
mail A 213.215.144.242
mailbackup CNAME ns.miodominio.it.
Esempio di file di zona /VAR/NAMED/MIODOMINIO.IT-PRIVATE
Analogo al file di zona precedente, quello che segue risolve alcuni hst con indirizzi diversi (potrebbero essere IP privati che vengono nattati con gli IP pubblici precedentemente indicati.
$ORIGIN .
$TTL 86400 ; 1 day
miodominio.it IN SOA ns.miodominio.it. root.miodominio.it. (
2004102501 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
2592000 ; expire (4 weeks 2 days)
86400 ; minimum (1 day)
)
NS ns.miodominio.it.
NS ns2.miodominio.it.
MX 10 mail.miodominio.it.
MX 20 mailbackup.miodominio.it.
$ORIGIN miodominio.it.
ftp CNAME www.miodominio.it.
www A 192.168.0.244
ns A 192.168.0.245
ns2 A 217.56.35.9
mail A 192.168.0.242
mailbackup CNAME ns.miodominio.it.