Cos'è il DNS e Come Funziona la Risoluzione dei Nomi

Cosa fa davvero il DNS a ogni richiesta

Ogni richiesta verso example.com inizia con una ricerca che non ha niente a che fare con la tua applicazione: qualcosa deve trasformare quel nome in un indirizzo IP prima che un solo pacchetto TCP lasci la macchina. Quella traduzione è il DNS, il Domain Name System, e gira a ogni richiesta, che il client sia un browser, curl, o un servizio backend che ne contatta un altro tramite hostname.

Non c’è un’unica tabella dietro tutto questo. Il DNS è una gerarchia di server, ognuno responsabile di una fetta del namespace, interrogati in sequenza finché non arriva la risposta. Conoscere quella catena è ciò che trasforma “il sito è giù” in “il certificato è scaduto” o “il record punta ancora al vecchio IP”: due problemi molto diversi che da una scheda del browser sembrano identici.

Come un resolver ricorsivo attraversa la gerarchia DNS

Due tipi di server fanno il lavoro, con compiti diversi. Il resolver ricorsivo è quello con cui parla la tua macchina: quello del tuo provider, oppure uno pubblico come 1.1.1.1 o 8.8.8.8. Percorre la gerarchia al posto tuo e restituisce una risposta finale. I server autoritativi contengono i record veri e propri di un dominio, distribuiti su una gerarchia che rispecchia i punti nel nome.

1
2
3
4
5
6
7
8

client  ->  resolver                             una query, una risposta
            resolver -> root server              "chi gestisce .com?"
                     <- nameserver per .com
            resolver -> server TLD .com          "chi gestisce example.com?"
                     <- nameserver per example.com
            resolver -> nameserver example.com   "record A per example.com?"
                     <- 93.184.216.34
client  <-  resolver                             93.184.216.34

I root server non sanno nulla di example.com. Sanno solo quali server gestiscono .com. Il server TLD (top-level domain) .com non contiene neanche lui il record; sa solo quali nameserver sono autoritativi per example.com, quelli a cui punta il tuo registrar quando configuri il dominio. Solo l’ultimo server contiene il record A e restituisce un IP. Tre round trip, così la tua macchina non deve mai sapere che quella gerarchia esiste.

Gran parte di quel percorso non avviene mai in una richiesta reale. I resolver mettono in cache le risposte di root e TLD per ore o giorni, dato che cambiano di rado, quindi una query reale di solito parte già dal server autoritativo del record specifico. Spesso non arriva nemmeno lì: la risposta è già in cache.

I tipi di record DNS che userai davvero

Il server autoritativo di un dominio contiene un insieme di record, ognuno una risposta diversa a una domanda diversa:

Il CNAME è quello che frega tutti. Non punta a un IP; punta a un altro nome, e il resolver deve cercare anche quello, seguendo la catena finché non trova un record A o AAAA. Una CDN o una piattaforma SaaS ti dà un hostname tipo abcd123.cloudfront.net proprio per questo: può cambiare gli IP dietro quel nome quando vuole, e restituirne uno diverso a seconda di dove arriva la query, senza che tu tocchi il tuo record DNS.

Una restrizione blocca chiunque configuri un dominio nudo: un CNAME non può coesistere con altri record sullo stesso nome, e l’apice della zona (example.com senza sottodominio) ha sempre bisogno di record NS e SOA. Quindi non puoi fare un CNAME dell’apice verso l’hostname di una CDN, solo di un sottodominio come www. I provider aggirano il problema con quello che chiamano ALIAS, ANAME, o CNAME flattening: il server autoritativo risolve da solo il target e restituisce un record A, così l’apice sembra un normale record di indirizzo a ogni client pur continuando a seguire gli IP che cambiano dietro la CDN.

Come interrogare il DNS con dig

dig fa queste domande direttamente, senza la cache di un browser in mezzo.

1

dig example.com

La parte che conta è la ANSWER SECTION:

1
2

;; ANSWER SECTION:
example.com.        300    IN    A    93.184.216.34

Cinque campi, in ordine: il nome interrogato, il TTL in secondi (per quanto tempo questa risposta può restare in cache), la classe (IN per internet, di fatto sempre questa), il tipo di record e il valore. Un TTL di 300 significa che qualsiasi resolver che ha questa risposta la richiede di nuovo entro cinque minuti.

Interroga un tipo specifico invece del default A:

1
2
3

dig example.com MX
dig example.com TXT
dig example.com NS

Aggiungi +short quando vuoi solo il valore, che è quello che ti serve in uno script:

1
2

dig +short example.com
93.184.216.34

Interroga un resolver specifico con @. È così che controlli se una modifica è già arrivata a un provider prima che arrivi a te:

1
2

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

+trace riproduce l’intero percorso, dal root server fino alla risposta autoritativa, invece di fidarsi di un risultato in cache:

1

dig +trace example.com

nslookup fa lo stesso lavoro di base con un’interfaccia più vecchia e più verbosa. Vale la pena conoscerlo perché è preinstallato su Windows, dove spesso dig non c’è.

Perché una modifica DNS impiega tempo: TTL e cache

Modifichi un record e non appare ovunque all’istante. Il ritardo viene chiamato “propagazione”, una parola che suggerisce qualcosa che si diffonde su internet copia dopo copia. Non si diffonde niente. Il nuovo valore è attivo sul server autoritativo nel momento stesso in cui lo salvi. Quello che richiede tempo è ogni resolver che aveva già in cache la vecchia risposta e continua a servirla finché quella copia non scade.

Questo cambia la domanda giusta da porsi. Non “quanto dura la propagazione”, ma “che TTL aveva il vecchio record, e quanti resolver l’hanno messo in cache”. Un TTL di 300 secondi significa che un resolver che ha interrogato un minuto fa serve la vecchia risposta per al massimo altri quattro minuti. Un TTL di 86400 significa che qualche resolver da qualche parte risponde con il vecchio IP fino a un giorno dopo la modifica. Alcuni provider ignorano anche il TTL che hai impostato e tengono la cache più a lungo di quanto richiesto, ed è l’altro motivo per cui due persone su reti diverse possono legittimamente vedere risposte diverse a metà di un cambio.

Quindi pianifica la modifica invece di aspettare che passi da sola. Un giorno prima di una migrazione programmata verso un nuovo server o una nuova CDN, abbassa il TTL del record che stai per toccare a 60 o 300 secondi. Quel TTL basso deve prima arrivare alle cache e far scadere le copie di lunga durata. Poi fai la modifica vera: ogni resolver ora si aggiorna entro la nuova finestra breve invece di quella vecchia lunga. Rialza il TTL una volta confermato il nuovo valore.

Errori DNS comuni, e quando il problema non è il DNS

Un CNAME penzolante è l’errore più comune in circolazione. Un sottodominio punta ancora a un servizio dismesso, un vecchio bucket S3 o una distribuzione CDN cancellata, e chiunque rivendichi quel nome dall’altra parte può servire i suoi contenuti sotto il tuo dominio. Cancella il record DNS lo stesso giorno in cui smantelli ciò a cui puntava, non settimane dopo.

Record MX mancanti o sbagliati sembrano un problema del server di posta. Se l’email in uscita funziona ma non arriva mai niente, controlla il record MX del dominio prima di toccare la configurazione del server di posta; potrebbe puntare ancora a un servizio da cui sei migrato mesi fa.

Molte segnalazioni di “il DNS è rotto” non sono affatto DNS. Se dig example.com restituisce il giusto IP attuale e il sito continua a non caricarsi, la risoluzione è già andata a buon fine e il problema è più a valle: una regola del firewall, un certificato che non corrisponde durante l’handshake TLS, o un reverse proxy che instrada in base a un header Host che non riconosce. Controlla la risposta con dig prima di trarre conclusioni da quello che mostra il browser.

Dove controllare per primo quando un dominio non risolve

Esegui dig +short <dominio> contro il tuo resolver di sistema e contro uno pubblico (dig @1.1.1.1 +short <dominio>). Se non sono d’accordo, sei nel mezzo di una modifica, e il vecchio TTL ti dice quanto ancora aspettare. Se sono d’accordo e l’IP è corretto, il DNS ha fatto il suo lavoro: passa a TLS, routing o applicazione. Se l’IP è sbagliato o non torna niente, correggilo sul nameserver autoritativo. Svuotare la cache locale non cambia nulla di ciò che vede chiunque altro.

Articoli correlati

• Cos’è una CDN e Come Funziona
• Cos’è TLS e Come Funziona la Crittografia HTTPS
• Cos’è un Reverse Proxy e Come Funziona