Immaginiamo di cambiare l'indirizzo del server di un dominio: da casa si apre il nuovo sito, mentre sul telefono si raggiunge ancora il vecchio server. Anche digitando lo stesso nome, due dispositivi possono ottenere temporaneamente risultati diversi se passano attraverso cache DNS differenti. La cache HTTP riguarda il riutilizzo delle risposte delle pagine; la cache DNS riguarda invece le informazioni necessarie per trovare l'indirizzo a cui collegarsi.
Seguiamo l'host di una biblioteca immaginaria, www.library.example, per capire il rapporto tra risoluzione dei nomi e cache. Il nome e la sequenza temporale sono esempi didattici: non abbiamo misurato le risposte di un servizio reale. Distingueremo come il DNS fornisce un indirizzo, perché una modifica può apparire in ritardo e quali problemi possono verificarsi dopo la risoluzione.
1. Uno stesso nome può avere diversi tipi di risposta
Il DNS associa informazioni ai nomi di dominio mediante diversi tipi di record. Un record A indica un indirizzo IPv4 e un record AAAA un indirizzo IPv6; un nome può avere più indirizzi. CNAME è un alias verso un altro nome, MX identifica i server che ricevono la posta e NS indica i server dei nomi autoritativi della zona. Anche interrogando lo stesso nome, dunque, la risposta dipende dal tipo di record richiesto.
Come spiega la documentazione Cloudflare sui record DNS, il valore di CNAME è un altro nome, non un indirizzo IP. Se serve un indirizzo, può essere necessario continuare la risoluzione per quel nome. Nell'URL https://www.library.example/books, il nome host trattato dal DNS è www.library.example: il percorso /books e il contenuto della pagina non sono record DNS. Impostare un CNAME non crea automaticamente un reindirizzamento HTTP che cambia l'indirizzo nel browser.
2. Come il resolver ricorsivo trova il server autoritativo
Il sistema di risoluzione del dispositivo chiede normalmente una risposta al resolver ricorsivo configurato. Il resolver usa le informazioni disponibili nella cache oppure interroga altri server DNS per restituire una risposta finale o un errore. Lo standard terminologico DNS RFC 9499 distingue il ruolo di chi risolve per conto del richiedente da quello del server autoritativo, che dispone dei dati della propria zona. Per interpretare la provenienza di una risposta occorre capire in quale ruolo sta operando il server.
In un percorso semplificato, senza cache né inoltro intermedio, il resolver ottiene dalla radice un riferimento ai server del dominio di primo livello e da questi un riferimento ai server autoritativi della zona interessata. Infine ottiene il record richiesto o un alias dal server autoritativo. Un singolo server radice non conserva gli indirizzi IP di tutti i siti Web. Nella pratica si può partire da informazioni di delega già memorizzate oppure inoltrare la richiesta a un altro resolver: l'intera sequenza non si ripete necessariamente a ogni visita.
3. Il TTL riguarda la cache, non un orologio mondiale
Il TTL di un record comunica in secondi la durata di conservazione nella cache. Nelle normali risposte dalla cache, il tempo residuo diminuisce durante la conservazione. Se un resolver memorizza un indirizzo alle 10:00 con TTL di 300 secondi, alle 10:02 lo stesso dato avrà circa 180 secondi residui. La tabella suppone un solo resolver, senza nuove interrogazioni anticipate, aggiornamenti preventivi o risposte con dati scaduti.
| Ora ipotetica | Indirizzo sul server autoritativo | Comportamento di questo resolver |
|---|---|---|
| 10:00 | Vecchio indirizzo | Memorizza il vecchio indirizzo con TTL di 300 secondi |
| 10:01 | Passaggio al nuovo indirizzo | Nella cache restano ancora 240 secondi |
| 10:03 | Nuovo indirizzo | Può riutilizzare il vecchio indirizzo per i 120 secondi residui |
| Prima richiesta dopo le 10:05 | Nuovo indirizzo | Si suppone che interroghi di nuovo e ottenga il nuovo indirizzo invece del dato scaduto |
Un altro resolver potrebbe aver memorizzato quel record più tardi oppure non averlo mai consultato. Tempi di aggiornamento diversi impediscono di ricavare da un unico TTL l'istante in cui tutti gli utenti del mondo vedranno la modifica. Una cache può anche eliminare i dati prima della scadenza; aggiornare una pagina non svuota la cache di un resolver condiviso. Il TTL aiuta a capire il riutilizzo delle risposte DNS, ma non è il limite temporale dell'intera connessione Web o dell'aggiornamento dello schermo.
4. Quando abbassare il TTL e come si memorizza un'assenza
Una cache che ha ricevuto il vecchio indirizzo con TTL di 3.600 secondi non viene informata immediatamente se l'operatore abbassa ora il TTL a 60 secondi. Per una modifica programmata bisogna intervenire in anticipo e considerare quanto possano rimanere le risposte memorizzate con la durata precedente. Un TTL basso può favorire verifiche più frequenti, ma aumenta anche il carico delle interrogazioni e la dipendenza dai server autoritativi. Conviene collegare il valore al piano di modifica e alla gestione dei guasti, anziché copiare lo stesso numero breve per ogni servizio.
Anche NXDOMAIN, che indica un nome inesistente, e NODATA, cioè l'assenza del tipo di record richiesto per un nome esistente, possono essere memorizzati. Lo standard sulla cache negativa RFC 2308 definisce la durata di queste risposte usando il minore tra il TTL del record SOA autoritativo e il campo MINIMUM del SOA. Perciò una precedente risposta di assenza può persistere anche subito dopo l'aggiunta di un host. Guardare soltanto il TTL del nuovo record A non chiarisce la durata di quella risposta negativa.
5. Confrontare lo stesso nome, tipo e server
Annotate il nome esatto interrogato, il tipo, come A o AAAA, il server DNS consultato e l'ora. Dove è installato dig, un comando come dig example.com A specifica nome e tipo. Per un problema reale sostituite example.com con l'host che intendete controllare. Il comando illustra una procedura: non è una registrazione di un'esecuzione o di tempi di risposta misurati per questo articolo.
Esaminate insieme lo stato della risposta e nome, tipo, valore e TTL nella sezione ANSWER. Ripetendo la stessa domanda allo stesso resolver, osservate se il TTL diminuisce, senza considerare automaticamente un aumento come un errore. Il dato potrebbe essere stato aggiornato in anticipo oppure potrebbe aver risposto un altro nodo della cache. Tenere separate le risposte A e AAAA aiuta a capire quale famiglia di indirizzi presenta differenze.
Gli operatori possono confrontare la risposta del resolver ricorsivo utilizzato con quella dei server autoritativi della zona, mantenendo identici nome e tipo. Se differiscono, si possono verificare nell'ordine il TTL residuo, la coerenza dei dati tra server autoritativi e la delega. La risposta di un resolver pubblico non rappresenta lo stato di tutti gli utenti. Anche il DNS interno di una rete aziendale o una configurazione DNS separata nel browser può cambiare il percorso: registrate quindi anche l'ambiente di connessione.
6. Separare errori DNS, errori di connessione ed eccezioni
NXDOMAIN risponde che il nome non esiste; NODATA segnala l'assenza del tipo richiesto. SERVFAIL indica invece che il server non ha potuto completare l'interrogazione, mentre un timeout descrive la mancata ricezione di una risposta entro l'attesa prevista. Non bisogna interpretare tutti questi casi come la cancellazione del dominio. Conservare il codice eventualmente ricevuto e il server interrogato permette di scegliere la verifica successiva.
Vedere una risposta precedente dopo la scadenza del TTL non significa sempre che le regole siano state violate. Il meccanismo serve-stale di RFC 8767 definisce come usare dati scaduti per migliorare la disponibilità in situazioni eccezionali in cui non si riesce ad aggiornarli presso i server autoritativi. Non tutti i resolver lo utilizzano con la stessa configurazione. Perciò occorre controllare il comportamento del resolver effettivo, anziché dedurre il tempo di applicazione della modifica da un singolo TTL.
Infine, risolvere correttamente un indirizzo non garantisce che il sito Web sia raggiungibile. Il percorso di rete, il certificato TLS, il server Web e l'applicazione sono fasi distinte. Se la risposta DNS contiene l'indirizzo previsto ma la pagina non si apre, l'indagine deve proseguire nella fase di connessione successiva. Registrare separatamente risposte DNS e Web aiuta a localizzare il guasto prima di cancellare cache delle pagine o modificare indiscriminatamente le impostazioni DNS.