# Verifica propagazione DNS > Confronta i nameserver autoritativi con oltre 170 punti di osservazione in più di 70 paesi, leggi il TTL residuo di ogni cache e capisci se la divergenza è propagazione o GeoDNS. Strumento gratuito nel browser (nessun upload): https://www.mauriziofonte.it/strumenti/verifica-propagazione-dns Interroga i **nameserver autoritativi** della zona e li confronta con un inventario di oltre 170 punti di osservazione in più di 70 paesi, rivalidato ogni giorno. Per ogni cache mostra il **TTL residuo**, cioè i secondi che mancano alla scadenza, e distingue due situazioni che si somigliano molto: una copia in cache che risponde ancora il valore precedente, e un dominio dietro CDN che risponde indirizzi diversi a reti diverse. ## Come si usa 1. **Inserisci il dominio** - Va bene anche un URL completo o un indirizzo email: viene estratto l'hostname. I domini con caratteri non latini sono convertiti in punycode automaticamente. 2. **Scegli il tipo di record** - A e AAAA per il puntamento del sito, MX per la posta, TXT per SPF, DKIM e verifiche di proprietà, NS per un cambio di nameserver, CNAME per gli alias. Sono coperti anche CAA, DS, DNSKEY, TLSA, SRV, SVCB e HTTPS. 3. **Lascia attivo il piano autoritativo** - Le query dirette ai nameserver della zona forniscono il riferimento con cui valutare le cache. Senza, restano leggibili i valori ma non il confronto. 4. **Leggi il verdetto di ogni riga** - Ogni riga riporta una classe e la ragione per cui è stata assegnata. Una risposta diversa da quella dei nameserver del dominio può essere normale: accade su ogni dominio servito da un CDN. 5. **Guarda il tempo residuo** - Se una cache serve ancora il valore precedente, il countdown indica quando scadrà l'ultima osservata. Da quel momento la propagazione risulta completa sui punti misurati. ## Perché i resolver rispondono valori diversi Chi arriva a uno strumento come questo di solito si chiede **"il mio cambio DNS è finito, e se no quando finisce?"**. Molti strumenti rispondono invece a un'altra domanda: "quali indirizzi restituiscono venti resolver". Sono due domande diverse, e la prima non risponde alla seconda. Le risposte divergenti fra resolver hanno due cause distinte. La prima è la **cache**: un resolver ha memorizzato il valore precedente prima del cambio e continua a servirlo fino alla scadenza del TTL. Questa è propagazione in corso, e il tempo residuo è un numero leggibile. La seconda è il **routing geografico**: il dominio è servito da un CDN o da un bilanciatore che risponde indirizzi diversi in base alla rete da cui arriva la query. In quel caso non c'è nulla in aggiornamento e non c'è nulla da attendere. Un esempio misurabile su questo stesso dominio, con la pubblicazione conclusa da mesi: i nameserver autoritativi rispondono `172.67.135.235` e `104.21.7.88`, mentre `8.8.8.8` e `9.9.9.9` rispondono `188.114.96.7` e `188.114.97.7`. Indirizzi diversi, stesso operatore, rete anycast. Letta senza contesto, quella differenza somiglia a un cambio non ancora propagato. La distinzione fra i due casi si può osservare. **Una copia in cache che risponde un valore superato ha per forza un TTL già consumato**, perché è stata popolata prima del cambio e il tempo passa; una risposta appena prelevata dall'origine arriva invece con il TTL pieno. Quindi un valore diverso con TTL pieno indica che l'origine ha risposto così in questo momento, mentre un valore diverso con TTL eroso indica una copia precedente ancora in circolo, e i secondi che mancano sono il TTL residuo. A questa lettura si aggiunge, quando è possibile ottenerla, una verifica diretta: interrogare il nameserver autoritativo con **EDNS Client Subnet** diverse e osservare se la risposta cambia. Se cambia, il routing geografico è rilevato. Se non cambia non si conclude nulla, perché diversi CDN realizzano la geografia con l'anycast del nameserver anziché con ECS. ## Glossario - **Propagazione DNS**: Espressione informale per la scadenza progressiva delle cache dei resolver dopo un cambio. Non esiste un processo di distribuzione: le copie precedenti semplicemente scadono. - **TTL**: Time To Live, i secondi per cui un record può restare in cache. Il TTL restituito da un resolver è il tempo che manca alla scadenza della sua copia, non il valore configurato nella zona. - **Nameserver autoritativo**: Il server che detiene la zona e risponde con il bit AA alzato. È la fonte dei dati: tutto il resto sono copie con una scadenza. - **Serial SOA**: Numero di versione della zona. Se due nameserver autoritativi dello stesso provider espongono serial diversi, uno dei due non ha ancora ricevuto l'ultima versione. - **Anycast**: Uno stesso indirizzo IP annunciato da molti data center; risponde quello più vicino a chi interroga. È il motivo per cui l'IP di un resolver pubblico non identifica un luogo. - **GeoDNS**: Configurazione in cui il nameserver autoritativo risponde valori diversi in base alla rete di provenienza della query. Produce divergenze stabili e previste fra resolver. - **EDNS Client Subnet**: Estensione (RFC 7871) con cui un resolver comunica al nameserver autoritativo la subnet del client. Interrogare il nameserver autoritativo con ECS diverse consente di rilevare il routing geografico. - **Cache negativa**: Memorizzazione del fatto che un nome non esiste. Dura quanto il campo minimum della SOA, ed è il motivo per cui un record appena creato può restare invisibile per qualche minuto. - **DNSSEC**: Firma crittografica della zona. Se la validazione fallisce, un resolver validante risponde SERVFAIL e il dominio risulta irraggiungibile per i suoi utenti, indipendentemente dalla propagazione. - **Delega**: Il record NS che il registro pubblica per la zona. Una delega incompleta produce risoluzione intermittente, che a valle somiglia a una propagazione lenta. - **CNAME**: Alias verso un altro nome. I record finali vivono nella zona del bersaglio, quindi la verifica autoritativa segue la catena fino a quella zona. ## Domande frequenti ### Quanto dura la propagazione DNS? Quanto il TTL del record, più il tempo che il provider impiega a pubblicare il cambio sugli autoritativi. Con un TTL di 300 secondi si parla di cinque minuti. La risposta "24-48 ore" risale a quando i TTL erano molto più lunghi e alcuni ISP non ne rispettavano la scadenza: oggi è raramente attinente. ### Perché due resolver mi danno indirizzi diversi anche se ho cambiato tutto giorni fa? Nella maggior parte dei casi perché il dominio è servito da un CDN o da un bilanciatore geografico, che risponde indirizzi diversi a reti diverse. Accade con Cloudflare, Akamai, Fastly e Route53 in modalità latency-based. Questo strumento classifica quelle righe come variante geografica, così la differenza resta leggibile senza somigliare a un cambio incompleto. ### Posso forzare la propagazione o svuotare le cache? Puoi svuotare la cache del tuo sistema operativo e del tuo browser, e usare i moduli di flush pubblici che Google e Cloudflare offrono per i propri resolver. Sugli altri resolver la copia si aggiorna alla scadenza del TTL: non esiste un meccanismo per anticiparla dall'esterno. ### Come si prepara un cambio DNS per ridurre i tempi? Si abbassa il TTL del record a 300 secondi almeno 24 ore prima del cambio, si attende che il TTL precedente sia scaduto, si esegue la migrazione, si verifica e solo dopo si rialza il TTL al valore abituale. È la procedura che riduce la finestra di disallineamento a pochi minuti. ### Perché serve un server per interrogare i nameserver autoritativi? Perché i nameserver autoritativi parlano il protocollo DNS su UDP e TCP porta 53: non espongono DNS-over-HTTPS e non inviano header CORS, quindi dal browser non sono raggiungibili. Il resto dello strumento gira nel browser; se l'interrogazione dei nameserver non risponde, il risultato lo indica e le misure dalla tua rete restano valide. ### Cosa significa che i serial SOA sono diversi? Che i nameserver della zona non hanno tutti la stessa versione dei dati: uno o più secondari non hanno ricevuto l'ultimo trasferimento. C'è però un caso frequente da distinguere: se la zona è servita da due provider distinti, ognuno usa la propria numerazione e i serial non sono confrontabili fra loro. Questo strumento li confronta solo all'interno dello stesso master dichiarato nella SOA. ### Ho appena creato il record e alcuni resolver dicono che non esiste. È normale? Sì, si tratta di cache negativa: quel resolver aveva già ricevuto una richiesta per quel nome prima che esistesse, ha memorizzato la risposta negativa e la conserva per il tempo indicato dal campo minimum della SOA, tipicamente da qualche minuto a un'ora. ### Quanti punti di osservazione vengono interrogati? Dipende dal profilo scelto. Quello rapido, che è il predefinito, ne interroga una trentina: i grandi operatori anycast più un campione geografico distribuito sui continenti. Quello completo interroga tutto l'inventario attivo, oltre 170 punti in più di 70 paesi. In entrambi i casi si aggiungono i nameserver autoritativi della zona, che sono il riferimento, e la sezione "da dove arrivano queste misure" riporta il conteggio esatto del momento e la data dell'ultima validazione. ### Perché non c'è una mappa del mondo? Perché i resolver pubblici sono anycast: lo stesso indirizzo IP è annunciato da centinaia di data center e risponde quello più vicino a chi interroga, quindi associarlo a una città non descriverebbe il percorso reale della query. Qui viene indicato da dove parte ogni misura: dal tuo browser per il primo piano, da un server in Germania per il secondo. ### I dati del dominio che verifico vengono salvati? No. La misura dalla tua rete non passa da nessun server di questo sito. L'interrogazione dei nameserver passa da un endpoint che mette in cache il risultato per venticinque secondi, per non ripetere le stesse query, e non registra il dominio interrogato. Non c'è storico né account. ### Posso aggiungere un mio resolver? Sì, fino a tre indirizzi IP pubblici. Gli indirizzi privati non sono accettati: un resolver interno non sarebbe raggiungibile dal server che esegue le query, e accettarli aprirebbe la possibilità di sondare reti private. Per un resolver interno lo strumento adatto è dig, dalla rete in cui vive. ### Funziona anche con i domini dietro CDN? Sì. Se il nome è un alias, la verifica segue la catena CNAME fino alla zona che contiene i record finali e misura lì. Il risultato mostra la catena seguita e la zona effettivamente interrogata, che per un nome dietro CDN è diversa dal dominio digitato. ### Funziona anche per la posta e per i certificati? Sì. MX per il routing della posta, TXT per SPF e DKIM, CAA per le autorità abilitate a emettere certificati, TLSA per DANE, SVCB e HTTPS per i record usati da ECH e Alt-Svc. Per un'analisi completa dei record di posta c'è il [validatore email DNS](/strumenti/validatore-email-dns). --- Uno strumento di Maurizio Fonte, senior backend engineer. Tutti gli strumenti: https://www.mauriziofonte.it/strumenti/