La propagazione DNS è il tempo che passa tra la modifica di un record DNS e il momento in cui tutti vedono il nuovo valore. In realtà non viene inviato nulla: i resolver sparsi per internet continuano a servire la copia che hanno in cache finché il suo TTL (time to live) non scade, e solo allora tornano a chiedere. La maggior parte delle modifiche ai record è visibile ovunque entro il TTL del vecchio record, spesso da pochi minuti a un’ora. Il cambio dei nameserver presso il registrar può richiedere fino a due giorni. Per capire a che punto è una modifica, chiedi ai nameserver del dominio che cosa pubblicano, poi chiedi a qualche resolver pubblico che cosa hanno ancora in cache.
Che cosa succede quando modifichi un record
Il browser di un visitatore non interroga direttamente il tuo provider DNS. La richiesta attraversa diverse cache, e ognuna può rispondere a memoria:
Il browser conserva per poco tempo le risposte recenti.
Il sistema operativo ha una propria cache del resolver.
Un resolver ricorsivo dell’ISP, della rete aziendale o di un servizio pubblico come 1.1.1.1 o 8.8.8.8 tiene in cache ogni risposta per tutto il tempo consentito dal suo TTL.
I nameserver autoritativi del tuo dominio contengono i record reali. All’inizio sono gli unici a conoscere la modifica.
Quando salvi una modifica presso il tuo provider DNS, i nameserver autoritativi di solito la servono nel giro di secondi o minuti. Ogni cache più a valle continua a dare la vecchia risposta finché la sua copia non scade. Per un po’, quindi, due visitatori su reti diverse possono vedere server diversi: è normale, non è un errore. Il TTL lo imposti tu, per ogni record, in secondi; la voce del glossario sulla propagazione DNS ne offre la versione breve.
Quanto dura la propagazione DNS
Record ordinari: il vecchio TTL
Per un record A, AAAA, CNAME, MX o TXT, l’attesa massima è il TTL che il vecchio record aveva quando i resolver l’hanno messo in cache. Un record con TTL 3600 può essere servito dalla cache fino a un’ora dopo la modifica. Abbassare il TTL nello stesso momento della modifica non serve, perché i resolver che hanno già la vecchia copia la tengono per il vecchio TTL.
Cambio dei nameserver: la zona padre
Spostare un dominio su un altro provider DNS significa modificarne i record NS presso il registrar. Questi record sono pubblicati nella zona padre, per esempio .com, ed è la zona padre a stabilirne il TTL, non tu. Puoi verificarlo da solo interrogando direttamente un server .com:
dig +norecurse @a.gtld-servers.net example.com NS
La risposta elenca i nameserver con un TTL di 172800 secondi, cioè 48 ore. Da qui nasce il consiglio di aspettare “fino a 48 ore”. In quel periodo alcuni resolver interrogano il vecchio provider e altri il nuovo, quindi entrambi devono servire gli stessi record finché la modifica non si è assestata.
Nomi nuovi: il caching negativo
Se qualcuno ha cercato un nome prima che esistesse, per esempio un nuovo sottodominio che hai testato troppo presto, i resolver possono mettere in cache anche la risposta “nome inesistente”. La RFC 2308 ne fissa la durata: il valore più basso tra il campo minimum del record SOA e il TTL del record SOA stesso. Ecco perché un sottodominio appena creato può mostrare DNS_PROBE_FINISHED_NXDOMAIN per un po’ su una rete e funzionare su un’altra.
Applicazioni che si tengono stretti gli indirizzi
Un programma in esecuzione continua, come un application server o un proxy, può risolvere un hostname una sola volta all’avvio e conservare l’indirizzo fino al riavvio successivo, qualunque cosa dica il TTL. Se un servizio continua a parlare con il vecchio server quando tutti gli altri sono già passati al nuovo, riavvialo prima di dare la colpa al DNS.
Come verificare la propagazione DNS
Parti dalla fonte e procedi verso l’esterno. Prima conferma che la modifica è pubblicata, poi guarda quali cache hanno ancora la vecchia risposta.
1. Trova i nameserver autoritativi
dig NS example.com +short
Se non sono i nameserver del provider su cui hai fatto la modifica, hai modificato la zona sbagliata. È uno dei motivi più comuni per cui una modifica “non si propaga mai”.
2. Interroga direttamente ogni nameserver
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Ripeti per ogni nameserver dell’elenco. Tutti dovrebbero restituire il nuovo valore e lo stesso numero di serie SOA, il terzo campo della risposta SOA. Un server con un numero di serie più vecchio non ha ancora ricevuto l’aggiornamento: è la propagazione interna al tuo provider, e di solito si risolve in pochi minuti.
3. Interroga i resolver pubblici
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Senza +short, dig mostra il TTL di ogni risposta. Se arriva da un resolver, quel numero indica il tempo che resta alla sua copia in cache: un vecchio valore con 1200 secondi rimasti verrà sostituito entro 20 minuti. Su Windows, nslookup -type=A example.com 1.1.1.1 interroga un resolver specifico, ma senza mostrare il TTL. Il nostro DNS lookup gratuito mostra le risposte e i TTL per qualsiasi tipo di record dal resolver del nostro server a Stoccolma, senza installare nulla.
4. Segui la delega dopo un cambio di nameserver
dig +trace example.com
+trace parte dalla root e segue i rimandi fino ai tuoi nameserver, ignorando le cache lungo il percorso. Se la traccia termina sul nuovo provider, la modifica presso il registrar è attiva e non resta che aspettare che le cache si aggiornino.
Pianifica la modifica perché la propagazione non faccia danni
Dopo una modifica non puoi accelerare la propagazione, ma puoi renderla breve prima di iniziare. Per il passaggio a un nuovo server:
QuandoPassaggioAlmeno un vecchio TTL primaAbbassa il TTL del record, per esempio da 3600 a 300 secondi.Prima della modificaConfigura il nuovo server e testalo, per esempio con una voce nel file hosts o con curl –resolve.La modificaPunta il record sul nuovo server e controlla la risposta autoritativa.Durante la propagazioneLascia acceso il vecchio server, con gli stessi contenuti. Alcuni visitatori ci arrivano ancora.Più o meno un giorno dopoRialza il TTL e spegni il vecchio server.
Per un cambio di nameserver, copia prima tutti i record sul nuovo provider e confronta le due zone record per record, MX e TXT compresi. Un record TXT dimenticato manda in tilt l’autenticazione delle email; il checker SPF, DKIM e DMARC ti dice se i controlli passano ancora. Se il dominio usa DNSSEC, segui le indicazioni del nuovo provider per il record DS presso il registrar: un record DS che non corrisponde ai nuovi nameserver fa rispondere SERVFAIL ai resolver che eseguono la validazione.
Svuotare le cache che controlli
Puoi svuotare le tue cache per vedere prima il nuovo valore, il che aiuta durante i test. Per i tuoi visitatori non cambia nulla.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: apri chrome://net-internals/#dns e svuota la host cache.
Resolver pubblici: Cloudflare e Google ti permettono di eliminare un singolo nome dalle loro cache, dalla pagina di purge di 1.1.1.1 e dalla pagina di flush di Google Public DNS.
Il resolver del tuo ISP e quelli dei tuoi visitatori non si possono svuotare dall’esterno. Scadono secondo i loro tempi.
Quando non è la propagazione
Se i nameserver autoritativi restituiscono ancora il vecchio valore, aspettare non serve. Cerca piuttosto una di queste cause:
Zona o provider sbagliati. Il record è stato modificato presso un provider che il dominio non usa più.
Nome sbagliato. L’apex (example.com) e www.example.com sono record distinti.
Un proxy davanti. Se per il record è attivo un CDN o un proxy, il DNS pubblico restituisce per scelta gli indirizzi del proxy, non quelli del tuo server.
Un record mai salvato, o un errore di battitura nel valore. Confronta quello che vedi nel pannello del provider con la risposta di dig.
La voce tipi di record DNS spiega a che cosa serve ogni record, e la checklist per un sito non raggiungibile copre i passaggi successivi al DNS.
Sapere quando cambia un record con Uptimecheck
La propagazione è la modifica DNS pianificata. Quella non pianificata, un errore di battitura durante una migrazione o un account del registrar compromesso, è quella che merita un avviso. Il monitoraggio DNS di Uptimecheck sorveglia i record A, AAAA, CNAME, MX, NS, SOA, TXT e CAA:
Interroga direttamente i nameserver autoritativi del dominio, così una modifica compare al controllo successivo, senza nessuna cache di resolver in mezzo. Quando i nameserver danno risposte diverse, la pagina del monitor lo segnala.
Un nuovo set di record genera un avviso quando due controlli consecutivi lo hanno rilevato, con i valori vecchi e nuovi, e resta nella cronologia del record.
Inserisci i valori che ti aspetti e il controllo fallisce ogni volta che i record pubblicati non corrispondono: un modo anche per confermare che una modifica pianificata è andata online.
I controlli possono essere eseguiti anche ogni minuto. Start include 10 monitor DNS, Professional 25 e Business 150.
Abbinalo ai controlli di uptime sul sito stesso e al monitoraggio della scadenza del dominio. Per configurarne uno, leggi come configurare il monitoraggio DNS, e scopri i segnali d’allarme in come rilevare i record DNS compromessi.
Scopri nel momento stesso in cui i tuoi record cambiano. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.