Cos'è DNS Cache?
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é DNS Caching Matters
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 il cache DNS
La Gerarchia di Caching
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 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 su 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
Browser Cache
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
Risolvere la Cache
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 |
Cache Behavior Esempi
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
TTL Strategia e Caching
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 |
Pre-Migrazione TTL Riduzione
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
Cache avvelenamento 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
Visualizza i contenuti di Cache
Windowsipconfig /displaydns | more
macOS (informazioni limitate):
sudo killall -INFO mDNSResponder
# Check Console.app for logs
Linux (risolto sistemato):
sudo systemd-resolve --statistics
Test Cache Behavior
# First query (cache miss)
time dig example.com
# Immediate repeat (cache hit)
time dig example.com
# Compare times
Articoli correlati
Stale Cache Dopo il cambiamento DNS
Problem: Aggiornati record DNS non riflettenti per gli utenti# Solution #
1. Attendere che TTL scada
2. Ridurre TTL prima dei cambiamenti futuri
3. Chiedi agli utenti di scaricare la cache locale
Caching eccessivamente aggressivo
Alcuni ISP ignorano TTL e la cache più a lungo:
Problem: I cambiamenti richiedono ore / giorni per propagare# Solution #
- Utilizzare TTL più bassi (gli ISP di solito rispettano il minimo di 300s)
- Considerare qualsiasi DNS cast per servizi critici
- Documento noto ISP problematici
Caching negativo
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
# Solution # Abbassare il TTL minimo SOA prima di aggiungere nuovi record
Flushing DNS Cache
Quando a Flush
- Testare le modifiche DNS immediatamente
- Risoluzione dei problemi
- Dopo la migrazione dei provider DNS
- Tossicazione della cache sospetta
Come Preparare il Tempo
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
Migliori 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 di Caching avanzati
Prefetching
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">
Cache Warming
I bilanciatori di carico e i CDN possono pre-popolare le cache per i record critici.
Anycast e Caching
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.