Propagazione DNS: quanto tempo ci vuole davvero?
Di CaptainDNS
Pubblicato il 26 marzo 2026
- La "propagazione DNS" non esiste come meccanismo: il DNS non spinge nulla. Sono le cache dei resolver che scadono in base al TTL (Time To Live) configurato dall'amministratore di zona.
- Il tempo reale dipende dal TTL del record modificato: 1 minuto (TTL 60) fino a 24 ore (TTL 86400). Nessuna ragione tecnica giustifica un ritardo di 48 ore.
- Abbassare il TTL a 300 secondi 48 ore prima di una modifica DNS elimina il mito delle "24-48 ore". Dopo la modifica, il nuovo record è visibile ovunque in 5 minuti.
- Verificare in tempo reale con uno strumento multi-resolver permette di confermare che la modifica è effettiva, resolver per resolver.
"Prevedi 24-48 ore per la propagazione DNS." Se hai già modificato un record DNS, hai letto questa frase. Nelle pagine di assistenza del tuo registrar, in un ticket di supporto o in un tutorial trovato tramite un motore di ricerca. È probabilmente il consiglio tecnico più ripetuto su Internet. È anche uno dei più fuorvianti.
Il DNS non "propaga" nulla. Non esiste alcun meccanismo di diffusione nel protocollo che spinga le modifiche verso i resolver di tutto il mondo. Ciò che esiste è un sistema di cache distribuito con un orologio di scadenza: il TTL. Quando modifichi un record, i resolver che hanno il vecchio valore in cache continuano a servirlo fino alla scadenza del TTL. Poi interrogano il server autoritativo e ottengono il nuovo valore. Niente di più.
Il ritardo percepito è interamente controllabile. Se il TTL è di 5 minuti, la modifica è visibile ovunque in 5 minuti. Se è di 24 ore, bisogna attendere 24 ore. La cifra "48 ore" non corrisponde a nessun valore di TTL standard. Proviene dagli inizi del DNS commerciale. I registrar imponevano TTL di 86.400 secondi (24 ore) e i resolver degli ISP aggiungevano talvolta i propri ritardi.
Questo articolo analizza il meccanismo reale, quantifica i tempi esatti per ogni valore di TTL e ti fornisce un metodo di migrazione DNS che rende il ritardo prevedibile e controllato.
Verifica la tua propagazione DNS
Il mito delle "24-48 ore"
Da dove viene questa cifra?
Per capire l'origine del mito, bisogna risalire agli anni 2000. A quell'epoca, i registrar come Network Solutions, GoDaddy o Gandi configuravano TTL predefiniti di 86.400 secondi (24 ore) sui record che gestivano. Alcuni registri di TLD (come VeriSign per .com e .net) aggiornavano i file di zona ogni 12 ore. Sommando questi due fattori, un cambio di server NS poteva effettivamente richiedere fino a 36 ore per essere visibile ovunque. Arrotondare a "48 ore" permetteva di coprire i casi limite.
Il problema è che questa stima è rimasta congelata nella documentazione mentre l'infrastruttura è cambiata. Oggi i registri principali aggiornano le loro zone in pochi minuti. I registrar moderni propongono TTL di 3.600 secondi (1 ora) per impostazione predefinita, talvolta 300 secondi. La realtà tecnica del 2026 non ha più nulla a che vedere con quella del 2002.
Il termine "propagazione" è improprio
Il termine "propagazione" suggerisce un processo attivo di diffusione. Come se una modifica DNS venisse spinta di server in server, alla stregua di un aggiornamento software che si distribuisce progressivamente. Questa immagine mentale è sbagliata.
Il DNS funziona su un modello pull, non push. Nessun server invia una notifica ai resolver per comunicare "il valore è cambiato". Ogni resolver ricorsivo decide autonomamente quando interrogare il server autoritativo, in base al TTL del record che ha in cache.
Ecco cosa succede realmente quando un utente digita captaindns.com nel browser:
- Lo stub resolver della macchina locale verifica la propria cache. Se ha una risposta valida (TTL non scaduto), la restituisce immediatamente.
- Se non ha nulla in cache, trasmette la richiesta al resolver ricorsivo configurato (quello dell'ISP, di Google, di Cloudflare, ecc.).
- Il resolver ricorsivo verifica la propria cache. Se ha una risposta valida, la restituisce.
- Se non ha nulla o se il TTL è scaduto, avvia una risoluzione completa: interroga un server root, poi il server TLD (
.com), poi il server autoritativo per il dominio. - Il server autoritativo restituisce la risposta attuale (il nuovo record se lo hai modificato) con il TTL configurato.
- Il resolver mette questa risposta in cache per la durata del TTL e la restituisce all'utente.
Il "ritardo di propagazione" non è altro che il tempo rimanente prima della scadenza della cache. Se il resolver ha messo il vecchio record in cache 30 minuti fa con un TTL di 3.600 secondi, serviranno ancora 30 minuti prima che interroghi di nuovo il server autoritativo.
Il TTL: il vero orologio della propagazione
Cos'è il TTL?
Il TTL (Time To Live) è un campo numerico associato a ogni record DNS, espresso in secondi. Indica ai resolver per quanto tempo possono mantenere la risposta in cache prima di doverla richiedere al server autoritativo.
Il TTL è definito dall'amministratore della zona DNS, non dal protocollo. È una scelta operativa. Ogni record in una zona può avere il proprio TTL. Puoi configurare un TTL di 60 secondi su un record A che punta a un servizio in alta disponibilità, mantenendo allo stesso tempo un TTL di 86.400 secondi su un record MX che non cambia mai.
La RFC 1035 (sezione 3.2.1) definisce il TTL come un intero senza segno a 32 bit, ovvero un valore massimo teorico di 2.147.483.647 secondi (circa 68 anni). In pratica, la RFC 2181 (sezione 8) raccomanda di trattare qualsiasi valore superiore a 2.147.483.647 come 0. I valori comuni vanno da 60 a 86.400 secondi.
Per verificare il TTL attuale di un record, usa dig:
dig captaindns.com A +noall +answer
L'output è simile a questo:
captaindns.com. 3600 IN A 76.76.21.21
Il numero 3600 è il TTL rimanente in secondi. Attenzione: questo valore decresce ogni secondo. Se rilanci il comando 10 secondi dopo, vedrai 3590. Quando raggiunge 0, il resolver considera la voce scaduta e interroga di nuovo il server autoritativo.
Per ottenere il TTL definito dal server autoritativo (e non il TTL rimanente nella cache del resolver), interroga direttamente il server autoritativo:
dig captaindns.com A @ns1.captaindns.com +noall +answer
Tabella dei tempi reali per TTL comune
Questa tabella indica il ritardo massimo tra una modifica DNS e la sua visibilità completa su tutti i resolver, supponendo che il resolver abbia messo il vecchio record in cache subito prima della modifica (caso peggiore).
| TTL (secondi) | Durata leggibile | Ritardo max di visibilità | Uso tipico |
|---|---|---|---|
| 60 | 1 minuto | 1 minuto | Failover automatico, alta disponibilità, servizi critici |
| 300 | 5 minuti | 5 minuti | CDN, bilanciamento del carico, pre-migrazione |
| 900 | 15 minuti | 15 minuti | Servizi cloud (AWS, GCP, Azure) |
| 1800 | 30 minuti | 30 minuti | Applicazioni SaaS |
| 3600 | 1 ora | 1 ora | Default comune dei registrar moderni (Cloudflare, Route 53) |
| 14400 | 4 ore | 4 ore | Default storico OVH, Gandi, alcuni pannelli cPanel |
| 43200 | 12 ore | 12 ore | Record stabili raramente modificati |
| 86400 | 24 ore | 24 ore | Record NS, record di zona stabili, default storico |
Le "24-48 ore" del mito corrispondono al caso peggiore di un TTL di 86.400 combinato con un resolver che avrebbe messo il valore in cache un secondo prima della modifica. In questo scenario, il ritardo massimo è di 24 ore, non 48. Le 48 ore sono un arrotondamento prudenziale senza fondamento tecnico.
Perché alcuni resolver ignorano il TTL?
Il protocollo DNS (RFC 1035) richiede che i resolver rispettino il TTL. In pratica, esistono alcune deviazioni.
TTL minimo imposto. Google Public DNS impone un limite inferiore di 30 secondi. Se un server autoritativo restituisce un TTL di 0 o 10 secondi, Google lo tratta come 30 secondi. Questo comportamento è documentato nelle loro FAQ tecniche. Cloudflare applica un limite inferiore simile. L'impatto è trascurabile per la maggior parte dei casi d'uso.
TTL massimo imposto. Alcuni resolver degli ISP applicano un tetto al TTL per ridurre il carico sui propri server. Un ISP che gestisce milioni di richieste al secondo può decidere di non rispettare un TTL di 60 secondi e trattarlo come 300 secondi. Questo comportamento è raro, non documentato e contrario alle RFC, ma esiste.
Cache negativa. Il TTL si applica anche alle risposte NXDOMAIN (dominio inesistente) tramite il campo SOA minimum TTL (RFC 2308). Se crei un nuovo record per un nome che non esisteva, il resolver potrebbe aver messo in cache la risposta "non esiste" con il TTL negativo della zona SOA. Questo ritardo viene spesso dimenticato durante le migrazioni.
Per verificare il TTL negativo della tua zona:
dig captaindns.com SOA +noall +answer
captaindns.com. 3600 IN SOA ns1.captaindns.com. admin.captaindns.com. 2026032601 7200 900 1209600 300
L'ultimo campo (300) è il TTL negativo. Le risposte NXDOMAIN saranno messe in cache per 300 secondi (5 minuti).
I resolver DNS: tutti diversi di fronte alla cache
La cache gerarchica
La risoluzione DNS attraversa diversi livelli di cache prima di raggiungere il server autoritativo. Ogni livello può restituire una risposta senza proseguire oltre:
Livello 1: la cache applicativa. I browser e le applicazioni mantengono la propria cache DNS. Chrome, ad esempio, conserva le risoluzioni per 60 secondi per impostazione predefinita. Questa cache è indipendente dal sistema operativo.
Livello 2: lo stub resolver (cache OS). Il sistema operativo mantiene una cache DNS locale. Su Windows, il servizio "Client DNS" gestisce questa cache. Su macOS, è mDNSResponder. Su Linux con systemd, è systemd-resolved. Questa cache rispetta generalmente il TTL restituito dal resolver ricorsivo.
Livello 3: il resolver ricorsivo. È il server DNS configurato nella tua connessione di rete (quello dell'ISP, Google 8.8.8.8, Cloudflare 1.1.1.1, ecc.). È lui che effettua la risoluzione completa interrogando la gerarchia DNS e che mantiene la cache più consistente. Il TTL a questo livello determina il ritardo percepito di "propagazione".
Livello 4: i relay DNS intermedi. Nelle reti aziendali, un server DNS interno (Active Directory, Pi-hole, dnsmasq) può fungere da relay verso il resolver ricorsivo. Questo relay aggiunge un ulteriore livello di cache, con le proprie regole di conservazione.
Una modifica DNS è pienamente visibile per un utente solo quando tutti i livelli di cache che attraversa sono scaduti. Nel caso peggiore (tutte le cache appena riempite), il ritardo è quello del TTL più elevato nella catena. In pratica, le cache applicative e del SO hanno TTL brevi (60 secondi o meno), quindi il collo di bottiglia è quasi sempre il resolver ricorsivo.
Perché i risultati variano a seconda del resolver?
Quando testi la propagazione DNS, puoi ottenere risultati diversi a seconda del resolver interrogato. È normale, e ci sono tre ragioni.
Ragione 1: l'istante di messa in cache differisce. Google DNS potrebbe aver messo il vecchio record in cache 2 minuti fa, mentre Cloudflare lo ha fatto 55 minuti fa. Con un TTL di 3.600 secondi, Google servirà il vecchio valore per ancora 58 minuti, mentre Cloudflare lo servirà per ancora 5 minuti. Stesso TTL, ma sfasamento temporale.
Ragione 2: l'infrastruttura di cache è distribuita. Google DNS non è un singolo server. È una rete di server anycast distribuiti in centinaia di datacenter. Ogni istanza mantiene la propria cache. Una richiesta da Parigi colpisce un server Google diverso da quello di Tokyo. Entrambi possono avere valori di cache differenti. Ecco perché due utenti che interrogano "8.8.8.8" nello stesso momento possono ottenere risposte diverse.
Ragione 3: EDNS Client Subnet (ECS). Alcuni domini utilizzano risposte geolocalizzate tramite EDNS Client Subnet. Il server autoritativo restituisce indirizzi IP diversi in base alla localizzazione del client. Un utente in Francia ottiene l'IP del datacenter europeo, un utente in Giappone ottiene l'IP del datacenter asiatico. Non è un problema di propagazione: è il comportamento atteso di un CDN. Ma complica la diagnosi perché i resolver hanno risposte legittimamente diverse in cache.
Per verificare cosa ha in cache ogni resolver, interrogali direttamente:
dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
Se tutti e tre restituiscono lo stesso IP con TTL rimanenti diversi, è la prova che la modifica è in corso e che le cache scadono in momenti differenti.
Guida pratica: migrazione DNS senza sorprese
Il metodo che segue elimina l'incertezza di una migrazione DNS. Si basa su un principio semplice: ridurre il TTL prima della modifica affinché la cache scada rapidamente dopo il cambio. È la tecnica standard utilizzata dai SRE (Site Reliability Engineers) durante le migrazioni di infrastruttura.
Prima della modifica: G-48
Passo 1: verificare il TTL attuale.
Interroga il server autoritativo per conoscere il TTL definito (non il TTL rimanente in una cache):
dig captaindns.com A @ns1.captaindns.com +noall +answer
Se il TTL è di 86.400 secondi (24 ore), bisognerà ridurlo e attendere che la vecchia cache scada.
Passo 2: abbassare il TTL a 300 secondi (5 minuti).
Nell'interfaccia del tuo registrar o del tuo gestore di zona DNS, modifica il TTL del record che intendi cambiare. Non toccare ancora il valore del record. Solo il TTL cambia.
captaindns.com. 300 IN A 76.76.21.21
Passo 3: attendere la scadenza del vecchio TTL.
È il passaggio cruciale. Dopo aver ridotto il TTL a 300, devi attendere che il vecchio TTL scada ovunque. Se il vecchio TTL era di 86.400 secondi, attendi 24 ore. Se era 3.600 secondi, attendi 1 ora.
Perché? Perché i resolver che hanno il record in cache con il vecchio TTL di 86.400 non vedranno la tua modifica di TTL finché la loro cache non sarà scaduta. Una volta scaduto il vecchio TTL, tutti i resolver interrogheranno di nuovo il server autoritativo e otterranno il record con il nuovo TTL di 300 secondi.
Per questo motivo bisogna iniziare 48 ore prima: nel caso peggiore (TTL iniziale di 86.400), servono 24 ore per la propagazione del nuovo TTL, più un margine di sicurezza.
Verifica l'avanzamento interrogando diversi resolver:
dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
Quando tutti e tre restituiscono un TTL rimanente inferiore o uguale a 300, il nuovo TTL è attivo.
Il giorno della modifica: G
Passo 4: effettuare la modifica DNS.
Modifica il valore del record presso il tuo registrar o provider DNS. Ad esempio, per una migrazione di server:
captaindns.com. 300 IN A 185.199.108.153
Il TTL resta a 300 secondi. La modifica sarà visibile su tutti i resolver in massimo 5 minuti.
Passo 5: verificare la propagazione.
Interroga i principali resolver pubblici per confermare che la modifica è effettiva:
dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
dig captaindns.com A @208.67.222.222 +noall +answer
Lo strumento di test di propagazione CaptainDNS effettua questa verifica automaticamente interrogando resolver distribuiti su diversi continenti.
Passo 6: validare il servizio.
Verifica che il servizio funzioni correttamente al nuovo indirizzo. Testa gli accessi HTTP/HTTPS, l'invio di email, le connessioni API. Non passare al passo successivo finché tutto non è confermato.
Dopo la modifica: G+1
Passo 7: rialzare il TTL.
Una volta confermata la modifica e validato il servizio, rialza il TTL a un valore standard. Un TTL di 3.600 secondi (1 ora) è un buon compromesso tra reattività e riduzione del carico DNS:
captaindns.com. 3600 IN A 185.199.108.153
Un TTL troppo basso (60 secondi) in modo permanente sovraccarica i server autoritativi. Un TTL troppo alto (86.400 secondi) rende le migrazioni future più lunghe. Per i record che cambiano raramente (NS, MX), un TTL da 3.600 a 14.400 è ragionevole.
Passo 8: monitorare per 24-48 ore.
Monitora le metriche del servizio (tempo di risposta, tasso di errore, deliverability email) nelle ore successive alla migrazione. Resolver con comportamenti non standard possono tardare ad aggiornare la propria cache. Uno strumento di supervisione DNS resiliente permette di rilevare queste anomalie.
Come accelerare la "propagazione"?
Quando la modifica è stata fatta e alcuni resolver servono ancora il vecchio valore, esistono alcune azioni concrete per ridurre il ritardo. Nessuna sostituisce il metodo di riduzione del TTL descritto sopra, ma sono utili come complemento.
Svuotare la cache DNS locale
La cache della tua macchina locale può contenere il vecchio valore. Svuotarla obbliga il sistema a interrogare di nuovo il resolver ricorsivo.
Windows (PowerShell come amministratore):
ipconfig /flushdns
macOS (Terminale):
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Linux (systemd-resolved):
sudo systemd-resolve --flush-caches
Chrome (barra degli indirizzi):
chrome://net-internals/#dns
Clicca su "Clear host cache". Chrome mantiene la propria cache DNS indipendente dal sistema operativo.
Richiedere un purge ai resolver pubblici
Alcuni resolver pubblici offrono un'interfaccia per eliminare un record specifico dalla propria cache. Non è una garanzia (il record verrà rimesso in cache alla prossima richiesta), ma forza una ri-risoluzione immediata.
Google Public DNS: vai alla pagina Google Public DNS Flush Cache e inserisci il dominio e il tipo di record da eliminare.
Cloudflare: vai alla pagina Cloudflare Purge Cache e inserisci il dominio.
Questi strumenti eliminano la cache di un singolo nodo (quello che gestisce la tua richiesta). I resolver come Google e Cloudflare utilizzano l'anycast: la cache è distribuita su centinaia di server. Eseguire il purge da Parigi non elimina la cache del server che serve gli utenti di San Paolo.
Cosa NON funziona
Alcune "soluzioni" circolano sui forum e nelle pagine di supporto. Sono inefficaci, se non controproducenti.
Riavviare il router. La cache DNS del router domestico è spesso limitata a poche decine di voci e scade rapidamente. Anche se il riavvio svuota questa cache, il resolver ricorsivo dell'ISP (il vero collo di bottiglia) conserva il vecchio valore.
Cambiare resolver DNS sul computer. Passare da Google (8.8.8.8) a Cloudflare (1.1.1.1) può dare l'impressione che la modifica sia propagata, perché Cloudflare potrebbe non avere la stessa voce in cache di Google. Ma questo non risolve nulla per gli altri utenti. È un bias di osservazione, non una soluzione.
Aspettare "un po' di più". Se la modifica non è visibile dopo il tempo corrispondente al TTL, attendere ulteriormente non risolverà nulla. Il problema è altrove: TTL negativo in cache, errore nella zona DNS, server autoritativo mal configurato o resolver che non rispetta il TTL. Bisogna diagnosticare, non avere pazienza.
Casi d'uso specifici
Cambio di hosting (A / AAAA)
È il caso più frequente: stai migrando un sito web verso un nuovo server. Il record A (IPv4) o AAAA (IPv6) cambia indirizzo IP.
Il piano standard funziona perfettamente qui. Riduci il TTL 48 ore prima, cambia l'IP, verifica. La particolarità: se il tuo vecchio e il tuo nuovo server sono configurati per rispondere allo stesso nome di dominio, gli utenti che ottengono il vecchio IP vedono il vecchio server, quelli che ottengono il nuovo vedono il nuovo. Durante la transizione, entrambi i server devono funzionare in parallelo.
Per le migrazioni con cambio simultaneo di indirizzo IPv4 e IPv6, non dimenticare di modificare entrambi i record. Una dimenticanza sul record AAAA lascia i client IPv6 puntati verso il vecchio server.
CNAME e alias
I record CNAME hanno il proprio TTL, ma il resolver deve anche risolvere il target del CNAME. Il ritardo totale è il massimo tra il TTL del CNAME e il TTL del record di destinazione. Se il tuo CNAME ha un TTL di 300 ma punta a un record A con un TTL di 86.400, la modifica del valore A richiederà fino a 24 ore anche se il CNAME stesso viene risolto in 5 minuti.
Email: MX, SPF, DKIM, DMARC
I record legati all'email meritano un'attenzione particolare perché le conseguenze di un errore sono più gravi rispetto a un sito web. Un sito inaccessibile per 10 minuti è un disagio. Email perse per 10 minuti possono avere conseguenze professionali serie.
MX (Mail Exchanger). I record MX hanno spesso un TTL elevato (da 3.600 a 86.400). Durante una migrazione di provider email, la riduzione del TTL è obbligatoria. Durante la transizione, entrambi i server MX devono accettare la posta per il tuo dominio. Configura il vecchio provider per trasferire i messaggi al nuovo, se possibile.
SPF (record TXT). La modifica di un record SPF diventa effettiva alla scadenza del TTL del TXT. Il rischio: se aggiungi un nuovo provider di invio (come uno strumento di marketing) senza aggiornare l'SPF, le sue email saranno rifiutate dai server che hanno il vecchio SPF in cache. Soluzione: aggiungi il meccanismo SPF prima di iniziare a inviare tramite il nuovo provider e attendi la scadenza del TTL.
DKIM (record TXT sotto _domainkey). La pubblicazione di una nuova chiave pubblica DKIM segue le stesse regole di TTL. Attenzione durante una rotazione di chiave: la vecchia chiave deve restare pubblicata nel DNS finché email firmate con essa sono ancora in transito (le code email possono trattenere i messaggi per diversi giorni).
DMARC (record TXT sotto _dmarc). Un cambio di policy DMARC (passaggio da p=none a p=quarantine, ad esempio) diventa effettivo progressivamente al ritmo della scadenza delle cache. Si raccomanda di passare attraverso il modo p=quarantine prima di p=reject per limitare i falsi positivi durante la transizione.
DNSSEC
L'attivazione o la modifica di DNSSEC aggiunge un ulteriore livello di complessità. Due tipi di record sono coinvolti: i DNSKEY nella zona DNS e il record DS (Delegation Signer) presso il registrar.
Il record DS è pubblicato nella zona del TLD padre (ad esempio, nella zona .com per un dominio .com). Il suo aggiornamento dipende dal registrar e dal registro TLD. Il ritardo è spesso più lungo rispetto a un record standard perché implica una comunicazione tra registrar e registro.
La regola durante l'attivazione di DNSSEC: pubblicare i DNSKEY per primi, attendere la propagazione completa (almeno 2 volte il TTL), poi aggiungere il record DS. Se il DS viene aggiunto prima che i DNSKEY siano visibili ovunque, alcuni resolver con validazione restituiranno SERVFAIL, rendendo il tuo dominio inaccessibile.
Cambio di server NS (delega)
Cambiare i server autoritativi (record NS) è il caso più delicato. I record NS a livello di TLD hanno il proprio TTL (spesso 48 ore per .com). Il resolver deve rispettare questo TTL prima di reinterrogare il registro TLD.
La procedura raccomandata:
- Riprodurre la zona DNS completa sui nuovi server NS
- Ridurre il TTL di tutti i record importanti a 300 secondi
- Attendere la scadenza del vecchio TTL
- Modificare la delega NS presso il registrar
- Mantenere i vecchi server NS attivi per 48-72 ore (il tempo necessario alla scadenza delle cache NS)
- Verificare che entrambi i gruppi di server NS restituiscano le stesse risposte durante tutto il periodo di transizione
Diagnosi: perché la mia modifica DNS non funziona?
Quando la modifica non è ancora visibile dopo il ritardo previsto, bisogna diagnosticare. Ecco le cause più frequenti, ordinate per probabilità.
Causa 1: la modifica non è stata registrata
È la causa più comune. L'interfaccia del registrar ha mostrato "salvato" ma il server autoritativo non ha ancora il nuovo valore. Verifica direttamente:
dig captaindns.com A @ns1.captaindns.com +noall +answer
Se appare il vecchio record, il problema è presso il provider DNS, non nella propagazione.
Causa 2: la cache negativa
Se hai creato un nuovo record (che non esisteva prima), il resolver potrebbe avere una risposta NXDOMAIN in cache. Verifica il TTL negativo nel SOA:
dig captaindns.com SOA +noall +answer
L'ultimo campo del SOA è il TTL negativo. Attendi quel ritardo.
Causa 3: il tipo di record sbagliato
Hai cambiato il record A ma il DNS restituisce un CNAME che punta al vecchio record. Oppure hai modificato un TXT ma ci sono due record TXT e hai modificato quello sbagliato. Verifica richiedendo tutti i tipi:
dig captaindns.com ANY @ns1.captaindns.com
Causa 4: DNSSEC rotto
Se DNSSEC è attivo e la catena di fiducia è interrotta (record DS non corrispondente più al DNSKEY), i resolver con validazione restituiscono SERVFAIL al posto della risposta. Testa con e senza validazione DNSSEC:
dig captaindns.com A @8.8.8.8 +dnssec
dig captaindns.com A @8.8.8.8 +cd
Il flag +cd (Checking Disabled) disabilita la validazione DNSSEC. Se la richiesta funziona con +cd ma non senza, il problema è DNSSEC.
Causa 5: relay DNS aziendale con cache aggressiva
In una rete aziendale, un server DNS interno (Active Directory, Pi-hole) può mettere in cache le risposte con un TTL superiore a quello restituito dal resolver ricorsivo. Contatta l'amministratore di rete per svuotare la cache del server DNS interno.
Comprendere il ruolo della zona SOA
Il record SOA (Start of Authority) contiene parametri che influenzano indirettamente la "propagazione". I suoi campi vengono spesso trascurati durante la pianificazione di una migrazione.
dig captaindns.com SOA +noall +answer
captaindns.com. 3600 IN SOA ns1.captaindns.com. admin.captaindns.com. (
2026032601 ; serial
7200 ; refresh (2 ore)
900 ; retry (15 minuti)
1209600 ; expire (14 giorni)
300 ; minimum / negative TTL (5 minuti)
)
Serial: numero di versione della zona. I server secondari confrontano questo numero per rilevare i cambiamenti. Un serial non incrementato dopo una modifica impedisce la sincronizzazione verso i server secondari.
Refresh: intervallo con cui i server secondari verificano se la zona è cambiata. Un refresh di 7.200 secondi (2 ore) significa che il server secondario può servire una zona obsoleta per 2 ore. Questo parametro impatta la coerenza tra server autoritativi, non la cache dei resolver ricorsivi.
Minimum (TTL negativo): il TTL applicato alle risposte NXDOMAIN. Se crei un nuovo record, i resolver che hanno una risposta NXDOMAIN in cache dovranno attendere questo ritardo. Valore raccomandato: 300 secondi (5 minuti).
I resolver pubblici e le loro particolarità
Ogni resolver pubblico ha comportamenti specifici che influenzano la percezione della propagazione. Conoscere queste specificità aiuta nella diagnosi. Un confronto dei resolver DNS pubblici permette di approfondire l'argomento.
Google Public DNS (8.8.8.8 / 8.8.4.4)
- TTL minimo: 30 secondi
- Interfaccia di purge disponibile
- Infrastruttura anycast massiva (centinaia di PoP)
- Supporta EDNS Client Subnet per risposte geolocalizzate
Cloudflare (1.1.1.1 / 1.0.0.1)
- TTL minimo: 30 secondi
- Interfaccia di purge disponibile
- Architettura anycast in oltre 310 datacenter
- Non trasmette la sottorete client per impostazione predefinita (migliore privacy)
Quad9 (9.9.9.9 / 149.112.112.112)
- Filtro malware integrato (può bloccare certi domini)
- TTL minimo non documentato pubblicamente
- Nessuna interfaccia di purge pubblica
- Validazione DNSSEC attivata per impostazione predefinita
OpenDNS (208.67.222.222 / 208.67.220.220)
- Filtro configurabile (categorie di contenuto)
- Cache che può essere più persistente del TTL in alcuni casi
- Interfaccia di purge tramite la dashboard
Resolver degli ISP
- Comportamento variabile e spesso non documentato
- Alcuni impongono TTL minimi o massimi
- Cache talvolta condivisa tra milioni di abbonati (effetto di mutualizzazione)
- Raramente con interfaccia di purge
Piano d'azione raccomandato
Ecco la procedura completa, riassunta in 5 passi. Stampala o salvala per la tua prossima migrazione DNS.
-
Verificare il TTL attuale: interroga il server autoritativo con
digo usa lo strumento CaptainDNS per ottenere il TTL di ogni record della tua zona. -
Abbassare il TTL 48 ore prima: riduci a 300 secondi per tutti i record che intendi modificare. Non dimenticare i record associati (AAAA se cambi il record A, TXT se migri l'email).
-
Effettuare la modifica: modifica i record DNS presso il tuo registrar o provider. Verifica immediatamente che il server autoritativo restituisca il nuovo valore.
-
Verificare la propagazione: testa da diversi resolver pubblici (Google, Cloudflare, Quad9, OpenDNS). Usa uno strumento di test di propagazione per una visione globale su tutti i continenti.
-
Rialzare il TTL: una volta confermata la modifica e validato il servizio, ripristina un TTL standard (3.600 secondi). Mantieni il monitoraggio per 24 ore.
FAQ
Quanto tempo dura la propagazione DNS?
Il ritardo dipende unicamente dal TTL (Time To Live) del record modificato. Con un TTL di 300 secondi, la modifica è visibile ovunque in 5 minuti. Con un TTL di 3.600 secondi, conta un massimo di 1 ora. Con 86.400 secondi, il ritardo massimo è di 24 ore. Nessuna ragione tecnica giustifica un ritardo di 48 ore. Questo mito risale agli anni 2000, quando i TTL predefiniti erano di 86.400 secondi e i registri TLD aggiornavano le zone ogni 12 ore.
Come accelerare la propagazione DNS?
Abbassa il TTL a 300 secondi (5 minuti) almeno 48 ore prima della modifica prevista. Una volta che il TTL ridotto si è propagato, qualsiasi modifica successiva sarà visibile in 5 minuti. In aggiunta, svuota la cache locale: ipconfig /flushdns su Windows, sudo dscacheutil -flushcache su macOS. Puoi anche usare le interfacce di purge di Google Public DNS e Cloudflare per forzare una ri-risoluzione immediata su quei resolver.
Perché la mia modifica DNS non funziona?
Le cause più frequenti, in ordine di probabilità: (1) la modifica non è stata registrata correttamente presso il provider DNS; (2) la cache negativa (NXDOMAIN) trattiene una vecchia risposta "non esiste"; (3) il tipo di record sbagliato è stato modificato; (4) la catena DNSSEC è rotta; (5) un relay DNS aziendale applica una cache aggressiva. Diagnostica interrogando il server autoritativo: dig captaindns.com A @ns1.captaindns.com. Se il valore è ancora quello vecchio, il problema è alla fonte.
Cos'è il TTL DNS?
Il TTL (Time To Live) è un campo numerico associato a ogni record DNS, espresso in secondi. Indica ai resolver per quanto tempo possono mantenere una risposta in cache. Un TTL di 3.600 significa 1 ora di cache. Passato quel tempo, il resolver interroga di nuovo il server autoritativo. Il TTL è definito dall'amministratore della zona DNS, non dal protocollo. Ogni record può avere il proprio valore di TTL.
Bisogna aspettare 24-48 ore dopo una modifica DNS?
No. Il ritardo si impone solo se il TTL del record è di 86.400 secondi (24 ore), valore predefinito storico di alcuni registrar. Con un TTL di 3.600 secondi (1 ora, valore comune nel 2026), il ritardo massimo è di 1 ora. Preparando la migrazione con TTL a 300 secondi 48 ore prima, la modifica è visibile in 5 minuti. La raccomandazione "24-48 ore" risale agli anni 2000 e non riflette la realtà tecnica attuale.
Come svuotare la cache DNS?
La cache DNS esiste a diversi livelli. Su Windows: ipconfig /flushdns in PowerShell. Su macOS: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. Su Linux (systemd): sudo systemd-resolve --flush-caches. Per Chrome: chrome://net-internals/#dns, poi "Clear host cache". Per i resolver pubblici, usa le interfacce di purge di Google Public DNS e Cloudflare 1.1.1.1. La cache del resolver del tuo ISP non è eliminabile manualmente.
Perché i resolver DNS danno risultati diversi?
Tre ragioni. Primo: ogni resolver ha messo il record in cache in un momento diverso, quindi il TTL scade in istanti sfasati. Secondo: i grandi resolver (Google, Cloudflare) usano reti anycast con centinaia di server indipendenti. Il server che serve Parigi non condivide la cache con quello di Tokyo. Terzo: alcuni domini usano EDNS Client Subnet (ECS) per restituire IP geolocalizzati, producendo risposte diverse in base alla localizzazione del client.
Cambiare resolver DNS accelera la propagazione?
No, non in modo affidabile. Passare da 8.8.8.8 a 1.1.1.1 può dare l'impressione che la modifica sia propagata, se il nuovo resolver non ha il vecchio record in cache. Ma non accelera nulla per gli altri utenti. Il ritardo dipende dal TTL della cache di ogni resolver. Non puoi controllare la cache del resolver dei tuoi visitatori. L'unico metodo affidabile resta la riduzione del TTL prima della modifica.
Come verificare se la propagazione DNS è terminata?
Interroga almeno quattro resolver pubblici con dig: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) e OpenDNS (208.67.222.222). Se tutti restituiscono il nuovo valore, la propagazione è completa per la grande maggioranza degli utenti. Per una verifica esaustiva, usa uno strumento multi-resolver che interroga server su diversi continenti. Finché almeno un resolver restituisce il vecchio valore, la propagazione non è terminata.
Glossario
- TTL (Time To Live): durata in secondi durante la quale un resolver DNS può mantenere un record in cache prima di richiederlo al server autoritativo. Definito dall'amministratore di zona.
- Resolver ricorsivo: server DNS che riceve le richieste dai client ed effettua la risoluzione completa interrogando la gerarchia DNS (root, TLD, autoritativo). Esempi: Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1).
- Server autoritativo: server DNS che detiene i record originali di una zona DNS. È la fonte di verità per i record di un dominio.
- Cache DNS: memoria temporanea dove un resolver archivia le risposte DNS già ottenute. La cache riduce il carico sui server autoritativi e accelera le risposte.
- Zona DNS: insieme di record DNS per un dominio e i suoi sottodomini, ospitato su uno o più server autoritativi.
- NS record (Name Server): record che designa i server autoritativi per una zona DNS. Pubblicato sia nella zona padre (delega) che nella zona stessa.
- Stub resolver: componente del sistema operativo che trasmette le richieste DNS al resolver ricorsivo configurato. Mantiene una cache locale minima.
- SOA (Start of Authority): record obbligatorio in ogni zona DNS che contiene i metadati della zona (serial, refresh, retry, expire, TTL negativo).
- NXDOMAIN: risposta DNS che indica che il nome di dominio richiesto non esiste. Questa risposta viene messa in cache secondo il TTL negativo definito nel SOA.
- Anycast: tecnica di instradamento di rete in cui lo stesso indirizzo IP viene annunciato da più posizioni geografiche. I resolver pubblici usano l'anycast per indirizzare le richieste verso il server più vicino.
Lo strumento di test di propagazione CaptainDNS interroga resolver distribuiti su tutti i continenti e mostra in tempo reale lo stato della cache per ogni record. Usalo per confermare che una modifica DNS è visibile ovunque prima di considerare la migrazione completata.
Fonti
- RFC 1035: Domain Names - Implementation and Specification (IETF, sezione 3.2.1 per la definizione del TTL)
- RFC 2181: Clarifications to the DNS Specification (IETF, sezione 8 per le regole di TTL)
- RFC 2308: Negative Caching of DNS Queries (IETF, cache negativa e SOA minimum TTL)
- Google Public DNS: Flush Cache (documentazione ufficiale dell'interfaccia di purge)
- Cloudflare 1.1.1.1: Purge Cache (documentazione ufficiale dell'interfaccia di purge)
