Domain Name System
Massimo Ianigro
Daniele Vannozzi
[email protected]
[email protected]
Argomenti trattati
le funzioni del Domain Name System
lo spazio dei nomi
interazioni tra nameserver e resolver
interazioni tra DNS e posta elettronica
2
Bologna 23 novembre 2000
Domain Name System:
breve storia
 Gli indirizzi IP sono difficili da ricordare: vanno bene per la
comunicazione tra le macchine
 modello centralizzato: agli albori di Internet l’associazione
tra indirizzo IP e nomi delle macchine era registrata nel file
HOSTS.TXT mantenuto presso SRI-NIC (Arpanet)
 traffico e sovraccarico del server centrale
 collisioni dei nomi
 consistenza dei dati gestiti centralmente
 modello distribuito: all’inizio degli anni ‘80, l’aumento del
numero degli host ha reso indispensabile l’adozione di un
modello di gestione distribuita denominato Domain Name
System
3
Bologna 23 novembre 2000
DNS: le funzioni
 ad ogni risorsa TCP/IP può essere assegnato un
nome simbolico
Sono necessari:
 un metodo per associare al nome simbolico di una macchina
l’indirizzo (o gli indirizzi) IP: risoluzione diretta
 un metodo per associare ad un indirizzo IP il nome simbolico
della macchina: risoluzione inversa
 Domain Name System (DNS)
 definito presso ISI - USC 1984
 RFC 882, RFC 883, RFC 973 (obsolete)
 RFC 1034, RFC 1035, RFC 1123, RFC 1537, RFC 1912
4
Bologna 23 novembre 2000
DNS: caratteristiche principali
database distribuito
basato sul modello client/server
tre componenti principali:
 spazio dei nomi e informazioni associate (Resource
Record - RR)
 nameserver (application server che mantiene i dati)
 resolver (client per l’interrogazione del nameserver)
accesso veloce ai dati (database in memoria
centrale e meccanismo di caching)
5
Bologna 23 novembre 2000
Lo spazio dei nomi
 lo spazio dei nomi è organizzato secondo un modello
gerarchico:
 il database del DNS ha una struttura logica “ad albero rovesciato”
 ciascun nodo dell’albero rappresenta un dominio
 ogni dominio può essere suddiviso in altri domini: sottodomini
 ogni nodo ha una etichetta che lo identifica rispetto al padre
La radice dell'albero è unica, e la sua etichetta è vuota. In certi casi
si indica anche come “.”
 struttura dello spazio dei nomi:
 domini generali (gTLD)
 domini nazionali (ccTLD)
 domini per la risoluzione inversa (arpa)
6
Bologna 23 novembre 2000
L’albero dei nomi
Top Level Domain, TLD
a
First Level Domain
c
Second Level Domain
.....
“.“
b
e
d
f
.....
g
h
 il “domain name” (nome a dominio) di ogni nodo è composto dalla sequenza
delle etichette dal nodo a “ “ (root), separate da “.” (punto). Es: e.c.a,
h.g.f.d.b
 un nome a dominio assoluto è detto anche “fully-qualified domain name” o
FQDN
 il ”Distributed Information Tree” (albero dei nomi) definisce una gerarchia dei
nomi che rende ogni nome a dominio completamente qualificato univoco in
tutto l’albero
Bologna 23 novembre 2000
7
I domini
“.“
nodo con nome a dominio
head.acme.com
com
 per dominio si intende il
sottoalbero che inizia dal nodo
acme
con il nome a dominio in
comp
questione
head
 di solito, le foglie
duck
rappresentano il nome a
dominio di un host
www
 ai nodi sono associate le
informazioni relative a quel
nome a dominio (RR)
 entry di host
 entry strutturali
8
dominio com
goofy
sale
dominio acme.com
dominio comp.acme.com
Bologna 23 novembre 2000
L’Internet Domain Name Space
 lo spazio dei nomi di Internet, per “tradizione” (rfc1591), è strutturato
secondo un modello misto organizzazionale/geografico
 i Top-Level-Domain sono
domini generali “storici” di tipo organizzazionale (gTLD):
 com: organizzazioni commerciali
 edu: università e ricerca USA
 gov: organizzazioni governative USA
 mil: organizzazioni militari USA
 net: provider, centri di interesse per l’Internet, ..
 org: organizzazioni non governative
 int: organizzazioni internazionali, trattati, ...
domini nazionali, rappresentati dai codici ISO 3166 di 2 lettere
(ccTLD)
il dominio arpa
nuovi domini in corso di definizione: .info, …
9
Bologna 23 novembre 2000
L’Internet Domain Name Space
“.“
COM
EDU
BERKELEY
AI
PREP
10
MIT
US
STANFORD
LCS
XX
IAT
VX
DNS
NL
IT
CNR
FIAT
MI
RM
UK
FI
ARPA
LAZIO
COMUNE
IN-ADDR
REGIONE
HP4000
Bologna 23 novembre 2000
L’albero per la risoluzione
inversa
“.“
ARPA
IN-ADDR
.....
128
146
.....
.....
11
193
195
.....
.....
48
8
65
1
69
.....
254
 48.146.in-addr.arpa dominio
 65.48.146.in-addr.arpa sotto-dominio
 69.65.48.146.in-addr.arpa macchina
Bologna 23 novembre 2000
La delega di autorità
 Il DNS permette a organizzazioni dotate di un proprio dominio di:
 amministrare la relazione nomi-indirizzi del proprio dominio in maniera
autonoma ed indipendente
 definire le regole di naming all’interno del proprio dominio
 delegare ad altri la gestione degli eventuali domini figli (sotto-domini)
 risolvere i nomi fuori del proprio dominio accedendo alle informazioni
gestite da altre organizzazioni
 la decentralizzazione della responsabilità amministrativa è ottenuta
attraverso il meccanismo della delega
 il gestore del dominio “.” è InterNIC (per conto dello IANA/ICANN),
che delega l’autorità per la gestione dei TLD
12
Bologna 23 novembre 2000
Domini e zone: differenze
zona com
dominio com
“.“
com
acme
13
roger
goofy
 le informazioni sono mantenute nei
nameserver
 un nameserver mantiene i dati di un
sottoinsieme dello spazio dei nomi: la
zona
 ogni
zona
può
essere
un
sottodominio
completo,
cioè
comprendere vari domini su una
porzione del DIT non disgiunta
 un nameserver può gestire più zone
disgiunte
 il dominio padre contiene solo
puntatori alla sorgente dei dati dei
suoi sottodomini
 ciascuna zona contiene i nomi a
dominio e i dati appartenenti ad
certo dominio, esclusi i nomi e i
dati dei sottodomini delegati ad
altri
Bologna 23 novembre 2000
Domini e zone: i nameserver
 la struttura gerarchica dello spazio dei nomi si riflette nella relazione tra
i nameserver
 il meccanismo della delega di autorità si basa sui seguenti principi:
 ogni nameserver di un dominio, per essere conosciuto nel DNS, deve
essere stato registrato dal nameserver del dominio di livello superiore.
Questo crea la delega
 una volta delegata l'autorità su una zona il nameserver “padre” perde
ogni possibilità di modificare le informazioni dei domini contenuti nella
zona delegata
 i nameserver delegati possono essere più d'uno (è consigliato averne
almeno due, in alcuni casi è addirittura obbligatorio), ma uno solo è
quello che possiede la vera autorità perché gestisce i files contenenti
le informazioni
14
Bologna 23 novembre 2000
Il “parenting”
Dipende da varie considerazioni:
!
?
 necessità di definire sottodomini per partizionare uno spazio
dei nomi piatto e molto esteso
 necessità di distinguere l’affiliazione delle macchine di un
dominio
 necessità di distribuire la gestione
 quanti sottodomini definire?
 quando delegarne la gestione?
 che nome assegnare ai sottodomini?
Attenzione alla corretta gestione del meccanismo della
delega per garantire la risoluzione dei nomi per tutto il
dominio!!
15
Bologna 23 novembre 2000
I root-servers
 i root-server sono i nameserver della “.“ (radice).
 sono essenziali al funzionamento del DNS perchè:
 contengono le informazioni sui Top-Level-Domain e sui relativi nameserver ai quali
ne delegano la gestione
 contengono le informazioni per la risoluzione inversa (risoluzione indirizzo-nome)
 ogni nameserver deve conoscere nomi ed indirizzi dei
root-server
 la lista aggiornata dei root-server è mantenuta da InterNIC
 ftp://ftp.rs.internic.net/domain/named.root
 ftp://ftp.nic.it/pub/DNS/named.root
16
Bologna 23 novembre 2000
Nameserver autoritativi
un nameserver si definisce autoritativo quando è
“in possesso dei dati” per una determinata zona
dell’albero dei nomi
per un dominio vi possono essere più
nameserver autoritativi
 per avere una maggiore affidabilità è fortemente
consigliato averne più di uno, localizzati in modo da
ridurre il rischio di interruzione del servizio DNS
i nameserver autoritativi si dividono in:
17
 primari
 secondari
Bologna 23 novembre 2000
Nameserver primari e secondari
 un nameserver si definisce primario quando possiede i file delle
informazioni (“file di zona”) e pertanto in ogni zona vi sarà un solo
nameserver primario
 un nameserver si definisce secondario quando acquisisce, dal
nameserver primario, i dati relativi alla zona mediante una
procedura automatica denominata “zone-transfer”
 i parametri che regolano il funzionamento della procedura sono
contenuti in uno specifico record del nameserver primario (record SOA)
 procedura: /usr/dns/etc/named-xfer -z domname -f outputfile authNS
 è necessario valutare attentamente il numero e la dislocazione dei
nameserver secondari in modo da ridurre il più possibile il rischio
che problemi di connessione possano impedire la risoluzione dei
nomi di un dominio
18
Bologna 23 novembre 2000
Caching
 ogni nameserver mantiene copia di tutte le informazioni di cui è
venuto a conoscenza
 tali informazioni sono utilizzate durante il processo di
risoluzione dei nomi
 le risposte date dal nameserver sulla base della cache sono
“not authoritative”
 le informazioni nella cache di un nameserver rimangono valide
per un tempo limitato (Time-To-Live, TTL)
può dare luogo a “temporanee” inconsistenze
aumenta le performance del sistema
19
Bologna 23 novembre 2000
Il processo di risoluzione:
Nameserver e Resolver
Il processo di risoluzione dei nomi a dominio è basato sul modello clientserver:
 il nameserver (server) è un processo che ha il compito di fornire
“risposte autoritative” ad interrogazioni sui nomi definiti nell’ambito dei
domini per cui è autoritativo;
 il resolver (client) è invece utilizzato dalle applicazioni che hanno
necessità di effettuare una risoluzione di nomi a dominio. Esso è
costituito da un insieme di routine di libreria (es. gethostbyname) che
sono in grado di colloquiare con i nameserver, interpretarne le risposte
e restituire l’informazione al programma richiedente. E’ possibile
configurare il default domain di appartenenza, la lista dei nameserver
da interrogare e la search list in un apposito file di configurazione (es.
file /etc/resolv.conf su Unix)
20
Bologna 23 novembre 2000
Il processo di risoluzione dei nomi
query per www.iat.cnr.it
2
referral al NS per it.
query for www.iat.cnr.it
Default
Nameserver
(cache vuota)
3
referral al NS per cnr.it
root
“.“
nameserver
it.
IT
COM
nameserver
query for www.iat.cnr.it
4
referral al NS per iat.cnr.it
cnr.it
CNR
UNIPI
nameserver
query: www.iat.cnr.it
1
21
6
RESOLVER
applicazione
utente
5
iat.cnr.it
RR per www.iat.cnr.it
nameserver
IAT
BO
www
Bologna 23 novembre 2000
Risoluzione dei nomi
 Se il nome desiderato non è nella zona (o nella cache) del NS
interrogato, si innesca il processo di risoluzione dei nomi
 La richiesta di risoluzione risale il DIT fino alla radice e lo ridiscende
fino ad arrivare ad un NS autoritativo la cui zona contiene il nome in
questione e quindi anche gli RR
 La risposta, opportunamente salvata in tutti i cache intermedi, viene
infine passata dal resolver all’utente che aveva effettuato la
richiesta
 2 modalità di risoluzione dei nomi:
 ricorsiva (il NS pensa a tutto)
 iterativa (il resolver si rivolge direttamente ai vari NS della catena)
22
Bologna 23 novembre 2000
Le piattaforme hardware e
software
 hardware
 disponibile su quasi tutte le attuali piattaforme (PC, Macintosh,
workstation, mainframe)
 software
 prodotti di pubblico dominio (BIND per Unix e WinNT/Win95,
MIND/NonSequitur per MacOS)
 prodotti commerciali (MacDNS, QuickDNS Pro, distribuzione di
WinNT server 4.0)
 BIND (Berkeley Internet Name Domain)
 è l’implementazione di nameserver più diffusa su Internet
 sviluppata per Unix BSD, ne esistono porting per molti altri ambienti
 spesso ne è inclusa una implementazione nel software di corredo di
piattaforme Unix
 vi sono attualmente tre versioni:
23
 la versione “storica” 4.x.y (l’ultima rilasciata è la 4.9.7)
 la versione 8.x.y (l’ultima rilasciata è la 8.2.2-P7)
 la versione 9.x.y, ancora in fase di evoluzione
Bologna 23 novembre 2000
http://www.isc.org/bind.html
Le maggiori differenze tra le
versioni 4 e 8
File di configurazione
 named.boot (4.x.y)
 formato ormai in uso da anni
 consente solo alcune “personalizzazioni” generali
 named.conf (8.x.y)
 nuovo formato (stile linguaggio c)
 funziona con IPv6 (http://www.6bone.net)
 consente una personalizzazione completa sia generale che
zona per zona
 Esiste una procedura perl (named-bootconf.pl) per la
conversione dal formato 4.x.y al formato 8.x.y
rimangono inalterati i file delle singole zone
24
Bologna 23 novembre 2000
Nuove funzionalità della versione
8.x.y
 meccanismo del notify
 permette l’aggiornamento quasi in tempo reale tra nameserver
primario e secondari
 meccanismo di logging flessibile e personalizzabile, senza uso
obbligato del logging del sistema (syslog)
 controllo degli accessi personalizzabile per zona
 migliore ottimizzazione della memoria centrale
 migliora notevolmente le prestazioni del servizio, specialmente per
implementazioni con molte zone attive sulla stessa macchina





25
numero max di zone incrementato a 4.294.967.295 (232 )
supporto iniziale di DNSSEC
supporto di WindowsNT
update dinamico (NSUPDATE) e incrementale (IXFR)
$GENERATE
Bologna 23 novembre 2000
Caratteristiche salienti di BIND 9
Versione corrente 9.0.1
Miglioramento delle funzionalità di update
dinamico
Supporto per zone di elevate dimensioni (.com)
Miglioramento funzionalità DNSSec/TSIG
Miglioramento funzionalità IXFR
Views
RNDC - Remote Named Daemon Control
Alcune delle funzionalità correnti della 8.x.y non
sono ancora state implementate
26
Bologna 23 novembre 2000
Views (Bind 9)
E’ possibile definire ‘viste’ differenti di una stessa zona:
view "internal" {
match-clients { 10.0.0.0/8; }; // rete interna
recursion yes; //ricorsione abilitata solo alla LAN interna
zone "example.com" {
type master;
file ”zone-internal.db"; // file “completo”
};
};
view "external" {
match-clients { any; }; // reti esterne
recursion no;
zone "example.com" {
type master;
file ”zone-external.db"; //file con le macchine “pubbliche”
};
};
27
Bologna 23 novembre 2000
RNDC
Consente il controllo di named in remoto (TCP/953)
Richiede un file di configurazione rndc.conf nel
quale è possibile specificare le chiavi per
l’autenticazione della connessione.
Esempio:
key rndc_key {
algorithm "hmac-md5";
secret "c3Ryb25nIGVub3VnaCBmb3EgK";
};
options {
default-server localhost;
default-key
rndc_key;
};
28
Bologna 23 novembre 2000
Differenze rispetto a BIND 8.2.2
Nuove categorie di logging; il logging viene
attivato solo dopo il parsing completo di
named.conf
Assenza delle opzioni: $GENERATE, STATISTICSINTERVAL, TOPOLOGY, SORTLIST, RRSET-ORDER,
CHECK-NAMES,MIN-ROOTS, process limits, file
path, selective forwarding
Funzione di ‘resolver’ implementata da un
processo demone (UDP/921) invece che da
libresolv.a
named-xfer integrato in named
29
Bologna 23 novembre 2000
Differenze rispetto a BIND 8.2.2
(2)
ACL ‘case sensitive’
Il TTL del SOA non viene più utilizzato come
TTL di default; il default viene determinato dalla
direttiva $TTL oppure dal TTL del primo
resource record nella zona. In assenza di
entrambi la zona non viene caricata!!!
Nuova sintassi della direttiva controls
Sistema operativo WindowsNT non supportato
Administrator Reference Manual
30
Bologna 23 novembre 2000
La posta su Internet
relazione tra SMTP e DNS
l’instradamento della posta su Internet si basa
sulle interazioni tra mailer (MTA) SMTP e DNS
per ogni destinatario di un messaggio il mailer
SMTP chiede al DNS la lista di RR di tipo MX
per il nome a dominio specificato nella parte
globale
i record MX costituiscono una lista ordinata,
secondo la preferenza, di mailer (MTA) per il
dominio (host) destinazione
31
Bologna 23 novembre 2000
Mail Routing & DNS
algoritmo di un mailer SMTP per destinazione
REMOTA:
 lista mailers vuota:
 ripete l’interrogazione per record A e tenta la consegna
all'host remoto
 lista mailers non vuota:
 se la lista contiene il mailer stesso
• scarta se stesso ed ogni mailer con preference minore o
uguale a se stesso (preference con valore numerico maggiore
o uguale) - loop prevention
• se la lista risultasse vuota: ERROR
32
 tenta la consegna ai mailers della lista, partendo dal
preference maggiore (numericamente minore).
Bologna 23 novembre 2000
Mail routing & DNS:
esempio
DNS
domainA MX 0 MTA3
MX 50 MTA2
MX 100 MTA4
MX for domainA
MTA2
mail to
user@domainA MTA1
mail delivery
MTA3
domainA:
LOCAL
MTA4
33
Bologna 23 novembre 2000
Utilizzo dei record MX per il
routing della posta elettronica
Utilizzando opportunamente i pesi associati ai
record MX è possibile controllare il routing della
posta elettronica
Esempio:
effettuare un controllo sull’instradamento della
posta elettronica verso le macchine del dominio
34
Bologna 23 novembre 2000
Utilizzo dei record MX
[email protected]
2
Nella zona di domain.it
Host
IN mx
mx
10 host
20 firewall
Firewall.domain.it
35
Internet
Bologna 23 novembre 2000
Alcune regole pratiche per la
sicurezza del named
Alcune regole pratiche per migliorare il livello di sicurezza di un
named:
 restringere lo zone-transfer solo ai nameserver secondari e verificare
che tali restrizioni siano attivate anche su tutti gli altri nameserver
autoritativi
 disabilitare la possibilità di effettuare update dinamici (nsupdate)
 disabilitare la ricorsione
 eseguire named senza i privilegi di root (named -u xxx)
 nel caso di utilizzo di un firewall per proteggere una rete, predisporre
un nameserver esterno con le sole informazioni relative alle macchine
visibili su Internet (es. www server, mail server, etc) e uno interno,
utilizzabile solo dalle macchine locali, con le informazioni complete
della zona.
Bologna 23 novembre 2000
36
Utility di supporto nella gestione
di un nameserver
nslookup
host
dig
dnswalk
ndc
nsupdate
L’RFC 1713 descrive un insieme di tools che possono essere utili
per il debugging della configurazione di un nameserver
37
Bologna 23 novembre 2000
nslookup
 è normalmente distribuito insieme al S.O. o alla
distribuzione di BIND
 si può utilizzare sia in modalità interattiva che tramite
riga di comando
 dispone di aiuto in linea
nslookup
Default Server: dns.iat.cnr.it
Address: 146.48.65.3
>
> set q=any
> www.iat.cnr.it
> www.iat.cnr.it canonical name = soi.cnr.it
38
Bologna 23 novembre 2000
nslookup (2)
 Query per tutti i record del dominio cnr.it
> nslookup
Default Server: dns.pi.cnr.it
Address: 146.48.65.2
> set q=any
> cnr.it
Server: dns.pi.cnr.it
Address: 146.48.65.2
Non-authoritative answer:
cnr.it nameserver = nameserver.cnr.it
cnr.it nameserver = dns2.nic.it
cnr.it nameserver = itgbox.iat.cnr.it
cnr.it nameserver = simon.cs.cornell.edu
cnr.it nameserver = ns1.surfnet.nl
cnr.it
origin = nameserver.cnr.it
mail addr = Daniele\.Vannozzi.iat.cnr.it
serial = 2000111801
refresh = 86400 (1 day)
retry = 1800 (30 mins)
expire = 604800 (7 days)
minimum ttl = 86400 (1 day)
...
> set type=mx
> ls iat.cnr.it
39
Bologna 23 novembre 2000
host
 è incluso nella distribuzione di BIND ed è inoltre
reperibile presso:
ftp://ftp.nikhef.nl/pub/network/host.tar.Z
 non è interattivo: si utilizza da linea di comando
 permette di fare interrogazioni complesse a qualsiasi
nameserver
 è dotato di aiuto in linea
host
host
host
host
host
host
40
-i 146.48.65.3
-av cnr.it nameserver.cnr.it
-avl cnr.it nameserver.cnr.it
-t soa cnr.it
-C cnr.it
Bologna 23 novembre 2000
host (2)
Query per tutti i record del dominio cnr.it
> host -va cnr.it
Query about cnr.it for record types ANY
Trying cnr.it ...
Query done, 6 answers, status: no error
The following answer is not authoritative:
cnr.it
542353 IN
NS
nameserver.cnr.it
cnr.it
542353 IN
NS
dns2.nic.it
cnr.it
542353 IN
NS
itgbox.iat.cnr.it
cnr.it
542353 IN
NS
simon.cs.cornell.edu
cnr.it
542353 IN
NS
ns1.surfnet.nl
cnr.it
155353 IN
SOA nameserver.cnr.it Daniele\.Vannozzi.iat.cnr.it (
2000111801 ;serial (version)
86400 ;refresh period (1 day)
1800 ;retry interval (30 minutes)
604800 ;expire time (1 week)
86400 ;default ttl (1 day)
)
……
41
Bologna 23 novembre 2000
host (3)
> host -C ba.cnr.it
ba.cnr.it
NS nameserver.cnr.it dns.ba.cnr.it postmaster.dns.ba.cnr.it
(1999071201 3600 1800 604800 86400)
ba.cnr.it
NS dns.ba.cnr.it
dns.ba.cnr.it postmaster.dns.ba.cnr.it
(1999071202 3600 1800 604800 86400)
!!! dns.ba.cnr.it has different serial than nameserver.cnr.it
ba.cnr.it
NS area.area.ba.cnr.it dns.ba.cnr.it postmaster.dns.ba.cnr.it
(1999071201 3600 1800 604800 86400)
!!! area.area.ba.cnr.it has different serial than dns.ba.cnr.it
42
Bologna 23 novembre 2000
dig
è incluso nella distribuzione di BIND
non è interattivo; si utilizza da linea di comando
permette di fare interrogazioni complesse ed a
qualsiasi nameserver
è dotato di aiuto in linea
dig
dig
dig
dig
dig
43
-h
dns.iat.cnr.it
dns.iat.cnr.it mx
-x 146.48.65.3
@nameserver.cnr.it cnr.it
Bologna 23 novembre 2000
dig (2)
 Query per tutti i record del dominio cnr.it
> dig cnr.it
; <<>> DiG 2.2 <<>> cnr.it
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0
;; QUESTIONS:
;;
cnr.it, type = A, class = IN
;; AUTHORITY RECORDS:
cnr.it. 504 SOA nameserver.cnr.it. Daniele\.Vannozzi.iat.cnr.it. (
2000111801; serial
86400 ; refresh (1 day)
1800
; retry (30 mins)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
…..
;; Total query time: 28 msec
;; FROM: dns.pi.cnr.it to SERVER: default -- 146.48.65.2
;; WHEN: Mon Nov 20 12:32:20 2000
44
Bologna 23 novembre 2000
dnswalk
 DNS debugger
 Esegue il trasferimento di zona di un dominio e ne controlla la
consistenza dei dati (record NS e MX che corrispondono a CNAME,
catena di CNAME, mancanza della risoluzione inversa, ecc.)
 Riproduce sul file system la struttura del DNS per il dominio
controllato
 Fa parte dei contrib del BIND (disponibile anche su
http://www.visi.com/~barr/dnswalk/)
 Necessita del perl e di alcuni moduli addizionali (Net::DNS e
IO::Socket). Le vecchie versioni di dnswalk necessitano anche di
‘dig’
45
Bologna 23 novembre 2000
dnswalk
(2)
Effettua controlli su:
 associazione tra record A e PTR
 uso dei CNAME (es. CNAME definito verso un altro CNAME)
 uso dei record MX (MX definito verso CNAME o host inesistenti)
 presenza di un solo nameserver
 utilizzo di caratteri non validi nei nomi a dominio (es: ‘_’ )
 assenza del ‘.’ finale nei record PTR (125 IN PTR host.cnr.it )
 lame delegations
46
Bologna 23 novembre 2000
dnswalk
(3)
Esempio:
dnswalk -F ba.cnr.it.
Checking ba.cnr.it.
Getting zone transfer of ba.cnr.it. from dns.ba.cnr.it...done.
SOA=dns.ba.cnr.it
contact=postmaster.dns.ba.cnr.it
WARN: netrider.ba.cnr.it A 194.119.200.30: no PTR record
WARN: mailhost.ba.cnr.it CNAME bigarea.ba.cnr.it: unknown host
WARN: embnet.ba.cnr.it CNAME embnet.area.ba.cnr.it: CNAME (to
area.area.ba.cnr.it)
WARN: ftp.ba.cnr.it CNAME ftp.area.ba.cnr.it: CNAME (to
area.area.ba.cnr.it)
0 failures, 6 warnings, 0 errors.
47
Bologna 23 novembre 2000
NDC -
Name daemon control
NDC consente di gestire il processo named evitando di inviare segnali
con il comando KILL. Esempi:
# ndc reload BA.CNR.IT
Zone is now scheduled for reloading.
# ndc getpid
my pid is <241>
# ndc status
named 8.2.2-REL Sat Oct 30 17:27:21 MET 1999
[email protected]:/root/bind8_2_2/src/bin/named
number of zones allocated: 256
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is DONE priming
server IS NOT loading its configuration
48
Bologna 23 novembre 2000
NSUPDATE
Consente di aggiornare una zona in modo dinamico, inviando al
named i RR da inserire. Esempio:
# nsupdate
> update add cc.dynamic.ba.cnr.it 3600 IN A 100.100.100.100
causerà l’inserimento del RR ‘cc 3600 IN A 100.100.100.100’ nel dominio dynamic.ba.cnr.it
L’operazione verrà registrata in un file di log (‘file di zona’.log) e propagata ai server secondari:
;BIND LOG V8
[DYNAMIC_UPDATE] id 8347 from [193.204.191.39].1315 at 941985572 (named pid 959)
:
zone: origin dynamic.ba.cnr.it class IN serial 1999072501
update: {add} cc.dynamic.ba.cnr.it. 3600 IN A 100.100.100.100
;BIND LOG V8
[INCR_SERIAL] from 1999072501 to 1999072502 Sat Nov 6 15:44:32 1999
49
Bologna 23 novembre 2000
NSUPDATE
(2)
ATTENZIONE! Il file di zona verrà riscritto (ogni 30 minuti o allo
shutdown di named) con i RR aggiunti via nsupdate:
file di zona prima di nsupdate
@ NS
@ NS
;
WWW
@ IN SOA dns.ba.cnr.it. postmaster.dns.ba.cnr.it. (
1999072501 3600 1800 604800 86400 )
dns.ba.cnr.it.
area.area.ba.cnr.it.
IN
A
194.119.200.100
file di zona riscritto da named
;BIND DUMP V8
$ORIGIN ba.cnr.it.
dynamic
86400 IN
NS
dns.ba.cnr.it. ;Cl=4
86400 IN
NS
area.area.ba.cnr.it. ;Cl=4
86400 IN
SOA dns.ba.cnr.it. postmaster.dns.ba.cnr.it. (
1999072502 3600 1800 604800 86400 ) ;Cl=4
$ORIGIN dynamic.ba.cnr.it.
cc
3600 IN
A
100.100.100.100 ;Cl=4
WWW 86400 IN
A
194.119.200.100 ;Cl=4
50
Bologna 23 novembre 2000
NSUPDATE
(3)
La possibilità di aggiornare una zona via nsupdate va abilitata in
named.conf mediante ‘allow-update’. Il controllo dell’accesso al
momento è basato solo sull’indirizzo IP.
Esempio:
zone "dynamic.ba.cnr.it" {
type master;
file "dom.dynamic.ba.cnr.it";
allow-update {
193.204.191.39;
};
};
51
Bologna 23 novembre 2000
Riferimenti Bibliografici














52
DNS and BIND, 3rd Edition (Paul Albitz & Cricket Liu, September 1998)
RFC 882 - Domain Names, Concepts and Facilities (P. Mockapetris, Sep 1983)
RFC 883 - Domain Names, Implementation and Specification (P. M., Nov 1983)
RFC 973 - Domain System Changes and Observations (P. M., Jan 1986)
RFC 974 - Mail Routing and the Domain System (C. Partridge, Jan 1986)
RFC 1034 - Domain Names, Concepts and Facilities (P. M., Nov 1987)
RFC 1035 - Domain Names, Implementation and Specification (P. M., Nov 1987)
RFC 1123 - Requirements for Internet Hosts, Application and Support (IETF, Oct 1989)
RFC 1340 - Assigned Numbers (ISI, Jul 1992)
RFC 1537 - Common DNS Data File Configuration Errors (P. Beertema, Oct 1993)
RFC 1591 - Domain Name System Structure and Delegation (J. Postel, Mar 1994)
RFC 1713 - Tools for DNS debugging (A. Romao, Nov 1994)
RFC 1912 - Common DNS Operational and Configuration Errors (D. Barr, Feb 1996)
RFC 2317 - Classless IN-ADDR.ARPA delegation (BSD - ISC, Mar 1998)
Bologna 23 novembre 2000
Il naming attuale del dominio CNR.IT
 gestito presso lo IAT di Pisa
 organizzato in sottodomini che riflettono la
struttura organizzativa del CNR, la
distribuzione sul territorio ed esigenze di rete
 tutti i domini devono avere almeno 2
nameserver
 tutti i domini di terzo livello (es: pi.cnr.it,
src.cnr.it, ecc) devono avere come
nameserver secondario nameserver.cnr.it
 è suggerito avere un secondario sul
nameserver primario del dominio padre
 è consigliato utilizzare come nameserver
secondario per la risoluzione inversa delle
reti usate dal CNR (non per le subnet delle
reti in classe B) nameserver.cnr.it
 è necessario “registrare” il router che
assicura l’interconnessione alla dorsale della
rete nel dominio net.cnr.it
53
“.“
IT
CNR
iat
src
dns
pi
iei
ieiserv
www
area
net
pisa-router
adrserv
Bologna 23 novembre 2000
Il nuovo naming del dominio cnr.it
 Approvato dalla commissione CIRT
 attualmente all’approvazione del Presidente/Consiglio Direttivo
 Novita’ introdotte
 Eliminazione del dominio “geografico”
 Univocita’ delle sigle dei nuovi istituti
 Specifiche tecniche sull’erogazione del servizio di risoluzione
dei nomi
 Controllo del rispetto dei requisti tecnici anche dopo l’attivazione
del nuovo dominio
 Attivazione di un gruppo di esperti per la valutazione delle
richieste di nuovi nomi a dominio non previsti dalle attuali policy
54
Bologna 23 novembre 2000
Un possibile utilizzo del nuovo
naming del dominio cnr.it
IRPI
un istituto con sezioni
distribuite sul territorio
nazionale
La situazione attuale
Stesso nome di dominio
 Irpi (eccezione attuale sede di Bari)
Un dominio per ogni sede
 Perugia
 Padova
 Cosenza
 Bari
 Torino
56
irpi.pg.cnr.it
irpi.pd.cnr.it
irpi.cs.cnr.it
cerist.ba.cnr.it
irpi.to.cnr.it
Bologna 23 novembre 2000
Le possibili soluzioni
Adozione di uno schema di naming che non
tenga conto della dislocazione fisica delle
sezioni e delle macchine
 Host.irpi.cnr.it
Adozione di uno schema geografico sotto al
nuovo dominio
 Host.pg.irpi.cnr.it
 Host.pd.irpi.cnr.it
57
Bologna 23 novembre 2000
Alcuni elementi utili alla scelta
dello schema di naming
Sinergie interne al nuovo istituto
Comprensione/immediatezza/semplificazione
dell’indirizzi Internet
Conoscenze informatiche (dns ed altri servizi
Internet di base)
Disponibilita’ di risorse hardware nelle varie sedi
Individuazione delle responsabilita’ nelle varie
sedi
58
Bologna 23 novembre 2000
La migrazione verso il nuovo
naming
Registrazione/delega del nuovo dominio
Verifica/Attivazione dei server dns autoritativi
per il nuovo dominio
Gestione contemporanea del vecchio naming e
nuovo naming
59
Bologna 23 novembre 2000
Interazione tra DNS e
migrazione
l’interazione e’ “legata” al cambio, da parte di
ogni host, del proprio nome a dominio
i file da modificare/creare sono:
 named.conf
 file della risoluzione diretta
 file della risoluzione inversa
i record coinvolti sono principalmente
 record A e CNAME
 record PTR
60
Bologna 23 novembre 2000