Massimo Ianigro Massimo Ianigro [email protected] Daniele Vannozzi Daniele Vannozzi...

Massimo Ianigro Massimo Ianigro [email protected]

Daniele Vannozzi Daniele Vannozzi [email protected]

Domain Name SystemDomain Name System

22 Bologna 23 novembre 2000

le funzioni del Domain Name System lo spazio dei nomi interazioni tra nameserver e resolver interazioni tra DNS e posta elettronica

Argomenti trattatiArgomenti trattati


Domain Name System:Domain Name System:breve storiabreve 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.TXTHOSTS.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


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

DNS: le funzioniDNS: le funzioni


DNS: caratteristiche principaliDNS: 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)


Lo spazio dei nomiLo 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)


il “domain name” (nome a dominio) di ogni nodo è composto dalla sequenza delle etichette dal nodo a “ “ (root), separate da “.” (punto). Es: e.c.ae.c.a, h.g.f.d.bh.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

L’albero dei nomiL’albero dei nomi

Top Level Domain, TLDTop Level Domain, TLD

First Level DomainFirst Level Domain

Second Level DomainSecond Level Domain

..........

..........

aa bb

cc dd

ff

““.“.“

hh

ggee


I dominiI domini

per dominio si intende il sottoalbero che inizia dal nodo con il nome a dominio in questione

di solito, le foglie rappresentano il nome a dominio di un host

ai nodi sono associate le informazioni relative a quel nome a dominio (RR)

entry di host entry strutturali

nodo con nome a dominio head.acme.com

com

acme

www

duck

goofy

head

comp

sale

dominio com

dominio acme.com

dominio comp.acme.com

“.“


lo spazio dei nomi di Internet, per “tradizione” (rfc1591), è strutturato secondo un modello misto organizzazionale/geografico

i Top-Level-Domain sonodomini 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 arpanuovi domini in corso di definizione: .info, …

L’Internet Domain Name SpaceL’Internet Domain Name Space


L’Internet Domain Name SpaceL’Internet Domain Name Space

COM

MIT STANFORD

AI

PREP XX VX

ARPA

IN-ADDRBERKELEY

IT UK US NL

FIAT

RMMIIAT

LAZIOFI

COMUNE REGIONE

DNS HP4000

“.“

EDU

LCS

CNR


L’albero per la risoluzione inversaL’albero per la risoluzione inversa

48.146.in-addr.arpa dominio 65.48.146.in-addr.arpa sotto-dominio 69.65.48.146.in-addr.arpa macchina

ARPA

IN-ADDR

146128 195193

8 65

“.“

..... .....

254691

..... .....

..... .....

48


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

La delega di autoritàLa delega di autorità


Domini e zone: differenzeDomini e zone: differenze 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

“.“

com

acmegoofy

dominio comdominio com

roger

zona comzona com


Domini e zone: i nameserverDomini 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


Il “parenting”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!!

!


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

I root-serversI root-servers


Nameserver autoritativiNameserver 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: primari secondari


Nameserver primari e secondariNameserver 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


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)

CachingCaching

può dare luogo a “temporanee” inconsistenze

aumenta le performance del sistema


Il processo di risoluzione dei nomi a dominio è basato sul modello client-server:

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)

Il processo di risoluzione:Il processo di risoluzione:Nameserver e ResolverNameserver e Resolver


Il processo di risoluzione dei nomiIl processo di risoluzione dei nomi

applicazioneutente

1

DefaultNameserver

(cache vuota)

root nameserver

query per www.iat.cnr.it

“.“

IT COM

CNR UNIPI

BOIAT

www

referral al NS per it.

it. nameserver

query for www.iat.cnr.it

referral al NS per cnr.it

cnr.itnameserver

query for www.iat.cnr.it

referral al NS per iat.cnr.it

iat.cnr.it nameserver

query: www.iat.cnr.it

RR per www.iat.cnr.it

6 5

4

2

3

RESOLVER


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)

Risoluzione dei nomiRisoluzione dei nomi


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:

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

Le piattaforme hardware e Le piattaforme hardware e softwaresoftware

http://www.isc.org/bind.html


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

Le maggiori differenze tra le Le maggiori differenze tra le versioni 4 e 8versioni 4 e 8


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

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

Nuove funzionalità della versione 8.x.yNuove funzionalità della versione 8.x.y


Caratteristiche salienti di BIND 9Caratteristiche 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


Views (Bind 9)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” };};


RNDCRNDC

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; };


Differenze rispetto a BIND 8.2.2Differenze 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, STATISTICS-INTERVAL, 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


Differenze rispetto a BIND 8.2.2 Differenze rispetto a BIND 8.2.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


La posta su InternetLa posta su Internetrelazione tra SMTP e DNSrelazione 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


Mail Routing & DNSMail 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

tenta la consegna ai mailers della lista, partendo dal preference maggiore (numericamente minore).


Mail routing & DNS:Mail routing & DNS:esempioesempio

mail to user@domainA

mail to user@domainA

MTA1MTA1 MTA1MTA1

MX for domainA

DNSDNS

domainA MX 0 MTA3 MX 50 MTA2

MX 100 MTA4

MTA3MTA3 MTA3MTA3

MTA2MTA2 MTA2MTA2

MTA4MTA4 MTA4MTA4

mail delivery

domainA:LOCAL

domainA:LOCAL


Utilizzo dei record MX per il routing Utilizzo dei record MX per il routing della posta elettronicadella 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


Utilizzo dei record MX Utilizzo dei record MX 22

Internet

Firewall.domain.it

[email protected]

Host IN mx 10 host mx 20 firewall

Nella zona diNella zona di domain.it domain.it


Alcune regole pratiche per la Alcune regole pratiche per la sicurezza del namedsicurezza 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.


Utility di supporto nella gestione Utility di supporto nella gestione di un nameserverdi 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


nslookupnslookup

è 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


nslookup (2)nslookup (2)

Query per tutti i record del dominio cnr.it> nslookupDefault Server: dns.pi.cnr.itAddress: 146.48.65.2> set q=any> cnr.itServer: dns.pi.cnr.itAddress: 146.48.65.2Non-authoritative answer:cnr.it nameserver = nameserver.cnr.itcnr.it nameserver = dns2.nic.itcnr.it nameserver = itgbox.iat.cnr.itcnr.it nameserver = simon.cs.cornell.educnr.it nameserver = ns1.surfnet.nlcnr.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


hosthost

è 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 -i 146.48.65.3 host -av cnr.it nameserver.cnr.it host -avl cnr.it nameserver.cnr.it host -t soa cnr.it host -C cnr.it


host (2)host (2)

Query per tutti i record del dominio cnr.it> host -va cnr.itQuery about cnr.it for record types ANYTrying cnr.it ...Query done, 6 answers, status: no errorThe following answer is not authoritative:cnr.it 542353 IN NS nameserver.cnr.itcnr.it 542353 IN NS dns2.nic.itcnr.it 542353 IN NS itgbox.iat.cnr.itcnr.it 542353 IN NS simon.cs.cornell.educnr.it 542353 IN NS ns1.surfnet.nlcnr.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) )……


host (3)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


digdig

è 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 -h dig dns.iat.cnr.it dig dns.iat.cnr.it mx dig -x 146.48.65.3 dig @nameserver.cnr.it cnr.it


dig (2)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


dnswalkdnswalk

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’


dnswalk dnswalk (2)(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


dnswalk dnswalk (3)(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.


NDC - NDC - Name daemon controlName 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 getpidmy 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


NSUPDATENSUPDATE

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


NSUPDATE NSUPDATE (2)(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 @ IN SOA dns.ba.cnr.it. postmaster.dns.ba.cnr.it. (

1999072501 3600 1800 604800 86400 )

@ NS dns.ba.cnr.it.

@ NS area.area.ba.cnr.it.

;

WWW 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


NSUPDATE NSUPDATE (3)(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; };};


Riferimenti BibliograficiRiferimenti Bibliografici

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)


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

IlIl naming naming attuale del attuale del dominio CNR.ITdominio CNR.IT

IT

CNR

pisrc www

“.“

iat net

dnsarea

adrserv

pisa-routeriei

ieiserv


Il nuovo naming del dominio cnr.itIl 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

Un possibile utilizzo del nuovo naming Un possibile utilizzo del nuovo naming del dominio cnr.itdel dominio cnr.it

IRPI un istituto con sezioni

distribuite sul territorio nazionale


La situazione attualeLa situazione attuale

Stesso nome di dominio Irpi (eccezione attuale sede di Bari)

Un dominio per ogni sede Perugia irpi.pg.cnr.it Padova irpi.pd.cnr.it Cosenza irpi.cs.cnr.it Bari cerist.ba.cnr.it Torino irpi.to.cnr.it


Le possibili soluzioniLe 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


Alcuni elementi utili alla scelta Alcuni elementi utili alla scelta dello schema di namingdello 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


La migrazione verso il nuovo La migrazione verso il nuovo naming naming

Registrazione/delega del nuovo dominio

Verifica/Attivazione dei server dns autoritativi

per il nuovo dominio

Gestione contemporanea del vecchio naming e

nuovo naming


Interazione tra DNS e migrazioneInterazione 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

Massimo Ianigro Massimo Ianigro [email protected] Daniele Vannozzi Daniele Vannozzi...

Documents

Transcript of Massimo Ianigro Massimo Ianigro [email protected] Daniele Vannozzi Daniele Vannozzi...