DNS Dynamic Updates

1
DNS Dynamic Updates

• Corso di reti di calcolatori e sicurezza
• a.a. 2005-2006
• Prof. Stefano Bistarelli
• Irene Beccarini

2
Sommario
1. Il servizio DNS 2. Laggiornamento
dinamico - Lato client - Messaggi
daggiornamento - Lato server -
Problemi 3. Considerazioni conclusive
3
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)
NS Server dei nomi di una zona
CN Nome Canonico
MX Hostname del mailserver
A Indirizzo Ip
SOA ( Start of Authority ) Informazioni relative
ad una zona
4
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.

5
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.

Name Server Primario Gestisce
le risorse di una zona per la quale è
autoritativo. Ce ne può essere solo uno per zona.
Server Autoritativi
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.
6
Come si aggiornano le tabelle?!
7
Aggiornamento

• Aggiornamento dinamico
• Permette laggiunta, leliminazione 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 statico i contenuti di ciascun
DNS sono configurati da un file di configurazione
creato da un responsabile del sistema
8
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
9
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
Request Update
Response

1. Il client DNS invia una richiesta daggiornamento
   al server primario.
   
   Non ci sono problemi se laggiornamento riesce.
   A volte, però, per alcuni
   richiedenti, il DNS primario non è raggiungibile
   a causa di firewalls o particolari partizioni
   della rete.

Server DNS primario
10
Lato Client (segue)
Server DNS locale
Client DNS

1. Il client invia una nuova richiesta di tipo NS
   per conoscere i server DNS relativi alla zona
   specificata nel SOA.
   Ne riceve un elenco.

Querytype NS
Servers DNS
Server DNS autoritativo
Client DNS

1. Il client invia la richiesta daggiornamento al
   primo server autoritativo della lista. In caso
   neanche questo risponda riproverà con tutti gli
   altri server dellelenco.

Update Request
11
Lato Client (segue)
Server Primario
Server DNS autoritativo
Server DNS autoritativo
Update Request
Update Request
Response
Response
Response

1. 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.

12
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 daggiornamento e a compiere
tutte le operazioni precedenti.
Richiesta IP
Server DHCP
Client DHCP
Indirizzo IP
Update IP
Server DNS
13
Dns Update Messages
Header
Specifica che il msg è unaggiornamento
Zone
Specifica la zona da aggiornare
Prerequisite
Records che devono essere presenti
Records da aggiungere, eliminare o modificare
Update
Additional Data
Dati aggiuntivi
Sezione Dati Addizionali
Contiene - i records che sono collegati alla
fase daggiornamento - i records collegati a
quelli che devono essere aggiunti.
14
Intestazione
ID
Del client che genera la richiesta di update
QR
OpCode
RCode
Z
0 -richiesta 1 -risposta
QR
ZoCount
PrCount
OpCode
5 -aggiornamento
UpCount
Z
0 -riservato a un uso futuro
AdCount
RCode
Codice di risposta
ZoCount RR sezione Zona PrCount RR sezione
Prerequisiti UpCount RR sezione Update
AdCount RR sezione Dati Addizionali

15
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
  allaggiornamento. Può essere richiesto che

- esista o non esista un particolare RRset - la
zona in questione contenga o meno altri dati.
16
Sezione Aggiornamento

• Contiene i record da aggiungere o eliminare
  dalla zona
• Sono possibili 4 operazioni

Delete an RR elimina i records indicati
Add to an RRset aggiunge il nuovo record ad una
zona
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
17
Lato server
Client DNS
Update request
NOTIMP
1. Analisi OpCode If OpCode non valido o
non
implementato return NOTIMP
Server
18
Lato Server (segue)
FORMERR (format error)
2. Controllo Sezione Zona If (zcount !
1 ztype SOA) return (FORMERR)
return (NOTAUTH) if
(zone-type(zname, zclass) Slave) return
forward( ) if (zone-type(zname, zclass)
Master) return update( )
NOTAUTH (non autorizzato)
La zona da aggiornare deve essere una zona
dautorità. Deve essere nelle zone dautorità del
server che ha ricevuto la richiesta.

- se è un NS secondario passa la
richiesta al NSprimario
- se è
lNS primario procede allaggiornamento.
19
Lato Server (segue)
Server Primario
3. Analisi Sezione Prerequisiti Tutti i
prerequisiti devono essere soddisfatti dallo
stato corrente della zona.
FORMERR (errori formali)
I nomi dei record non sono entro la zona che deve
essere aggiornata si può far riferimento solo a
record dentro la zona.
NOTZONE
Qualche nome che dovrebbe/non dovrebbe esistere
non esiste/esiste
NXDOMAIN/YXDOMAIN
Qualche set che dovrebbe/non dovrebbe esistere
non esiste/esiste
NXRRSET/YXRRSET
20
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
Richiedente autorizzato
?
Richiedente non autorizzato
Invia un segnale di rifiuto aggiornamento
Dà avvio allaggiornamento
!
Richiedente non autorizzato
21
Lato server (Update Section)
5. Prescan Si analizza la sezione contenente gli
aggiornamenti da operare
I nomi dei record da inserire non sono nella zona
specificata
NOTZONE
Il campo TYPE deve essere definito, non
sconosciuto e non un tipo di query
FORMERR
22
Lato Server (segue)
6. Update Opera gli aggiornamenti indicati in
questa sezione in ordine.
Se interviene qualche guasto del sistema
laggiornamento viene bloccato e si ripristina la
situazione di partenza
SERVFAIL
- Non è possibile cancellare SOA o NS records se
sono alla radice della zona - Non è possibile
aggiungere un nuovo record SOA.
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
23
Lato server caratteristiche

• Risposta alla fine dellaggiornamento 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)
QR 1
OpCode ( della richiesta)
Z
RCode
Zcount ( della richiesta)
PRCount ( della richiesta )
Possono semplicemente essere settati a 0
UPCount ( della richiesta )
AdCount ( della richiesta )
24
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 dallaltra, non possono essere processate
  insieme.

25
Problemi

• 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 allaggiornamento.
• 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 unaltra richiesta duplicata,
  non si potrebbe dare avvio allupdate in quanto
  la tabella non conterrebbe ormai più il marker
  originale.

26
Problemi
2. Ordine delle richieste daggiornamento Le
richieste daggiornamento 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.
27
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
  laggiornamento 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 lupdate non avrebbe potuto
  aver luogo perché il valore del SOA SERIAL non
  sarebbe stato quello contenuto nel record SOA dei
  prerequisiti (ordine delle richieste).

28
Osservazioni

• E lasciato alla discrezione del richiedente
  lutilizzo 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 lUDP i
  server forwarder potranno usare l UDP o il TCP.

29
Riferimenti

• www.dns.net
• www.microsoft.com
• www.cefriel.it
• http//bertola.eu.org
• www.wikipedia.org

30
Grazie dellattenzione!