Cos’è una cache DNS, e per quanto tempo restano i record?

Dove viene effettivamente messa in cache una risposta DNS?

Una singola ricerca passa attraverso diverse cache prima che tu ti accorga di qualcosa, e ciascuna mantiene una propria copia per un proprio periodo di tempo:

• Il browser. Chrome, Edge e Firefox mantengono ciascuno una propria piccola cache DNS, separata da quella del sistema operativo. Quella di Chrome è visibile su chrome://net-internals/#dns, e svuotarla riguarda solo quel browser, non il resto della macchina.
• Il resolver stub del sistema operativo. Windows esegue il servizio DNS Client e mette in cache le risposte che puoi elencare con ipconfig /displaydns; macOS fa cache tramite mDNSResponder; la maggior parte dei desktop Linux esegue systemd-resolved, un resolver stub con cache locale che interroghi con resolvectl. Questa è una vera cache con il proprio conto alla rovescia del TTL, non solo una copia di ciò che ha il browser.
• Il router. La maggior parte dei router domestici esegue un piccolo forwarder DNS che risponde dalla propria cache prima di inoltrare una query a monte, il che è il motivo per cui riavviare il router a volte risolve un problema DNS che in realtà era altrove.
• Il resolver ricorsivo. Il resolver del tuo provider internet, o uno pubblico, gestisce la maggior parte delle ricerche su internet e mantiene la cache più grande e più condivisa. Una volta che ha una risposta, ogni dispositivo che lo interroga ottiene la copia in cache finché non scade.

Ogni livello è indipendente. Svuotare la cache sul tuo portatile non fa nulla alla cache che il tuo router o il tuo provider stanno ancora mantenendo, e non fa nulla per la macchina di nessun altro.

Cos’è un TTL, e chi lo rispetta davvero?

Ogni record DNS porta un time to live: un numero in secondi, impostato da chi gestisce la zona, che dice a un resolver per quanto tempo può riusare la risposta prima di richiederla di nuovo. L’RFC 1035 lo definisce come l’intervallo durante il quale un record "può essere messo in cache prima che la fonte dell’informazione debba essere nuovamente consultata", e un TTL pari a zero significa che la risposta non deve mai essere messa in cache.

Ogni cache della catena, browser, resolver stub, router, resolver ricorsivo, dovrebbe rispettare quel numero, facendo il conto alla rovescia dal momento in cui ha recuperato il record per la prima volta. In pratica, alcuni resolver dei provider applicano un proprio minimo sopra di esso, comunemente un’ora o più, indipendentemente da cosa dica la zona sul TTL. Questo è il motivo per cui abbassare un TTL per velocizzare una futura modifica aiuta la maggior parte dei resolver ma non è una garanzia per tutti loro.

Cos’è la cache negativa, e perché un record nuovo di zecca può restare mancante?

Un resolver non mette in cache solo i record che esistono. Se una query torna con nessun nome del genere (NXDOMAIN) o senza alcun record del tipo richiesto, anche quel fallimento viene messo in cache, un comportamento chiamato cache negativa. L’RFC 2308 stabilisce la durata della cache negativa a partire dal campo minimo del record SOA, e l’RFC 9520 rende ora obbligatorio, non più opzionale, mettere in cache quel fallimento per un resolver conforme.

Questo è il meccanismo dietro un problema familiare: crei un nuovo sottodominio, lo interroghi un secondo troppo presto, ottieni NXDOMAIN, e il resolver ricorda "non esiste" per la durata del TTL negativo della zona, anche se il record ora esiste. Windows rende visibili separatamente i due tipi di voce: ipconfig /displaydns elenca sia le risposte positive sia quelle negative, e ipconfig /flushdns scarta esplicitamente le voci di cache negativa come parte dello svuotamento della cache.

Perché un sito si risolve per te e non per qualcun altro?

Perché non esiste un’unica cache condivisa. Due persone che interrogano due resolver diversi, o che interrogano lo stesso resolver in due momenti diversi, possono ottenere due risposte diverse per lo stesso nome. La copia di un resolver potrebbe essere ancora fresca da una ricerca di un’ora fa; un altro potrebbe non aver mai visto quel nome prima e andare a recuperare il valore attuale. Nessuno dei due sbaglia, sono solo su orologi diversi. Se questo sta succedendo subito dopo che hai modificato un record, come verificare la propagazione DNS spiega come confrontare più resolver fianco a fianco e leggere quanto tempo resta a ciascuno.

Come si legge il TTL di un record ancora in cache?

Interroga direttamente il nome e mantieni l’output completo invece della forma breve:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Il numero prima del tipo di record, 847 in questo esempio, sono i secondi rimanenti prima che la copia di quel particolare resolver scada; non è il TTL originale del record, che solo il server autoritativo può dirti con certezza. Esegui la stessa query di nuovo qualche secondo dopo e il numero sarà sceso all’incirca di altrettanti secondi, confermando che stai leggendo un conto alla rovescia dal vivo e non un’impostazione statica. Se un nome non si risolve affatto invece di risolversi con un numero basso, quello è un guasto diverso: come svuotare il DNS copre lo svuotamento della tua cache per primo, e cosa fa davvero un resolver DNS copre cosa succede dopo nella catena quando la tua cache non è il problema.

Una cache spiega perché un visitatore vede una modifica subito e un altro no; non spiega un record che non si aggiorna mai da nessuna parte. Esegui una ricerca dal vivo con lo strumento di query DNS per vedere la risposta attuale dall’esterno della tua rete, e se il sito deve restare raggiungibile secondo una pianificazione invece di essere controllato una volta sola, è a questo che serve il monitoraggio distribuito da molte postazioni. HostTracker monitora siti web dal 2004, oggi osserva oltre 500.000 siti da più di 300 postazioni in 158 città, e avvisa via email, SMS, chiamata vocale, Slack, Telegram e altro quando un controllo fallisce, incluso un controllo che si aspetta un indirizzo IP specifico e segnala il momento esatto in cui la risposta cambia.

Domande frequenti

Una cache DNS piena rallenta il mio computer?

No. Una cache DNS è una piccola tabella di nomi e indirizzi, tipicamente qualche centinaio di voci al massimo, e cercarne una non costa nulla di misurabile. Se le ricerche sembrano lente, la causa non è la cache in sé; di solito è un resolver lontano o sovraccarico.

Svuotare la mia cache risolve le cose per altre persone?

No. ipconfig /flushdns, dscacheutil -flushcache e resolvectl flush-caches svuotano solo la cache sulla macchina su cui li esegui. Tutti gli altri stanno ancora leggendo dal proprio browser, dal proprio router e dal proprio resolver, ciascuno con il proprio timer.

Una cache DNS è la stessa cosa di una cache CDN?

No, anche se le due si confondono. Una cache DNS memorizza la risposta a "qual è l’indirizzo IP di questo nome". Una cache CDN memorizza il contenuto vero e proprio della pagina o del file su un server vicino al visitatore. Svuotare una non ha alcun effetto sull’altra.

Posso impostare il mio TTL se non gestisco il dominio?

No. Il TTL è una proprietà del record, impostata nella zona autoritativa da chi gestisce il DNS del dominio. Come visitatore, l’unica leva che hai è scegliere di interrogare un resolver che rispetta un TTL breve invece di uno che impone un proprio minimo.

Perché il TTL che vedo cambia ogni volta che interrogo?

Perché stai interrogando un resolver diverso, o lo stesso resolver in un momento diverso del suo conto alla rovescia. Interroga direttamente il nameserver autoritativo con dig example.com @ns1.yourdns.example per vedere il TTL così come è stato impostato in origine, senza che nulla sia già stato conteggiato.