Propagazione DNS: cos'è e come ridurne l'impatto

La propagazione DNS è il periodo in cui alcuni resolver continuano a servire il vecchio valore di un record dopo che è stato modificato sul name server autoritativo. Non è una diffusione: ogni resolver conserva la risposta in cache fino alla scadenza del TTL. Il ritardo va da pochi minuti a 24 o 48 ore per un cambio di name server, in base al TTL del record prima della modifica e, per i name server, al TTL di delega fissato dal registro. Ecco come funziona e come limitarne l'impatto.

In breve

La modifica è visibile subito sul server autoritativo. Il ritardo dipende solo dalle cache dei resolver, che tengono il vecchio valore fino alla scadenza del suo TTL.
La durata del vecchio valore è fissata dal TTL in vigore prima della modifica, non da quello appena inserito. Abbassatelo in anticipo.
Il cambio di name server è il più lento, perché dipende dal TTL di delega del registro, che non controllate.
Anche gli errori «questo nome non esiste» finiscono in cache: visitare un nome prima di creare il suo record può prolungare l'errore.

Cosa non è la propagazione DNS: una diffusione

Il termine è fuorviante. Nessun server invia la vostra modifica agli altri. Quando salvate una modifica presso il provider DNS, il name server autoritativo della zona serve subito il nuovo valore. Il ritardo si gioca altrove, nelle cache.

Quando un dispositivo cerca l'indirizzo di un nome di dominio, la richiesta attraversa più livelli, e ciascuno può ricordare la risposta:

il browser, la cui cache dura di norma circa un minuto e non sempre rispetta il TTL;
il sistema operativo, che conserva le risposte recenti;
il resolver ricorsivo, del provider di accesso o pubblico (per esempio 8.8.8.8 di Google o 1.1.1.1 di Cloudflare), che percorre la gerarchia DNS e poi memorizza il risultato.

Ogni resolver applica il TTL indicato dal server autoritativo nel momento in cui ha messo la risposta in cache. Poiché non hanno interrogato il server tutti insieme, le loro copie scadono in momenti diversi. Un record con TTL di 3600 secondi, messo in cache 5 minuti fa, verrà rinnovato tra 55 minuti. Da qui i riscontri contraddittori: uno vede il nuovo sito, un altro il vecchio, un terzo un errore.

Quanto dura una propagazione DNS

La durata dipende dal tipo di modifica. Un TTL di un giorno (86.400 secondi) è comune, e i valori sono più alti per i record che cambiano raramente, come i name server.

Tipo di modifica	Durata abituale	Cosa la determina
Modifica di un record esistente (A, AAAA, CNAME, MX, TXT)	Fino alla durata del vecchio TTL, da pochi minuti a 24 ore a seconda della configurazione	Il TTL in vigore prima della modifica
Creazione di un record che non esisteva	Variabile, di solito poche ore al massimo	Il SOA della zona (TTL del SOA e campo MINIMUM)
Cambio dei name server presso il registrar	Da qualche ora a 48 ore	Il TTL di delega del registro, spesso da uno a due giorni
Resolver con limiti propri	Può superare il TTL dichiarato	Un tetto o un minimo configurato (86.400 s di default per Unbound, 604.800 s per BIND)

I tre fattori che decidono il ritardo

Il TTL di prima della modifica

Immaginate un record con TTL di 86.400 secondi che oggi portate a 300. Un resolver che lo ha memorizzato ieri tiene il vecchio valore fino a 24 ore, qualunque sia il nuovo valore: il TTL di 300 secondi si applica solo dopo il rinnovo della sua copia. Per un CNAME, ogni nome della catena ha il proprio TTL, e il più lungo determina il ritardo complessivo.

La delega presso il registro

Quando cambiate i name server, la modifica si fa presso il registrar, che la trasmette al registro del dominio di primo livello. I resolver che conoscono ancora il vecchio elenco di name server continuano a interrogarli fino alla scadenza della delega. Questo TTL appartiene al registro: non potete accorciarlo.

I resolver che non seguono il TTL alla lettera

Alcuni resolver limitano o alzano i TTL, e i browser hanno una cache propria di breve durata. Non si può garantire la stessa durata ovunque. Il TTL è un limite teorico, non una promessa di tutte le cache.

La trappola della cache negativa

La maggior parte delle guide parla del TTL dei record e dimentica le risposte negative. Quando un resolver scopre che un nome non esiste (risposta NXDOMAIN) o che non ha record del tipo richiesto, può ricordare questa assenza. La RFC 2308 fissa la durata della cache negativa al minore tra due valori: il TTL del SOA della zona e il suo campo MINIMUM. Considera ragionevoli durate da una a tre ore e avverte che oltre un giorno si creano problemi.

Lo scenario tipico: provate nuovo.example.com prima di creare il record, ottenete un errore, poi create il record. Per il vostro resolver il nome «non esiste» finché la cache negativa non termina, anche se il record è attivo da un minuto. Come evitarlo:

create il record prima di provare o annunciare il nome;
se il vostro provider DNS permette di regolare il SOA, tenete un campo MINIMUM moderato;
svuotate la cache locale prima di concludere che «non funziona»: Microsoft precisa che ipconfig /flushdns elimina anche le voci di cache negative.

Metodo per limitare l'impatto di una migrazione

Annotate il TTL attuale di ogni record interessato (vedi i comandi più sotto). È lui a fissare il ritardo.
Abbassate il TTL a 300 secondi, con un anticipo almeno pari alla durata del vecchio TTL. Con 86.400 secondi, fatelo 24-48 ore prima del passaggio. Verificate il minimo accettato dal provider.
Preparate la nuova destinazione: sito, server di posta o CDN pronto a rispondere con lo stesso contenuto del precedente. Entrambi devono funzionare durante la transizione.
Cambiate il record, una modifica alla volta per sapere cosa controllare.
Verificate prima il server autoritativo, poi i resolver pubblici.
Tenete attivo il vecchio server almeno fino al termine del più lungo vecchio TTL, poi spegnetelo.
Rialzate il TTL (3600 secondi o più) quando tutto è stabile.

Per un cambio di name server, ricreate prima l'intera zona presso il nuovo provider (A, CNAME, MX, TXT inclusi SPF e DKIM, e tutto il resto), verificate che risponda correttamente, poi cambiate i name server presso il registrar. Lasciate la zona del vecchio provider online e identica per 48 ore: i resolver che conoscono ancora la vecchia delega continuano a interrogarla.

Verificare cosa vede ogni resolver

Il comando dig (macOS, Linux) o nslookup (Windows) permette di confrontare le risposte del server autoritativo e di diversi resolver pubblici.

# Valore e TTL residuo visti dai resolver pubblici
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Name server dichiarati per il dominio
dig +short NS example.com

# Valore servito dal server autoritativo (sostituite con il vostro name server)
dig +noall +answer example.com A @ns1.provider-dns.example

# Numero di serie del SOA, da confrontare tra i name server
dig +short SOA example.com @ns1.provider-dns.example
dig +short SOA example.com @ns2.provider-dns.example

# Equivalente su Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

Nella risposta di un resolver, il TTL mostrato diminuisce da una richiesta all'altra: è il tempo che manca alla scadenza della sua copia. Se un resolver restituisce il vecchio valore con un TTL che continua a scendere mentre il server autoritativo restituisce già il nuovo, basta aspettare.

Confrontate anche il numero di serie del SOA tra i vostri name server. Se differiscono, un server serve dati obsoleti: il problema è del provider DNS, non della propagazione. La pagina dns.google permette di interrogare un tipo di record preciso, SOA compreso, e la guida alla risoluzione dei problemi di Google Public DNS descrive questa verifica.

Svuotare le cache che controllate

Svuotare la propria cache non cambia nulla per gli altri visitatori, ma permette di verificare cosa vedete davvero.

# Windows (prompt dei comandi)
ipconfig /flushdns

# macOS recente
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux con systemd-resolved
resolvectl flush-caches

Microsoft descrive /flushdns e /displaydns nella pagina del comando ipconfig. Poi chiudete completamente il browser, che conserva una memoria propria di breve durata.

Due resolver pubblici offrono anche una purga, utile dopo un cambio di name server o per chi li usa: lo strumento Flush Cache di Google Public DNS (Google consiglia di svuotare sia il dominio registrato sia il nome preciso che restituisce una risposta obsoleta) e la purga della cache di 1.1.1.1 di Cloudflare, dove si sceglie il dominio e il tipo di record. I resolver dei provider di accesso non si possono svuotare: bisogna attendere la scadenza delle loro copie.

Errori frequenti

Abbassare il TTL al momento del passaggio. È troppo tardi: i resolver tengono la copia fatta con il vecchio TTL.
Provare il nome prima di creare il record. La cache negativa può prolungare l'errore.
Cambiare i name server prima di ricreare tutta la zona. I record di posta o dei sottodomini dimenticati smettono di funzionare per i resolver che interrogano già il nuovo provider.
Spegnere troppo presto il vecchio server. I visitatori la cui cache non è scaduta arrivano su un server che non risponde più.
Dichiarare conclusa la propagazione dal proprio computer. La cache locale non rappresenta gli altri resolver.
Lasciare un TTL molto basso in modo permanente. Moltiplica le richieste ai vostri name server. Rialzatelo a migrazione conclusa.

Domande frequenti

Quanto dura la propagazione DNS?

Per la modifica di un record, al massimo la durata del vecchio TTL: un'ora con TTL di 3600 secondi, 24 ore con 86.400. Per un cambio di name server, da qualche ora a 48 ore. La maggior parte dei resolver si aggiorna ben prima del termine massimo. Restano solo alcune cache in ritardo.

Si può accelerare la propagazione DNS?

Non su tutta Internet: non si possono forzare le cache altrui. Si può abbassare il TTL prima della modifica, svuotare i resolver pubblici di Google e Cloudflare e le proprie cache. I resolver dei provider di accesso non si possono svuotare.

Quale TTL scegliere prima di una migrazione?

Un valore breve come 300 secondi (5 minuti), applicato almeno per la durata del vecchio TTL prima del passaggio. A migrazione stabile, rialzatelo a 3600 secondi o più: un TTL molto basso e permanente moltiplica le richieste. Verificate il minimo accettato dal provider DNS.

Perché il mio collega vede il nuovo sito e io no?

Passate da resolver diversi, che hanno memorizzato la risposta in momenti diversi. Interrogate lo stesso resolver pubblico da entrambe le postazioni per confrontare, poi svuotate la cache locale della postazione che vede ancora la vecchia versione.

Cosa succede alla mia posta durante la propagazione?

Una modifica del record MX segue le stesse regole: durante il ritardo, alcuni mittenti scrivono ancora al vecchio server di posta. Tenetelo attivo fino al termine della transizione. Se un server non è disponibile, i server mittenti di norma conservano i messaggi e riprovano per diversi giorni.

Bisogna svuotare la cache del computer?

Sì, per verificare cosa vedete voi, ma non cambia nulla per gli altri visitatori. Usate il comando del vostro sistema, poi chiudete completamente il browser. Se il valore è ancora vecchio, la copia è nel resolver del vostro provider di accesso.

Perché gli strumenti online di verifica danno risultati diversi?

Ognuno interroga resolver di paesi diversi, che hanno memorizzato la risposta in momenti diversi. Un risultato misto è normale finché il TTL non è scaduto ovunque. Se sono gli stessi name server autoritativi a rispondere in modo diverso, confrontate i numeri di serie del SOA: il problema è allora nella zona, non nella propagazione.