Cosa fare quando le modifiche DNS non hanno effetto

Una modifica DNS che sembra non avere effetto è una delle fonti di frustrazione più comuni nel lavoro quotidiano sull'infrastruttura, soprattutto perché il sistema sottostante (una cache distribuita con scadenza per ogni record) resta invisibile finché non lo si va a cercare apposta.

Controlla questi punti prima di pensare che sia rotto

1. Conferma che la modifica sia stata davvero salvata lato autoritativo: interroga direttamente i nameserver autoritativi del dominio invece di un resolver pubblico generico, per escludere un salvataggio fallito in silenzio o non ancora sincronizzato nell'infrastruttura del provider.
2. Controlla il TTL precedente del record: se era impostato, per esempio, a 86400 secondi (24 ore), un resolver che ha messo in cache la vecchia risposta pochi minuti prima della tua modifica non la richiederà di nuovo per un giorno intero.
3. Escludi una cache DNS a livello di browser o di sistema operativo: si trovano ancora più vicine a te del resolver configurato e possono conservare una risposta indipendentemente da esso.
4. Verifica di aver modificato il record che pensi di aver modificato: un errore sorprendentemente comune è aggiornare per sbaglio una zona DNS di staging o non di produzione.
5. Controlla da più di un punto di osservazione: un singolo resolver che mostra la vecchia risposta non ti dice se la modifica si sia propagata altrove.

Una causa meno ovvia: un nameserver secondario o slave in ritardo

Le configurazioni DNS più grandi spesso hanno un nameserver primario (o «master») dove le modifiche vengono effettivamente fatte, e uno o più nameserver secondari («slave») che copiano periodicamente la zona dal primario tramite un trasferimento di zona. Se un secondario non ha ancora recepito l'ultimo trasferimento, per una pianificazione dei trasferimenti configurata male, per un problema di rete tra primario e secondario o semplicemente perché l'intervallo di trasferimento non è ancora trascorso, i resolver che interrogano proprio quel secondario continueranno a ricevere la vecchia risposta anche se il primario è completamente aggiornato e la cache basata sul TTL di ogni resolver è scaduta. È una causa meno comune della semplice cache, ma vale la pena escluderla in particolare quando diversi nameserver autoritativi dello stesso dominio non concordano tra loro, e non solo quando i resolver pubblici non concordano.

Pianificare in anticipo evita la maggior parte dei problemi

Per una modifica pianificata, come una migrazione, un cambio di provider o un passaggio di consegne, abbassare il TTL uno o due giorni prima è la cosa più efficace che puoi fare. Costa un piccolo aumento di query in cambio di una propagazione in pochi minuti invece che in un giorno intero. Impostalo, aspetta che la vecchia finestra di TTL sia trascorsa del tutto, fai la modifica, poi rialza il TTL una volta confermato che tutto è a posto.

Svuotare la cache locale, quando è davvero lei la colpevole

Se i nameserver autoritativi e tutti i resolver pubblici che controlli concordano già sulla nuova risposta, ma una macchina specifica mostra ancora la vecchia, la sospettata rimasta è la cache locale di quella macchina.

Vale la pena farlo solo dopo aver confermato che il lato autoritativo è già corretto: svuotare una cache locale quando il record reale non si è ancora aggiornato ti restituisce solo una copia fresca della stessa vecchia risposta e sembra identico a uno svuotamento fallito.