Qualcosa si è rotto. Il sito non carica, le mail rimbalzano, oppure hai cambiato un record un'ora fa e non succede niente. Nove volte su dieci la risposta sta nel DNS — basta sapere dove guardare.
Il DNS è la rubrica di internet: trasforma example.com in un IP a cui il browser può davvero connettersi. Quando fa i capricci, tutto a valle sembra rotto anche se il server sta benissimo. Vediamo come leggerlo come si deve.
I record che vale la pena conoscere
Non serve memorizzarli tutti. Questi sono quelli che saltano fuori:
| Record | Cosa fa | Quando morde |
|---|---|---|
| A | Mappa un nome su un indirizzo IPv4 | Il sito punta al server sbagliato/vecchio |
| AAAA | Uguale, ma IPv6 | Gli utenti IPv6 non ti raggiungono |
| MX | Dove va la posta del dominio | Le mail rimbalzano o spariscono |
| TXT | Testo libero — SPF, DKIM, verifica | La mail finisce nello spam; la verifica fallisce |
| NS | Quali name server sono autoritativi | L'intero dominio risolve male |
| CNAME | Un alias che punta un nome su un altro | Un sottodominio non risolve |
| SOA | Metadati amministrativi della zona | Raramente — ma indica il NS primario |
| CAA | Quali CA possono emetterti certificati | L'emissione del certificato viene rifiutata |
Il nostro strumento di lookup DNS interroga tutti i dieci tipi che supporta — A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV e PTR — contro il resolver che scegli: Google (8.8.8.8), Cloudflare (1.1.1.1) o Quad9 (9.9.9.9), e mostra l'output grezzo in stile dig con i TTL intatti. Leggi la stessa cosa che un sysadmin vede in un terminale.
Noti un record A che punta a un IP che non riconosci? IP WHOIS ti dice in pochi secondi di chi è.
TTL: il numero che tutti ignorano finché non conta
Ogni record porta un TTL — time to live, in secondi. È per quanto tempo ai resolver è concesso mettere in cache la risposta prima di richiedere. Un TTL di 3600 significa «fidati per un'ora».
Questo singolo numero spiega quasi tutto il panico da «la mia modifica DNS non funziona». Un esempio semplice: correggi un record A alle 12:00, ma il suo TTL è 86400 (un giorno intero). I resolver che hanno interrogato il tuo dominio alle 11:30 continuano a restituire il vecchio IP per quasi 24 ore ancora — così per alcuni utenti il sito «si sposta» solo il giorno dopo. Non si è rotto niente; gli hai semplicemente detto che potevano mettere in cache quella risposta per un giorno.
La regola pratica che seguiamo: abbassa il TTL un giorno prima di pianificare una modifica a un record. Portalo a 300 secondi, aspetta che scada il vecchio TTL alto, poi fai la modifica. Ora il cambio si propaga in minuti invece che in un giorno. Rialzalo dopo, così i resolver non riinterrogano di continuo i tuoi name server.
«L'ho cambiato — perché non è online?»
Perché il DNS non ha un pulsante di aggiornamento. Non c'è un server centrale a cui fare push. Il tuo name server autoritativo ha il nuovo valore all'istante — ma ogni resolver che ha già messo in cache il vecchio continua a servirlo finché non scade il suo TTL. E resolver diversi, in paesi diversi, scadono in momenti diversi.
È esattamente per questo che abbiamo costruito il verificatore di propagazione DNS così com'è. Invece di interrogare un solo resolver e accontentarsi, spara la stessa query in parallelo a 15 resolver pubblici sparsi per il mondo — Google e Cloudflare negli USA, Quad9 in Svizzera, Mullvad in Svezia, CZ.NIC in Cechia, Alibaba e DNSPod in Cina, e altri. Vedi il nuovo record accendersi regione per regione man mano che le cache scadono. Quando tutti e 15 concordano, sei davvero propagato.
Regola spannometrica: la «propagazione» non è internet lento. Sono le cache che rispettano il TTL che hai impostato.
Quando il problema è il resolver stesso
A volte i record sono corretti ovunque e il sito risolve comunque lentamente. Questo punta alla latenza del resolver, non ai valori dei record.
Il nostro strumento di tempo di risposta DNS misura proprio questo: lancia dig contro quegli stessi 15 resolver, più volte ciascuno, e riporta minimo, massimo e tempo di query medio per resolver. Se i tuoi utenti stanno in Germania e i tuoi name server rispondono a Francoforte in 8 ms ma a Sydney in 280 ms, è un segnale reale e misurabile — forse è ora di un provider DNS anycast.
Chi controlla la zona: WHOIS e name server
Se i record NS sembrano sbagliati, la domanda diventa chi li ha impostati. Domain WHOIS ti dà il registrar, le date di registrazione e scadenza, i codici di stato del dominio, se DNSSEC è attivo e — cosa cruciale — i name server che il registry ha in archivio.
Una cosa che vale la pena sapere, perché gli strumenti economici la sbagliano: molte estensioni più recenti come .tools, .app e .dev non gestiscono affatto un server WHOIS tradizionale. Interrogale alla vecchia maniera e non ottieni nulla. Il nostro lookup ripiega automaticamente su RDAP — il rimpiazzo moderno basato su JSON — non appena rileva una risposta WHOIS magra o assente, così un dominio .tools restituisce lo stesso risultato strutturato di un .com. Ci siamo imbattuti in questo sul nostro stesso dominio, tra l'altro. La correzione è diventata una funzionalità.
Se i name server presso il registry non corrispondono a quelli che hai impostato dal tuo host DNS, hai trovato il bug: il dominio punta del tutto altrove, e nessuna modifica ai record aiuterà finché non si sistema la delega NS.
Una checklist rapida quando il DNS «non funziona»
- Cerca il record che hai cambiato con lo strumento di lookup. Il nuovo valore c'è del tutto?
- Controlla il TTL. Alto? Stai solo aspettando la scadenza della cache.
- Fai un controllo di propagazione. Risultati misti tra le regioni = le cache stanno ancora scadendo; coerente ovunque = è online.
- Verifica i record NS rispetto al tuo host DNS con WHOIS. Una discrepanza di delega è il vero colpevole più spesso di quanto pensi.
- Ancora lento? Misura il tempo di risposta del resolver prima di incolpare la tua app.
In sintesi
La maggior parte dei «disservizi» DNS non lo è. Sono TTL che fanno esattamente ciò che gli hai detto, o una delega che punta da qualche parte che avevi dimenticato. Leggi i record, rispetta il TTL e verifica la propagazione su più di un resolver prima di concludere alcunché. Parti da un lookup — la risposta di solito è proprio lì, nell'output.
— il team di checkbox.tools