La propagazione del DNS

Dolci riflessi a DolceacquaLe modifiche sono a posto, ora deve aspettare 48 ore perché si propaghino

Ve l’hanno detto talmente tante volte che il concetto che il DNS si deve propagare in 48 ore è radicato nella mente di tutti, anche di alcuni SysAdmin.

Eppure nessuno (o pochi) si è mai chiesto come mai riesco a parlare in tempo reale con l’altro lato del mondo, riesco a scaricare in pochi istanti un’immagine da un server remoto, riesco ad inviare velocemente una mail, ma ci vogliono due giorni per far propagare una modifica del DNS, manco le portassero UPS o DHL con consegne overnight da un server all’altro.

Le 48 ore sono in parte un retaggio storico in parte un modo per pararsi le terga da parte del gestore ed è un valore che può essere cambiato a piacere.

Innanzi tutto, una panoramica veloce su come funziona il sistema dei nomi a dominio (domain name system, DNS), regolato da una serie di database gerarchici.

Per risolvere un nome come www.acme.com il client DNS deve eseguire una serie di interrogazioni. Si parte leggendo la tabella dei root DNS, che deve essere a disposizione del resolver. Quella tabella dice quali sono i DNS da cui iniziare le ricerche di un nome. Nel mio esempio, interrogo uno dei root DNS e chiedo quale sia il server DNS che rappresenta l’autorità (authoritative DNS) per il dominio di primo livello .com. Una volta ottenuta la risposta, interrogo il server DNS autorità di .com per chiedere quale sia il server che rappresenta l’autorità di acme.com. Ottenuta anche questa risposta, contatto il server DNS autorità di acme.com e mi faccio dire qual è l’indirizzo IP di www.acme.com.

È facile capire che se ogni volta che un programma deve andare in rete per contattare una risorsa deve fare tutto questo cinema di interrogazioni, dovremmo avere una Internet parallela solamente per la risoluzione dei nomi a dominio.

La soluzione ovvia è fare una cache dei risultati, ovvero mettere da parte i dati raccolti per poterli riutilizzare. Abbiamo quindi una serie di cache che intervengono nel risultato della risoluzione dei nomi:

  • la cache dell’applicativo, come ad esempio il browser;
  • la cache del client DNS del sistema operativo;
  • la cache del DNS a cui si appoggia il sistema operativo.

Per evitare latenze eccessive dei dati nelle varie cache, il sistema dei nomi a dominio prevede che ogni informazione rilasciata abbia una scadenza (TTL, time to live) espressa in secondi. Se provo adesso dal mio computer a chiedere l’IP di siamogeek.com ottengo qualcosa come questo (sono state omesse le parti che non interessano):

$ dig -t a siamogeek.com
;; ANSWER SECTION:
siamogeek.com.		1696	IN	A	84.19.182.37

Nella risposta è contenuto un numero, 1696, che si riduce se ripeto la richiesta dopo poco. Quello è il TTL del record, ovvero i secondi di validità di quella informazione. In parole povere, la domanda è “Qual è l’IP di siamogeek.com?” e la risposta è “L’IP è 84.19.182.37; puoi usare questo dato senza chiedermelo di nuovo per altri 1696 secondi, poi devi scartarlo e rifare un’altra richiesta.”

Il valore del TTL dei record è specificato nella zona (l’insieme delle informazioni di un dominio registrate in un server DNS) del nome a dominio presente sul server DNS che rappresenta l’autorità per quel nome a dominio. Per molti di voi è un numero nella colonna TTL nel pannello di amministrazione del DNS come questo:

1800 secondi di TTL significa che ogni modica che io faccio alla zona siamogeek.com non si propaga (ovvero scadono i TTL dei record presenti nelle varie cache) in 48 ore, ma al massimo in 30 minuti.

Si può, naturalmente, forzare un DNS server, un DNS client o un applicativo a fare tabula rasa della cache:

  • se l’applicativo non prevede un comando specifico è sufficiente chiuderlo e rilanciarlo;
  • la cache del client DNS di Windows può essere scaricata con il comando nbtstat -R (la R del parametro deve essere maiuscola);
  • la cache di un DNS server di riferimento per una LAN viene ripulita o con un comando apposito oppure riavviando il demone o servizio.
Va da sé che se non si ha il controllo del resolver a cui ci si appoggia e si usano quelli del provider, di Google o altri, l’unica opzione è attendere la scadenza del TTL del record presente sul resolver di riferimento.

Una delle conclusioni che si traggono dalla conoscenza del funzionamento del sistema dei nomi a dominio è che quando si fa una modifica come il cambiamento dell’IP del server web, i primi a recepirla sono quelli che non hanno visitato di recente il sito, in quanto non hanno in cache l’informazione oppure se ce l’hanno è scaduta. Chi ha visitato di recente il sito, invece, sarà tra gli ultimi a vedere il cambiamento.

Se il proprio fornitore lo permette e se il TTL della zona è elevato, una settimana prima di eventuali cambiamenti è bene mettere il TTL dei record ad un valore basso, come 1800 o 3600 secondi. In questo modo le modifiche saranno recepite (ovvero “si propagheranno”) entro 30 o 60 minuti al massimo. Abbassare il TTL significa aumentare il carico di traffico del server di autorità del nome a dominio; è quindi buona cosa valutare bene queste modifiche se il server in questione si trova su una linea con banda limitata o con tariffazione aggiuntiva in caso di superamento di certe soglie di traffico.

Autore: Luigi Rosa

Consulente IT, sviluppatore, SysAdmin, cazzaro, e, ovviamente, geek.

14 pensieri riguardo “La propagazione del DNS”

  1. Ottimo ed esauriente articolo su un argomento che per molti è ostico.

    Comunque credo che e il “pararsi le terga” rimanga la ragione principale 🙂

    Quanto a tenere un DNS autoritativo di un dominio di secondo livello su una linea “a banda limitata o con tariffazione a traffico” immagino che al giorno d’oggi sia una situazione abbastanza rara soprattutto se diventa critica per il traffico piuttosto modesto generato dalle query DNS.
    In questi casi se si vuole mantenere il controllo sul dominio si può tenere “unpublicised” il DNS primario e pubblicare solo i secondari magari utilizzando affidabili servizi di DNS secondari online (anche per una questione di prestazioni e latenza).

    Per quanto riguarda l’abbassamento del TTL ricordo (giusto per fare un po’ di polemica) che la nostra RA imponeva determinati parametri minimi fino a qualche tempo fa….. pena il fallimento del check automatico obbligatorio sui DNS all’atto della registrazione!

    1. Non ricordarmi i limiti imposti dal GARR… Sai le volte che nel 1995 o 1996 non mi andava a buon fine un check perché copiavo le zone di un .COM?

      Va bene pararsi le terga, ma se metti un TTL da 3600 e dici “48 ore” crei allarmismi inutili, a meno di non voler poi fare quello che ha sistemato le cose in una frazione del tempo previsto 🙂

      1. Hai assolutmanete ragione, ma nel non lontano 2006 è capitato anche a me di “pararmi le terga” a ragion veduta.
        E’ accaduto infatti che le modifiche al dominio in questione diventassero effettive entro 5 minuti per tutto il mondo meno che per qualche centinaio di migliaia di utenti di un grosso provider italiano di cui non voglio fare il nome…. che a quanto pare aveva delle cache assolutamente irrispettose del TTL dichiarato dai miei DNS.
        Sapendoli in anticipo da esperienze precedenti ho preferito informare il cliente che “in alcuni casi” la propagazione sarebbe stata un po’ lenta.

        1. La riscrittura del TTL da parte di alcuni provider perché qualche “ottimizzatore” pensa di risparmiare banda sarebbe da punire con 50 frustate.

        2. Stavo per inserire fondamentalmente lo stesso commento, ma vedo che l’ hai gia` messo tu. Ci sono provider che se ne fregano del TTL (e anche proxy che se ne fregano del TTL, mi pare di ricordare qualche versione di qualche porcheria Microsoft),

      2. Non lamentarti del GARR.
        Hanno da qualche tempo (poco) finalmente tolto l’obbligo dell’invio del Fax.
        Stanno progredendo… 🙂

        K.

        1. Esatto, che però negli ultimi anni è il teorema di chi non sa pianificare correttamente le attività. Ok un 10% di delta, ma sparare 48 ore quando ne bastano due o tre…..

  2. A me fa proprio impazzire l’idea che i DNS si “propaghino”. 😀
    Spesso un sito migrato non è visibile perché semplicemente il provider non ha ancora fatto gli aggiornamenti necessari… intanto la tua web agency ti dice che occorre aspettare i “tempi di propagazione”, facendoti credere che ci sia dietro chissà quale fisiologia naturale del web.

Spazio per un commento