Come verificare la propagazione DNS

Da dove viene l'attesa

Immagina la catena che percorre una ricerca. Il tuo dispositivo chiede a un resolver ricorsivo, gestito dal tuo provider internet o da un provider pubblico. Se quel resolver ha una risposta recente in cache, la restituisce senza chiedere a nessun altro. Solo quando la cache è scaduta scende verso i server radice, il registro del dominio di primo livello, e infine i tuoi nameserver autoritativi, che contengono il record che hai modificato.

Quindi quando cambi un record A, il nuovo valore esiste nel secondo in cui il tuo provider DNS lo salva. Ogni resolver che ha ancora la vecchia risposta continua a servirla finché la sua copia non va in timeout. Il TTL, time to live, è un numero in secondi allegato al record che dice ai resolver per quanto tempo possono metterlo in cache. Un record con un TTL di 3600 può essere servito dalla cache per un'ora dopo essere stato recuperato, quindi un'ora è il caso peggiore per un resolver che lo ha recuperato appena prima della tua modifica.

Questo è il motivo per cui due persone nello stesso ufficio possono vedere risultati diversi, e perché cancellare la tua stessa cache non aiuta nessun altro. Non esiste una diffusione globale da aspettare, solo molti timer indipendenti che scadono in momenti diversi.

Come verificare da più resolver

Il modo manuale è chiedere la stessa domanda a più resolver e confrontare le risposte:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # il tuo resolver
dig +short example.com @ns1.yourdns.example  # autoritativo: la fonte di verità

La query autoritativa è quella importante. Se restituisce il nuovo valore, la tua modifica è corretta e completa, e tutto il resto è solo una questione di cache. Se restituisce il vecchio valore, la modifica non è stata salvata, hai modificato la zona sbagliata, oppure i nameserver del dominio non sono quelli che pensi.

Per vedere il tempo di cache rimanente invece del solo valore, ometti +short e leggi la colonna del TTL:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

Il numero prima del tipo di record conta alla rovescia man mano che la copia in cache invecchia, il che ti dice esattamente per quanto tempo ancora quel resolver servirà la vecchia risposta. Su Windows, nslookup example.com 8.8.8.8 fa lo stesso confronto senza strumenti aggiuntivi. Una ricerca DNS basata sul web che interroga da molte ubicazioni contemporaneamente fa lo stesso lavoro più velocemente, e copre anche resolver che non puoi raggiungere dalla tua macchina.

Perché può volerci ore

• Governa il vecchio TTL, non il nuovo. Se il record aveva un TTL di 86400 e lo abbassi mentre fai la modifica, i resolver che hanno in cache il vecchio record hanno comunque diritto a un giorno intero. Abbassare il TTL aiuta solo la prossima modifica.
• Alcuni resolver ignorano i TTL brevi. Diversi provider internet impongono un proprio minimo, comunemente un'ora o più, indipendentemente da cosa dice il tuo record.
• Le modifiche ai nameserver sono più lente. I record NS a livello di registro spesso hanno un TTL misurato in giorni, quindi cambiare provider DNS può richiedere davvero uno o due giorni per assestarsi ovunque.
• Conta anche la cache negativa. Se un nome non esisteva quando qualcuno lo ha cercato, anche la risposta "non esiste" viene messa in cache, per il periodo impostato dal campo minimo del SOA della zona.
• Cache concatenate. Un browser mette in cache il DNS, il sistema operativo mette in cache il DNS, e un resolver aziendale può trovarsi davanti a quello pubblico. Ogni livello aggiunge il proprio ritardo.
• Connessioni di lunga durata. Le applicazioni che hanno risolto un nome host una volta all'avvio continuano a usare quell'indirizzo finché non si riavviano, indipendentemente da cosa dice ora il DNS.

Come rendere veloce la prossima modifica

1. Abbassa prima il TTL, poi aspetta. Riduci il TTL del record a 300 secondi e lascialo così per almeno la durata del vecchio TTL prima di fare la modifica reale. A quel punto ogni copia in cache porta il valore breve.
2. Fai la modifica. Con un TTL di 300 secondi, la maggior parte dei resolver la recepisce entro cinque minuti.
3. Tieni il vecchio server attivo durante la sovrapposizione. Non spegnerlo nel momento in cui il DNS viene aggiornato. Lascialo servire finché il traffico verso di esso non si ferma, e la migrazione passa senza che nessuno se ne accorga.
4. Verifica contro i nameserver autoritativi e diversi resolver pubblici prima di dichiararla conclusa.
5. Rialza il TTL una volta che la modifica si è assestata, così il traffico normale torna a beneficiare della cache.

Per un cambio di nameserver non c'è scorciatoia, perché il TTL del registro non è tuo da impostare. Pianifica un giorno o due, e mantieni entrambi i provider DNS che servono record identici per tutto il tempo, così non conta quale dei due interroga un resolver.

Dopo che la modifica si è assestata

Controllare a mano qualche resolver ti dice quanto si è diffusa una modifica nel momento in cui guardi, il che è utile durante una migrazione e inutile il resto del tempo. I guasti che vale la pena intercettare sono quelli successivi: un record che cambia senza che nessuno se ne accorga, un nameserver che smette di rispondere, una zona che scade. Il monitoraggio DNS continuo interroga da molte ubicazioni secondo una pianificazione e avvisa quando la risposta smette di corrispondere a quella attesa, il che intercetta anche il caso "funziona da qui, non funziona da là" che una singola ricerca non può vedere. Esegui una ricerca ora con lo strumento di query DNS. Se il sito è irraggiungibile per te ma va bene altrove, è giù per tutti o solo per me continua da lì.