Cos'è la cache DNS?
La cache DNS è lo storage temporaneo dei risultati delle query DNS da parte di risolutori, sistemi operativi, browser e applicazioni. Quando viene eseguita una ricerca DNS, il risultato viene memorizzato nella cache per un periodo definito dal TTL del record (Time To Live), permettendo di rispondere istantaneamente alle richieste successive dello stesso dominio senza interrogare server autorevoli.
Perché la memorizzazione nella cache DNS è importante
Senza caching, ogni singola richiesta web richiederebbe un lookup DNS completo, aggiungendo latenza e generando traffico DNS massiccio. La cache DNS fornisce:
- "Faster Response Times" Risponde alle chiamate in microsecondi contro millisecondi per la ricerca completa
- Reduced Network Traffic: Domande minori ai server autorevoli
- Resilienza migliorata: La cache locale fornisce risposte anche se i server DNS sono temporaneamente irraggiungibili
- Lower Server Load: I server autorizzati gestiscono meno domande
Come funziona la memorizzazione nella cache DNS
Gerarchia della cache
La cache DNS si verifica a più livelli:
Browser Cache (seconds to minutes)
↓
OS Cache (seconds to minutes)
↓
Local Resolver Cache (minutes to hours)
↓
ISP Resolver Cache (minutes to hours)
↓
Authoritative Name Server (source of truth)
Processo di ricerca nella cache
1. Richiesta utente example.com
2. Ricercatore controlla la sua cache
3. Se miss, OS controlla la sua cache
4. Se miss, il risolutore controlla la sua cache
5. Se manca, domanda ricorsiva ai server autorevoli
6. Risultato memorizzato ad ogni livello basato su TTL
7. Risposta restituita all'utente
Scadenza basata sul TTL
Ogni record DNS include un valore TTL:
example.com. 300 IN A 203.0.113.50
^^^
TTL in seconds (5 minutes)
Le cache memorizzano questo record per 300 secondi, poi lo scartano. La prossima domanda innesca una nuova ricerca.
Livelli di cache DNS
Cache del browser
Moderni browser cache DNS risultati indipendentemente:
Chrome: Utilizza la propria cache DNS (chrome://net-internals/#dns) Firefox: Mantiene la cache interna (circa:networking#dns) Safari: Utilizza il risolutore del sistemaTipica cache del browser TTL: 60 secondi (indipendentemente dal DNS TTL)
Cache del sistema operativo
Windows: risultati del servizio client DNS# View cache
ipconfig /displaydns
# Flush cache
ipconfig /flushdns
macOS: maniglie mDNSResponder caching
# Flush cache (macOS 10.15+)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux: Varie per sistema, spesso risolte dal sistema
# Flush systemd-resolved cache
sudo systemd-resolve --flush-caches
# Check statistics
sudo systemd-resolve --statistics
Cache del resolver
I risolutori DNS ricorrenti (ISP DNS, 8.8.8.8, 1.1.1.1) mantengono grandi cache che servono milioni di utenti:
| Risolvere | Strategia di Cache |
|---|---|
| Google (8.8.8.8) | Rispetta TTL, cache globale |
| Cloudflare (1.1.1.1) | Rispetti TTL, distribuiti |
| ISP Resolvers | Può ignorare i bassi TTL |
Esempi di comportamento della cache
Operazione normale
Query 1: example.com
→ Full lookup: 50ms
→ Cached for 300s (TTL)
Query 2: example.com (1 minute later)
→ Cache hit: 1ms
Query 3: example.com (10 minutes later)
→ Cache expired, full lookup: 50ms
→ Re-cached for 300s
Aggiornamento record DNS
Original: example.com → 203.0.113.50 (TTL: 300s)
Time: 10:00 - DNS updated to 203.0.113.51
Client queries at 10:02
→ Still cached: 203.0.113.50 (expires 10:05)
Client queries at 10:06
→ Cache expired, new lookup: 203.0.113.51
→ Cached until 10:11
Strategia TTL e memorizzazione nella cache
Scegliere i valori TTL
| Utilizzare il caso | TTL consigliato | Ragione |
|---|---|---|
| Infrastrutture statiche | 3600-86400s (1-24 ore) | Raramente cambia, riduce il carico DNS |
| Sito web di produzione | 300-1800 (5-30 minuti) | Equilibrio performance e flessibilità |
| Migrazione attiva | 60-300 (1-5 minuti) | Più veloce propagazione durante i cambiamenti |
| Bilanciamento del carico | 60-120 | failover rapido quando i server cambiano |
Riduzione del TTL prima della migrazione
La migliore pratica quando la pianificazione cambia DNS:
Day -7: example.com TTL 3600s (1 hour)
Day -2: Reduce to 300s (5 minutes)
Day 0: Make DNS change
→ Max 5 minute cache retention
Day +1: Restore TTL to 3600s
Avvelenamento della cache e sicurezza
Attacco di avvelenamento da cache DNS
Gli aggressori tentano di iniettare falsi record DNS in cache:
1. Attaccatore inondazioni risolutore con risposte false
2. Se uno corrisponde a una domanda in sospeso, è memorizzato
3. Gli utenti ricevono IP dannoso per il dominio legittimo
4. Tossico di ceppo servito a molti utenti
Mitigazioni di sicurezza
NSSEC I documenti firmati crittograficamente impediscono l'avvelenamentoexample.com. IN A 203.0.113.50
IN RRSIG A 8 2 300 ...
Source Port Randomization: Rende le risposte più difficili da falsificare
0x20 Encoding: Caso casuale nelle domande aiuta la validazione
Resolver Security: Utilizzare risolutori rispettabili (Cloudflare, Google, Quad9)
Controllo della cache DNS
Visualizzare i contenuti della cache
Windowsipconfig /displaydns | more
macOS (informazioni limitate):
sudo killall -INFO mDNSResponder
# Check Console.app for logs
Linux (risolto sistemato):
sudo systemd-resolve --statistics
Testare il comportamento della cache
# First query (cache miss)
time dig example.com
# Immediate repeat (cache hit)
time dig example.com
# Compare times
Problemi legati alla cache
Cache obsoleta dopo una modifica DNS
Problem: Aggiornati record DNS non riflettenti per gli utenti Soluzione:1. Attendere che TTL scada
2. Ridurre TTL prima dei cambiamenti futuri
3. Chiedi agli utenti di scaricare la cache locale
Memorizzazione nella cache eccessivamente aggressiva
Alcuni ISP ignorano TTL e la cache più a lungo:
Problem: I cambiamenti richiedono ore / giorni per propagare Soluzione:- Utilizzare TTL più bassi (gli ISP di solito rispettano il minimo di 300s)
- Considerare qualsiasi DNS cast per servizi critici
- Documento noto ISP problematici
Memorizzazione nella cache negativa
Le ricerche fallite (NXDOMAIN) sono anche memorizzate nella cache:
Query: newsubdomain.example.com
Response: NXDOMAIN (does not exist)
Cached: 3600s (SOA minimum TTL)
Result: New subdomain won't resolve for 1 hour
Soluzione: Abbassare il TTL minimo SOA prima di aggiungere nuovi record
Svuotare la cache DNS
Quando svuotare la cache
- Testare le modifiche DNS immediatamente
- Risoluzione dei problemi
- Dopo la migrazione dei provider DNS
- Tossicazione della cache sospetta
Come svuotare la cache
Windowsipconfig /flushdns
- Cosa?
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux (risolto sistemato):
sudo systemd-resolve --flush-caches
♪Chrome ♪
Navigate to: chrome://net-internals/#dns
Click: "Clear host cache"
♪Firefox ♪
Toggle network.dnsCacheExpiration in about:config
Or restart browser
Buone pratiche
1.
Set appropriate TTLs: Prestazioni di equilibrio e velocità di cambiamento2.
Ridurre TTL prima delle modifiche Più basso TTL 24-48 ore prima degli aggiornamenti DNS3.
Monitor propagation Utilizzare strumenti per controllare la risoluzione DNS globale4.
Comportamento della cache del documento Capire gli strati di caching dell'infrastruttura5.
Utilizzare DNSSEC: Proteggere dall'avvelenamento della cache6.
Test accuratamente Verificare che le modifiche DNS funzionino come previsto prima di dichiarare il successo7.
Educare gli utenti**: Fornire istruzioni chiare per il lavaggio della cache quando necessarioConcetti avanzati di memorizzazione nella cache
Precaricamento
I browser e i risolutori possono prefetch DNS per i collegamenti su una pagina:
<!-- Hint to browser -->
<link rel="dns-prefetch" href="//cdn.example.com">
Riscaldamento della cache
I bilanciatori di carico e i CDN possono pre-popolare le cache per i record critici.
Anycast e memorizzazione nella cache
Anycast DNS indirizza le richieste al server più vicino, creando cache distribuite geograficamente per prestazioni ottimali.
La cache DNS è fondamentale per le prestazioni di Internet, indipendentemente e configurando correttamente i TTL garantisce che le modifiche DNS si propagano in modo efficiente mantenendo tempi di risoluzione rapidi.