Introduzione: domini, root nameserver e propagazione della delega
La propagazione delle modifiche DNS non riguarda solo i record di un singolo dominio. Per un'introduzione alla propagazione dei record DNS standard (A, MX, CNAME, ecc.) gestiti sui nameserver del provider, consulta questa guida introduttiva sulla gestione DNS.
I domini sono registrati tramite organizzazioni che gestiscono le varie estensioni (TLD) e il puntamento del dominio verso i nameserver scelti dall’utente avviene attraverso i root nameserver del registro competente.
Quando i nameserver appartengono allo stesso dominio che delegano, il registro deve includere anche i relativi indirizzi IP, detti glue record, per evitare loop di risoluzione. I glue record vengono gestiti automaticamente dal provider DNS.
Possiamo distinguere due aspetti:
- Propagazione DNS: riguarda i record (A, AAAA, MX, CNAME, …) di uno specifico dominio.
- Propagazione della delega: riguarda i record NS memorizzati sui root nameserver del TLD.
Alla registrazione di un nuovo dominio o al cambio di nameserver, il registrar invia il comando di aggiornamento al registro, e sul WHOIS la modifica risulta visibile in pochi istanti.
Però i root nameserver dei registri non sono gestiti come i nameserver dei singoli provider: amministrano milioni di domini e sono interrogati da resolver di tutto il mondo. Non possono quindi adottare TTL estremamente bassi né aggiornarsi in tempo reale.
In genere gli aggiornamenti vengono applicati a intervalli prefissati e il TTL dei record NS memorizzati sui root nameserver può arrivare a 24–48 ore. Di conseguenza, l’aggiunta o la modifica di una delega può richiedere diverse ore per diventare effettiva su tutti i server del registro, oltre a un ulteriore tempo affinché la modifica si propaghi ai resolver. Nel frattempo si possono ricevere errori come hostname not found o visualizzare ancora il vecchio hosting.
Come verificare lo stato della propagazione
Tutto parte dai root server, i server autoritativi della zona radice. Possiamo interrogarli per verificare se la delega è già stata aggiornata.
I root server si possono ottenere interrogando il resolver locale.
Esempio Linux:
$ dig . NS +short
…
m.root-servers.net.
c.root-servers.net.
l.root-servers.net.
f.root-servers.net.
e.root-servers.net.
i.root-servers.net.
j.root-servers.net.
d.root-servers.net.
h.root-servers.net.
a.root-servers.net.
k.root-servers.net.
b.root-servers.net.
g.root-servers.net.
…
Esempio Windows:
> nslookup -type=NS .
…
(root) nameserver = k.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = g.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = i.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = a.root-servers.net
…
Per ottenere i nameserver dell'estensione .com:
Procediamo con la query su uno dei server ottenuti prima, proviamo a.root-servers.net
Esempio Linux:
$ dig com NS @a.root-servers.net
…
;; AUTHORITY SECTION:
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
…
Esempio Windows:
> nslookup -type=NS com a.root-servers.net
…
com nameserver = l.gtld-servers.net
com nameserver = j.gtld-servers.net
com nameserver = h.gtld-servers.net
com nameserver = d.gtld-servers.net
com nameserver = b.gtld-servers.net
com nameserver = f.gtld-servers.net
com nameserver = k.gtld-servers.net
com nameserver = m.gtld-servers.net
com nameserver = i.gtld-servers.net
com nameserver = g.gtld-servers.net
com nameserver = a.gtld-servers.net
com nameserver = c.gtld-servers.net
com nameserver = e.gtld-servers.net
…
Verificare il TTL del TLD
Ora abbiamo i root nameserver dell'estensione .com, scegliamo uno dei nameserver e richiediamo il record SOA dell'estensione. Il campo minimum (o default TTL su Windows) è utile per capire quanto può durare una risposta negativa (NXDOMAIN).
Esempio Linux:
$ dig com SOA +multiline @a.gtld-servers.net
…
;; ANSWER SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. (
1754585805 ; serial
1800 ; refresh (30 minutes)
900 ; retry (15 minutes)
604800 ; expire (1 week)
900 ; minimum (15 minutes)
)
…
Esempio Windows:
> nslookup -type=SOA com a.gtld-servers.net
…
com
primary name server = a.gtld-servers.net
responsible mail addr = nstld.verisign-grs.com
serial = 1754585620
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
…
In entrambi i casi, abbiamo trovato il TTL predefinito che nell’esempio è 15 minuti.
Verificare i record NS del dominio
Esempio Linux:
$ dig gidinet.com NS @a.gtld-servers.net
…
;; AUTHORITY SECTION:
gidinet.com. 172800 IN NS dns1.gidinet.com.
gidinet.com. 172800 IN NS dns2.gidinet.com.
gidinet.com. 172800 IN NS dns3.gidinet.com.
gidinet.com. 172800 IN NS dns4.gidinet.com.
gidinet.com. 172800 IN NS dns5.gidinet.com.
…
Esempio Windows (con -debug per vedere il TTL):
> nslookup -type=NS -debug gidinet.com a.gtld-servers.net
…
AUTHORITY RECORDS:
-> gidinet.com
nameserver = dns1.gidinet.com
ttl = 172800 (2 days)
-> gidinet.com
nameserver = dns2.gidinet.com
ttl = 172800 (2 days)
-> gidinet.com
nameserver = dns3.gidinet.com
ttl = 172800 (2 days)
-> gidinet.com
nameserver = dns4.gidinet.com
ttl = 172800 (2 days)
-> gidinet.com
nameserver = dns5.gidinet.com
ttl = 172800 (2 days)
…
Il TTL associato ai record NS (es. 172800 = 48 h) mostra per quanto tempo i resolver possono mantenere in cache la vecchia delega.
Strategie per evitare ritardi nella propagazione
Dopo un cambio di nameserver è buona norma non accedere subito al dominio dai propri dispositivi: se il resolver locale memorizza la vecchia delega, resterà in cache per l'intero TTL. Lo stesso vale per gli strumenti di verifica online, che potrebbero diffondere ulteriormente l'informazione errata.
È possibile interrogare ciascun root nameserver dell'estensione per verificare se è già stato aggiornato o meno, ripetendo il comando visto sopra per ognuno.
Esegui il comando una volta per ciascun root nameserver dell'estensione (a.gtld-servers.net, b.gtld-servers.net, …):
Esempio Linux:
$ dig gidinet.com NS @nameserver
Esempio Windows:
> nslookup -type=NS gidinet.com nameserver
Strumenti utili per la verifica della propagazione della delega
Per semplificare la diagnosi, abbiamo preparato questi script open source che automatizzano i passaggi descritti. Ognuno:
- Identifica il TLD del dominio fornito
- Ottiene l'elenco dei root nameserver del registro
- Interroga ciascun nameserver e mostra i record NS restituiti
Scarica il formato che preferisci:
- check-delega.sh - Bash (Linux)
- CheckDelega.cs - Esempio C#
Gli script possono essere liberamente modificati e distribuiti.