Per ottenere un dominio una organizzazione deve registrarsi presso un ufficio del registro riconosciuto. Ad ogni organizzazione viene assegnato un suffisso univoco.
Il modello di riferimento per il servizio DNS è client/server
e una delle maggiori caratteristiche è la possibilità
per ogni organizzazione di gestirsi in maniera autonoma lo spazio
degli indirizzi assegnato.
Il sistema DNS si comporta globalmente come un database distribuito
di grandi dimensioni dove ogni organizzazione ha un suo server
e ogni server ha dei collegamenti ad altri server in modo che
l'intero sistema funzioni come un unico sistema coordinato.
Quando una applicazione necessita di tradurre un nome nel relativo
IP address diventa formalmente un client e quindi manda una richiesta
al server DNS della sua organizzazione per ottenere la traduzione.
I server DNS sono organizzati gerarchicamente e sono detti
autoritativi per la parte di loro competenza. Ad esempio il
ROOT server, che in realtà è un insieme
di 12/13 server distribuiti geograficamente sui continenti e in
postazioni protette, non conosce i nomi dei computer del dominio
fdns.net ma conosce chi è gestore del
dominio net. In maniera analoga il server che gestisce
il dominio net non conosce i nomi dei computer del dominio
tic.fdns.net ma conosce chi è il gestore del
dominio fdns.net.
Tutti i server sono collegati tra loro in modo da formare un sistema
unico: ogni server conosce come raggiungere il ROOT server
e come raggiungere i server che sono autoritativi per i nomi
dei suoi eventuali sottodomini.
Ogni risolutore di nomi in IP address è configurato per
chiedere servizio al DNS della propria organizzazione. Se la richiesta
che arriva al server è per un dominio di cui è autoritativo
allora il server risponde immediatamente. In caso
contrario diventa un client di un altro server DNS (in particolare
del ROOT server). Dalla radice e scendendo ogni volta di
un livello viene interrogato il server DNS autoritativo fino a quando non
si risolve il nome.
In modo analogo a quanto avviene per un nome di dominio avviene
l'assegnazione di un dominio in-addr.arpa. Questo
particolare dominio serve per compiere l'operazione (inversa)
di trovare il nome di un nodo a partire dall'indirizzo IP.
Allo scopo di ottimizzare le prestazioni il servizio memorizza le risposte in modo da non ripercorrere tutto l'albero.
La documentazione in lingua inglese fornita nell'installazione la puoi
trovare nel pacchetto bind9-doc oppure cercando con Google
il titolo "BIND 9 Administrator Reference Manual" (Bv9ARM).
Il gestore di domini di terzo
livello che ci fornisce gratuitamente il dominio tic.fdns.net
è nord americano e lo trovi seguendo il link
FDNS.NET.
Nel servizio è anche compreso la registrazione sul server DNS
di una chiave per attivare le connessioni VPN.
Dalla versione 9 in poi di Bind si possono costruire delle view (split) attraverso le quali il server risponde in modo diverso in funzione di chi chiede le informazioni. Questa funzionalità ci è sembrata utile dal lato della sicurezza per non dare informazioni aggiuntive e quindi nascondere la configurazione interna. Abbiamo costruito due view:
Le associazioni nomi-IP per l'esterno (view=ext) :
Le associazioni nomi-IP per la rete perimetrale interna
(view=pint) :
Per la risoluzione nel dominio in-addr.arpa da IP a nome ho
utilizzato la documentazione
RFC 2317 per la delegazione di
sottoreti.
A scopo di esercizio si potrebbe pensare che ogni laboratorio abbia un suo DNS che risponde alle associazioni relative al suo spazio di indirizzamento in modo da non dover configurare i due DNS d'istituto quando variano dei nomi all'interno di qualche laboratorio.
Ho preparato una esercitazione
Netkit4TIC proprio con questa
configurazione compresi il ROOT server e i server DNS autoritativi
rispettivamente per il
dominio net e il dominio fdns.net. È stata
anche configurata la risoluzione inversa nel dominio in-addr.arpa.
Sandro Doro (email me)