“Le 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.
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.
Lascia un commento