DNS Dynamic Updates
Corso di reti di calcolatori e sicurezza
a.a. 2005-2006
Prof. Stefano Bistarelli
Irene Beccarini
Sommario
1. Il servizio DNS
2. L’aggiornamento dinamico:
- Lato client
- Messaggi d’aggiornamento
- Lato server
- Problemi
3. Considerazioni conclusive
Dns: Domain Name System
• Database per convertire gli hostname in indirizzi IP
• Immagazzinano record di risorse RR: correlazioni fra gli hostname e le informazioni
associate.
RR= (Name, Class, Type, TTL)
A
NS
CN
MX
Indirizzo Ip
Server dei
nomi di una
zona
Nome
Canonico
Hostname del
mailserver
SOA ( Start of
Authority )
Informazioni
relative ad una
zona
DNS ( Segue…)
• Database gerarchico e distribuito
• Suddiviso in zone:
Zona = set di records = RRset
• Ogni zona può essere composta dalle risorse di un intero dominio, di una parte o di
un sottodominio.
edu
princeton … mit
cs
ux01 ux04
ee physics
com
gov
cisco … yahoo nasa … nsf
mil
org
arpa … navy
acm … ieee
net
uk
fr
DNS ( Segue…)
•
Ogni zona può avere 2 o più Name Servers.
• Il server dei nomi che amministra una zona deve essere “autorizzato” per la zona
che gli è stata assegnata e funziona da “Start of Authority” per quella zona.
Server
Autoritativi
Name Server Primario:
Gestisce le risorse di una zona per la
quale è autoritativo.
Ce ne può essere solo uno per zona.
Name server Secondario:
Ottiene i dati dal name server primario o
da un altro name server secondario.
Contiene una copia di sola lettura del
database.
Ci può essere più di un server secondario
per zona.
Come si
aggiornano
le tabelle?!
Aggiornamento
Aggiornamento statico:
Aggiornamento dinamico:
i contenuti di ciascun DNS
sono configurati da un file di
configurazione creato da un
responsabile del sistema
• Permette l’aggiunta, l’eliminazione e la
modifica di RR o RRset da una specifica
zona mediante uno scambio di messaggi
DNS tra un Client DNS e un Server DNS;
• Riduce la necessità di gestione manuale
dei record di zona, specialmente per i
client che vengono utilizzati in sedi
diverse e che utilizzano il DHCP per
ottenere un indirizzo IP;
• Rfc 2136.
Aggiornamento dinamico
Viene richiesto generalmente quando:
• Un indirizzo IP o un nome DNS viene aggiunto, rimosso o modificato;
• Viene attribuito un indirizzo IP tramite DHCP;
• Il lease di un indirizzo IP di una connessione istallata viene modificato o
rinnovato dal server DHCP;
Porta 53
Update Request
Client DNS
Server DNS
Response
Lato Client
Server DNS
locale
Client DNS
1)
Il servizio client invia una
domanda di tipo Origine di
Autorità utilizzando il nome
di dominio del computer.
2)
Il server DNS locale
risponde alla query fornendo
il record SOA nel quale il
client troverà il DNS
primario.
Querytype = SOA
SOA
Response
Request Update
3)
Server DNS
primario
Il client DNS invia una richiesta d’aggiornamento al
server primario.
Non ci sono problemi se l’aggiornamento riesce.
A volte, però, per alcuni richiedenti, il DNS primario
non è raggiungibile a causa di firewalls o particolari
partizioni della rete.
Lato Client (segue…)
Server
DNS locale
Client DNS
Querytype = NS
4)
Il client invia una nuova
richiesta di tipo NS per
conoscere i server DNS
relativi alla zona specificata
nel SOA.
Ne riceve un elenco.
5)
Il client invia la richiesta
d’aggiornamento al primo
server autoritativo della
lista. In caso neanche
questo risponda riproverà
con tutti gli altri server
dell’elenco.
Servers DNS
Server DNS
autoritativo
Client DNS
Update Request
Lato Client (segue…)
Server
Primario
Server DNS
autoritativo
Server DNS
autoritativo
Update Request
Update Request
Response
Response
Response
6)
Il server autoritativo contattato forwarderà la
richiesta al server primario tramite
eventualmente altri server autoritativi
secondari e rimanderà indietro la risposta al
richiedente, passando per tutti i server
intermedi intervenuti.
… Bugia !!!
Per i client in cui è in esecuzione un sistema operativo che utilizza il
DHCP per ottenere il proprio indirizzo IP, il processo è diverso!
Sarà il Client DHCP, non il Client DSN, ad inviare le richieste
d’aggiornamento e a compiere tutte le operazioni precedenti.
Richiesta IP
Server DHCP
Client DHCP
Indirizzo IP
Update IP
Server DNS
Dns Update Messages
Header
Zone
Specifica che il msg è un’aggiornamento
Specifica la zona da aggiornare
Prerequisite
Records che devono essere presenti
Update
Records da aggiungere, eliminare o
modificare
Additional Data
Dati aggiuntivi
Sezione Dati Addizionali
Contiene:
- i records che sono collegati alla fase d’aggiornamento;
- i records collegati a quelli che devono essere aggiunti.
Intestazione
Del client che genera la richiesta di update
ID
QR
OpCode
Z
RCode
ZoCount
PrCount
0 -richiesta
QR
OpCode
1 -risposta
5 -aggiornamento
UpCount
AdCount
Z
RCode
ZoCount: #RR sezione Zona
PrCount: #RR sezione Prerequisiti
UpCount: #RR sezione Update
AdCount: #RR sezione Dati Addizionali
0 -riservato a un uso futuro
Codice di risposta
Sezione Zona
• Definisce la zona dei record che devono essere aggiornati tramite un
unico record dai campi ( Zname, Ztype, Zclass );
• Tutti i record che devono essere aggiornati devono appartenere alla
stessa zona.
Sezione Prerequisiti
• Contiene i prerequisiti che devono essere soddisfatti per poter procedere
all’aggiornamento. Può essere richiesto che:
- esista o non esista un particolare RRset;
- la zona in questione contenga o meno altri dati.
Sezione Aggiornamento
• Contiene i record da aggiungere o eliminare dalla zona
• Sono possibili 4 operazioni:
Add to an RRset :
Delete an RR :
aggiunge il nuovo
record ad una zona
elimina i records
indicati
Delete an RRset :
elimina tutti i record
della zona i cui nome e
tipo sono quelli del
record indicato in questa
sezione
Delete all Rrset from a
name :
elimina tutte i record della
zona con lo stesso nome del
record inserito in questa
sezione
Lato server
Client DNS
Update
request
NOTIMP
1. Analisi OpCode:
If OpCode = non valido o
non implementato
return NOTIMP
Server
Lato Server (segue…)
FORMERR
(format error)
2. Controllo Sezione Zona:
NOTAUTH
(non autorizzato)
La zona da aggiornare deve essere una
zona d’autorità.
If (zcount != 1 || ztype = SOA)
return (FORMERR)
return (NOTAUTH)
Deve essere nelle zone d’autorità del server
che ha ricevuto la richiesta.
-
if (zone-type(zname, zclass) = = Slave)
return forward( )
-
if (zone-type(zname, zclass) = = Master)
return update( )
se è un NS secondario passa la richiesta
al NSprimario;
se è l’NS primario procede
all’aggiornamento.
Lato Server (segue…)
Server
Primario
3. Analisi Sezione Prerequisiti:
Tutti i prerequisiti devono essere
soddisfatti dallo stato corrente della
zona.
FORMERR
(errori formali)
NOTZONE
NXDOMAIN/
YXDOMAIN
NXRRSET/
YXRRSET
I nomi dei record non sono entro la zona
che deve essere aggiornata: si può far
riferimento solo a record dentro la zona.
Qualche nome che dovrebbe/non dovrebbe
esistere non esiste/esiste
Qualche set che dovrebbe/non dovrebbe
esistere non esiste/esiste
Lato server (segue…)
4. Controllo permesso del richiedente:
E’ implementato solo se a tale protocollo si
affianca il Secure DNS Update Protocol.
Il server dà avvio al controllo
REFUSED
?
Dà avvio
all’aggiornamento…
!
Richiedente
non autorizzato
Richiedente
non autorizzato
Invia un segnale
di rifiuto
aggiornamento
Richiedente
autorizzato
Lato server (Update Section)
5. Prescan:
Si analizza la sezione contenente gli
aggiornamenti da operare
NOTZONE
I nomi dei record da inserire non sono nella
zona specificata
FORMERR
Il campo TYPE deve essere definito, non
sconosciuto e non un tipo di query
Lato Server (segue…)
6. Update:
Opera gli aggiornamenti indicati in
questa sezione in ordine.
SERVFAIL
Se interviene qualche guasto del sistema
l’aggiornamento viene bloccato e si ripristina la
situazione di partenza
CLASS TYPE RDATA Operazione
--------------------------------------------------------ANY
ANY
empty
Delete all RRsets from a name
ANY
rrset
empty
Delete an RRset
NONE
rrset
rr
Delete an RR from an RRset
zone
rrset
rr
Add to an RRset
NOERROR
-
Non è possibile
cancellare SOA o NS
records se sono alla
radice della zona;
-
Non è possibile
aggiungere un nuovo
record SOA.
Lato server: caratteristiche
• Risposta: alla fine dell’aggiornamento il server invia un msg con il codice di
risposta alla porta UDP sorgente del richiedente o alla connessione TCP aperta dello
stesso.
ID
(specificato nella richiesta)
OpCode
QR = 1
Z RCode
( della richiesta)
Zcount
( della richiesta)
PRCount
( della richiesta )
UPCount
( della richiesta )
AdCount
( della richiesta )
Possono semplicemente
essere settati a 0
Lato Server: caratteristiche ( segue…)
Il processo di update assicura:
• Stabilità:
- Ogni modifica viene subito memorizzata;
- Il servizio DNS non usa meccanismi per rilasciare o eliminare definitivamente i record
che non vengono aggiornati o i nomi che diventano inattivi.
• Zone esattamente identificabili: tramite un SOA SERIAL ( numero della copia
originale della zona ) che viene aggiornato:
- ad ogni operazione di update ;
- al cambiamento di qualsiasi nome della zona;
- dopo un periodo prestabilito.
• Sequenzialità: due operazioni, di cui una dipende dall’altra, non possono essere
processate insieme.
Problemi
1. Richieste duplicate di modifica:
Una serie di aggiornamenti in sequenza sugli stessi dati potrebbe lasciare la
zona in uno stato indefinito.
E’ possibile specificare nella sezione prerequisiti un record della tabella che
vogliamo aggiornare che useremo come “marker RR”. Se è assente non si
potrà dare vita all’aggiornamento.
Nella sezione update (dove vengono inseriti i record da modificare) andremo a
cancellare il record che abbiamo segnato come marker e ad aggiungerne
uno nuovo.
Se dovesse arrivare un’altra richiesta duplicata, non si potrebbe dare avvio
all’update in quanto la tabella non conterrebbe ormai più il marker
originale.
Problemi
2. Ordine delle richieste d’aggiornamento:
Le richieste d’aggiornamento potrebbero arrivare al server in un ordine diverso
da quello di invio.
E’ possibile ovviare a questo problema usando valori crescenti per i “marker
RR” tramite la sincronizzazione operata su una base temporale visibile da un
certo set di richiedenti.
Problemi (segue…)
Un metodo per ovviare ad entrambi i problemi e assicurare un ottimo ciclo di
multitransazioni “lettura-modifica-scrittura” è creare un messaggio contenente tra
i prerequisiti il record SOA della zona da aggiornare.
Se la transazione avrà successo, dopo l’aggiornamento il SOA SERIAL risulterà
incrementato:
- Non è possibile ripetere lo stesso aggiornamento perché i prerequisiti non sono più
soddisfatti (richieste duplicate di modifica)
- Non è possibile che quegli stessi dati da modificare siano già stati alterati da altri
precedentemente.
Se così fosse stato l’update non avrebbe potuto aver luogo perché il valore del SOA
SERIAL non sarebbe stato quello contenuto nel record SOA dei prerequisiti (ordine
delle richieste).
Osservazioni
• E’ lasciato alla discrezione del richiedente l’utilizzo di un trasferimento
UDP o TCP:
Qualora necessiti di un accurato codice di risposta è bene che inizi la
transazione usando il TCP.
Tutti i server forwarder useranno di conseguenza il TCP per il trasferimento
della richiesta e della risposta.
• Qualora il richiedente decida di usare l’UDP i server forwarder potranno
usare l’ UDP o il TCP.
Riferimenti
- www.dns.net
- www.microsoft.com
- www.cefriel.it
- http://bertola.eu.org
- www.wikipedia.org
Grazie
dell’attenzione!