Cache DNS

Protocolli e Standard
Archiviazione temporanea dei risultati delle query DNS da parte di risolutori o client per velocizzare le ricerche ripetute.
← Torna al Glossario

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:

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 sistema

Tipica 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:

RisolvereStrategia di Cache
Google (8.8.8.8)Rispetta TTL, cache globale
Cloudflare (1.1.1.1)Rispetti TTL, distribuiti
ISP ResolversPuò 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 casoTTL consigliatoRagione
Infrastrutture statiche3600-86400s (1-24 ore)Raramente cambia, riduce il carico DNS
Sito web di produzione300-1800 (5-30 minuti)Equilibrio performance e flessibilità
Migrazione attiva60-300 (1-5 minuti)Più veloce propagazione durante i cambiamenti
Bilanciamento del carico60-120failover 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'avvelenamento
example.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

Windows
ipconfig /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

Windows
ipconfig /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 cambiamento

2. Ridurre TTL prima delle modifiche Più basso TTL 24-48 ore prima degli aggiornamenti DNS

3. Monitor propagation Utilizzare strumenti per controllare la risoluzione DNS globale

4. Comportamento della cache del documento Capire gli strati di caching dell'infrastruttura

5. Utilizzare DNSSEC: Proteggere dall'avvelenamento della cache

6. Test accuratamente Verificare che le modifiche DNS funzionino come previsto prima di dichiarare il successo

7. Educare gli utenti**: Fornire istruzioni chiare per il lavaggio della cache quando necessario

Concetti 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.

Metti in Pratica Questa Conoscenza

Usa l'API di DomScan per verificare disponibilità, salute del dominio e altro.