Verifica propagazione DNS

La domanda che porta a uno strumento come questo di solito non è "quali indirizzi restituiscono venti resolver", ma "il mio cambio DNS è finito, e se no quando finisce?". 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.

Ogni riga del risultato riceve una classe e la ragione che l'ha determinata. A ciascuna corrisponde una condizione osservata e un'azione diversa.

Propagato. Il valore coincide con quello che pubblicano i nameserver del dominio, oppure è uno degli indirizzi dell'insieme pubblicato. Non c'è altro da fare.

In aggiornamento. Il valore è diverso e il TTL è già eroso: la cache è stata popolata prima del cambio. Il countdown indica quanto manca. Le cache di terzi si aggiornano alla scadenza del TTL; i moduli di flush pubblici di Google e Cloudflare agiscono solo sui rispettivi resolver.

Variante geografica. Il valore è diverso ma aggiornato: il dominio risponde valori diversi a reti diverse. Non richiede attesa.

Nameserver discordi. I nameserver del dominio restituiscono valori diversi e non hanno tutti la stessa versione dei dati. È una condizione di sincronizzazione da risolvere sul provider DNS. Finché dura, il risultato di ogni risoluzione dipende da quale nameserver viene interrogato, il che produce comportamenti intermittenti difficili da diagnosticare a valle.

Nome non risolto ovunque. Una parte dei server risolve il nome e una parte risponde che non esiste. Su un record creato da poco si tratta quasi sempre di cache negativa, che dura quanto il campo minimum della SOA. Se persiste, la delega della zona presso il registro non è completa.

Firma DNSSEC non valida. Un server che controlla le firme rifiuta la risposta su un dominio firmato. Per gli utenti dietro un resolver che valida il dominio risulta irraggiungibile, quindi la priorità è più alta di una propagazione lenta.

Server non raggiungibile. Nessuna risposta entro il tempo previsto, oppure richiesta rifiutata. Riguarda il resolver e non il dominio: su un campione ampio, qualche punto che non risponde rientra nella norma e per questo resta grigio invece che rosso.

Molti strumenti di questa categoria mostrano una mappa del mondo con punti colorati e dichiarano di controllare da decine di location. Vale la pena capire cosa indichi quel numero, perché nella maggior parte dei casi quelle location sono etichette associate a indirizzi IP di resolver pubblici.

Il motivo è l'anycast. Resolver come 1.1.1.1, 8.8.8.8 e 9.9.9.9 non si trovano in un posto solo: lo stesso indirizzo IP è annunciato da centinaia di data center, e risponde quello più vicino a chi interroga. Un backend italiano che interroga 9.9.9.9 parla con il PoP italiano di Quad9, non con Zurigo. La verifica è immediata: dig CHAOS TXT id.server @1.1.1.1 restituisce fco01, cioè Roma, e dig CHAOS TXT id.server @9.9.9.9 restituisce res701.trn, cioè Torino.

Il test che separa le due cose è la fisica. La luce nella fibra viaggia a circa 200.000 km/s, quindi un round trip verso un punto distante D chilometri non può concludersi in meno di D/100 millisecondi. È un limite invalicabile: nessun instradamento, nessuna ottimizzazione e nessuna cache possono violarlo. Se un indirizzo che un database colloca a 16.000 km risponde in 19 ms, il nodo che ha risposto non è dove il database dice. Questo test viene eseguito su ogni indirizzo dell'inventario, ogni giorno, dal server che poi esegue le verifiche.

Da qui le tre etichette che vedi accanto a ogni punto di osservazione, e il fatto che non ce ne sia una quarta:

anycast significa che l'indirizzo è globale e la risposta arriva dal nodo più vicino a noi. Dove il resolver espone id.server o hostname.bind viene mostrato il nodo reale che ha risposto, con la sigla che dichiara lui. Mai una città scelta a tavolino.

posizione compatibile significa che la latenza misurata è coerente con la distanza dichiarata: un nodo più vicino non potrebbe essere così lento. Passando il puntatore sull'etichetta compaiono i tre numeri da cui la conclusione deriva. Attenzione alla formulazione, che è deliberata: il test dimostra che una posizione è impossibile, non che una posizione plausibile sia corretta. Un resolver a 286 ms è compatibile con Sydney, ma potrebbe stare ad Auckland; per il nostro uso quello che conta è che sia realmente remoto e realmente distinto dagli altri, e questo il test lo garantisce.

posizione non verificata significa che il test non ha potuto concludere, e in quel caso non viene mostrata nessuna posizione.

Non c'è una mappa, e non è una mancanza. Con il routing geografico ciò che serve sapere è quale valore riceve ciascuna area, non quali punti hanno risposto: la vista per continente porta quella informazione senza il costo di una libreria cartografica e senza suggerire una precisione che non abbiamo. Un pallino verde su una mappa comunica soltanto "ha risposto".

Un'ultima nota. Ciò che determina se un utente vede il valore precedente o quello nuovo non è tanto il paese in cui si trova, quanto quale resolver usa e quando quel resolver ha popolato la sua cache. Due utenti in continenti diversi che usano entrambi 8.8.8.8 ricevono quasi sempre la risposta del PoP regionale più vicino a ciascuno. Il TTL residuo descrive quel meccanismo in modo diretto, ed è per questo che è la colonna che resta visibile in ogni riga.

Le misure di questa pagina sono riproducibili con dig da qualsiasi macchina.

Interrogazione diretta dei nameserver. Si individua la zona che contiene il nome risalendo label per label, accettando solo i set NS il cui owner coincide con il candidato; si risolvono i nameserver in indirizzi e si interroga ciascuno di essi direttamente, con il bit di ricorsione azzerato, chiedendo il record richiesto e la SOA della zona. Le risposte con il bit AA alzato costituiscono il riferimento. Se il nome è un alias, la catena CNAME viene seguita fino alla zona che contiene i record finali, ed è lì che si misura. Equivalente: dig +norecurse @ns1.esempio.it esempio.it A.

Interrogazione dei punti di osservazione. Un inventario di resolver pubblici ricorsivi, interrogati in parallelo su UDP/53 con timeout di due secondi. L'inventario viene rivalidato ogni giorno: un indirizzo entra nel set attivo solo se risponde, espone il flag di ricorsione e non filtra, e ne esce dopo tre validazioni fallite di fila. La posizione dichiarata da un database viene confrontata con il minimo fisico imposto dalla velocità della luce in fibra (round trip non inferiore a distanza/100 in millisecondi): chi risponde più in fretta del proprio minimo è anycast, e non viene mai mostrato con una città. A questo si aggiungono tre resolver DoH interrogati dal browser, che misurano la rete di chi guarda. Il TTL restituito da una risposta in cache è il TTL residuo.

Nota sulle query non ricorsive. Leggere il TTL residuo con query a ricorsione disabilitata eviterebbe di innescare un aggiornamento della cache, ma non è praticabile su tutti i resolver: Cloudflare risponde, Quad9 rifiuta e Google restituisce SERVFAIL. Il TTL residuo si legge comunque da una normale query ricorsiva, perché una risposta servita dalla cache porta il TTL già decrementato; su una cache vuota la query provoca il prelievo dall'origine e il TTL torna pieno, ed è proprio questo il segnale che distingue una copia precedente da una risposta appena prelevata.

Limite di un solo punto di osservazione. Quando le sonde ECS rilevano che la zona risponde diversamente a reti diverse, i valori fuori dall'insieme osservato vengono classificati come varianti geografiche. È la lettura corretta nella maggior parte dei casi, dato che un CDN può rispondere molti indirizzi diversi e da una sola posizione non sono enumerabili; ha però un rovescio: su un dominio geografico, durante una migrazione, un resolver rimasto indietro può essere letto come variante. Su domini di questo tipo il segnale più affidabile resta l'interrogazione diretta dei nameserver.

Cosa non copre. Non ci sono probe distribuite, quindi non viene dichiarata alcuna geografia. Non c'è monitoraggio nel tempo con notifica. Non c'è uno snapshot immutabile del risultato: il link di condivisione ripete la verifica, che per un dato in movimento è più utile di una fotografia. Eventuali estensioni verranno documentate qui.

Questa pagina risponde a una domanda specifica: se un cambio DNS sia concluso. Per le domande adiacenti ci sono altri strumenti nella stessa sezione.

Il DoH query tester serve a interrogare un singolo resolver e vedere la risposta grezza: rcode, sezione authority, flag, catena di CNAME e dati RDAP del dominio. È lo strumento adatto a capire cosa risponde un resolver, più che a stabilire se sia aggiornato.

Il validatore email DNS copre il verticale della posta: MX, SPF con conteggio dei lookup, DKIM, DMARC e gli errori tipici di deliverability. Dopo aver pubblicato un TXT di autenticazione, quello ne verifica la correttezza e questo indica quando sarà visibile ovunque.

Sul fronte dei certificati, l'analizzatore degli header di sicurezza e il decoder di certificati SSL coprono i controlli successivi a una migrazione, quando il DNS punta già al posto giusto.