Con l’espressione propagazione DNS si descrive il periodo in cui una modifica della zona DNS diventa visibile in resolver e dispositivi diversi. Non avviene una diffusione simultanea da un singolo server a tutti i computer: ciascun resolver può conservare una risposta in cache e aggiornarla quando scade il relativo TTL. Inoltre, il risultato dipende dai nameserver autoritativi e dalla delega pubblicata dal registro. Per questo motivo, dopo aver cambiato un record, alcune reti possono già raggiungere la nuova destinazione mentre altre continuano temporaneamente a usare quella precedente. La variazione non è un trasferimento del sito né un cambiamento istantaneo della registrazione del dominio.
Il ruolo delle cache
Il TTL, o Time To Live, indica per quanto tempo una risposta può essere mantenuta in cache. Se un record aveva un TTL di diverse ore, un resolver che lo ha consultato poco prima della modifica può continuare a servirlo fino alla scadenza. Quando il TTL termina, il resolver richiede nuovamente il dato e apprende il valore corrente dall’autorità. Anche il sistema operativo e il browser possono mantenere cache locali per intervalli più brevi. Non tutti i sistemi rispettano esattamente ogni indicazione nello stesso modo, e una cache negativa può memorizzare per un periodo limitato l’assenza di un record.
Abbassare il TTL prima di un cambio può ridurre la durata delle risposte vecchie, ma il nuovo TTL deve essere stato pubblicato e osservato prima di modificare il valore principale. Se la riduzione e la migrazione vengono eseguite nello stesso momento, i resolver che avevano già memorizzato il vecchio TTL continueranno a rispettarlo. Dopo il passaggio, si può riportare il TTL a un valore adeguato alla stabilità del servizio. Un TTL molto basso non è sempre preferibile: aumenta il numero di interrogazioni e può essere ignorato o limitato da alcuni resolver.
Record e delega sono livelli diversi
La propagazione di un record A o CNAME nella zona non va confusa con un cambiamento dei nameserver. Se cambia la delega, i resolver devono apprendere quali server sono autoritativi per il dominio; una cache della delega può durare diversamente da quella dei singoli record. Anche la modifica dei DNSSEC, quando presenti, richiede coordinamento tra zona figlia e dati DS nel parent: un’incoerenza può causare risposte di errore di validazione invece di un semplice ritardo. Durante migrazioni importanti vanno quindi pianificate sia le modifiche alla delega sia quelle alla zona, con attenzione alle dipendenze.
La propagazione non corregge dati errati. Se la zona è pubblicata sul provider sbagliato o il nuovo indirizzo punta a un server non configurato, aspettare non risolve il problema. Una query al nameserver autoritativo mostra che cosa è stato effettivamente pubblicato; una query a un resolver ricorsivo mostra invece ciò che quel resolver restituisce al momento, potenzialmente da cache. Distinguere queste due viste evita di attribuire ogni discrepanza a un’attesa generica.
Come pianificare e verificare
Prima di un cambio si inventariano i record della zona, si annotano i valori e i TTL e si prepara un piano di ripristino. Il nuovo hosting dovrebbe essere pronto prima che il DNS venga spostato, con certificati, virtual host, contenuti e servizi di posta verificati. Per evitare interruzioni, le due destinazioni possono dover funzionare in parallelo per un intervallo. Dopo l’aggiornamento si interrogano i nameserver autoritativi e alcuni resolver indipendenti, quindi si prova il servizio da reti differenti. Le cache possono rendere il risultato non uniforme, perciò la finestra di manutenzione deve considerare il TTL precedente e la criticità dell’applicazione.
La verifica include web, posta e qualsiasi servizio collegato: un sito funzionante non dimostra che MX, SPF, DKIM, DMARC o verifiche di terze parti siano rimasti corretti. È utile monitorare errori, certificati e accessi durante la transizione. In sintesi, la propagazione DNS è l’effetto temporale delle cache e dell’aggiornamento delle informazioni distribuite. La gestione migliore consiste nel pianificare i TTL, modificare il livello corretto, misurare le risposte e mantenere il servizio pronto su entrambe le destinazioni finché la transizione non è stabile.
← Tutto il glossario