Che cos’è la propagazione DNS e perché richiede tempo?
La propagazione DNS è il nome comune del periodo in cui le risposte DNS memorizzate scadono e vengono aggiornate dopo una modifica. Non esiste un interruttore centrale che aggiorni subito ogni rete. Ogni resolver conserva la risposta in base al TTL.
Risposta autorevole e risposta in cache
Il nameserver autorevole possiede il valore ufficiale attuale. Un resolver pubblico o dell’ISP può restituire temporaneamente un valore precedente dalla cache. Due utenti possono quindi raggiungere IP diversi nello stesso momento pur esistendo un solo valore corrente nella zona.
Il ruolo del TTL
Time To Live definisce per quanto una risposta può essere conservata. Se si modifica con un TTL elevato, i resolver che hanno già il vecchio dato possono usarlo fino alla scadenza. Ridurlo aiuta solo se fatto con sufficiente anticipo rispetto al cutover.
Perché non esiste una durata garantita
I resolver interrogano in momenti diversi; browser, dispositivi, reti aziendali e ISP hanno cache proprie e alcuni sistemi applicano minimi. Ogni tempo è quindi una stima. Il processo dipende da come funziona il DNS e dai nameserver autorevoli.
Ridurre il rischio prima del cutover
- Documentare zona e servizi dipendenti.
- Preparare sito, SSL, email e verifiche a destinazione.
- Ridurre il TTL in anticipo dove appropriato.
- Testare la destinazione prima della modifica produzione.
- Mantenere temporaneamente il vecchio servizio e un ripristino della configurazione precedente.
Come verificare
Confronta la risposta autorevole con più resolver pubblici. Controlla separatamente dominio root, www e MX quando è coinvolta l’email. Svuotare la cache locale aiuta un solo dispositivo, non aggiorna gli altri resolver.
Cosa non risolve la propagazione
Attendere non corregge un IP sbagliato, un record assente, una delega errata, un host non configurato, SSL non valido o una casella inesistente. Se la risposta autorevole è sbagliata, sarà proprio quel valore a essere memorizzato.
Un cambio sicuro combina preparazione, test, osservazione e ripristino della configurazione precedente. Non dipende da promesse come “sempre 24–48 ore”, perché il risultato effettivo varia con il TTL precedente e lo stato di ogni cache.
Esempio di cambio pianificato
Il team riduce il TTL in anticipo, prepara e prova il nuovo server, quindi modifica il valore autorevole. Controlla più resolver, mantiene temporaneamente il vecchio server e ripristina un TTL ragionevole quando il traffico si stabilizza.
Ciclo completo di una risposta in cache
Quando un resolver ricorsivo richiede un record, il server autorevole restituisce valore e TTL. Il resolver conserva la risposta e ne riduce la durata residua. Le richieste successive possono usare la cache senza una nuova interrogazione. Alla scadenza, la ricerca seguente ottiene il valore attuale e avvia un nuovo ciclo.
Due utenti possono vedere risultati diversi perché i loro resolver hanno memorizzato il vecchio valore in momenti differenti. Una cache può essersi già aggiornata, mentre un’altra possiede ancora tempo valido. Ciò non dimostra necessariamente un’incoerenza tra i server autorevoli.
Più livelli di cache
Informazioni temporanee possono trovarsi anche nel browser, sistema operativo, router o rete aziendale. Cancellare la cache del browser non equivale a svuotare quella DNS del sistema e nessuna delle due azioni aggiorna il resolver dell’operatore Internet. Il confronto con resolver pubblici indipendenti aiuta a individuare il livello.
Ridurre il TTL prima di una transizione
La riduzione deve avvenire abbastanza presto da far scadere risposte salvate con il TTL precedente. Sito, certificato, email e monitoraggio vengono preparati prima della modifica in produzione. Durante il passaggio, il TTL minore limita la durata delle nuove cache. Dopo la stabilizzazione si ripristina un valore ragionevole.
Propagazione o configurazione sbagliata?
Controlla prima la risposta autorevole. IP errato, www mancante, vecchio AAAA o MX sbagliato non si correggono aspettando. Un DNS corretto non dimostra inoltre che server, SSL o applicazione funzionino. La diagnosi deve proseguire al livello indicato dai dati.
Cache positive e negative
Non vengono memorizzati soltanto i record esistenti. Anche la risposta che un nome o un tipo di record non esiste può restare in cache per un intervallo definito. Se un nome host viene creato subito dopo una precedente ricerca fallita, alcuni resolver possono continuare temporaneamente a segnalarlo come assente. Serve una configurazione autorevole corretta e la scadenza della cache, non modifiche ripetute e casuali.
Come interpretare risultati di risoluzione diversi
Se il server autorevole restituisce già il nuovo valore ma un resolver ricorsivo mantiene quello precedente, la cache è una spiegazione plausibile. Se è la risposta autorevole a essere errata, attendere non correggerà la configurazione. Confronta sempre il nome e il tipo di record esatti: dominio principale, www, host di posta e nomi di verifica possono avere TTL differenti. In questo modo si distingue una cache non ancora scaduta da un errore reale.
Domande frequenti
Perché rete mobile e Wi-Fi differiscono?
Possono usare resolver con cache diverse.
Quando il cambio è completo?
Quando i dati autorevoli sono corretti, i resolver principali concordano e sito, SSL ed email funzionano da reti indipendenti.
