Il processo completo di risoluzione DNS: quanti passaggi dal browser ai server root?

1. Il flusso completo in 8 passaggi

┌─────────────────────────────────────────────────────────────┐
│  Browser (Chrome / Firefox): digiti google.com              │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Cache DNS del browser (Chrome ~60s)
                 ↓ miss
┌─────────────────────────────────────────────────────────────┐
│  Stub resolver del sistema operativo + cache DNS di sistema │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Miss nella cache di sistema → query UDP inviata al router
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Inoltro DNS del router di casa + cache del router          │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Miss nella cache del router → inoltro al resolver ricorsivo dell'ISP
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Resolver ricorsivo ISP o pubblico (1.1.1.1 / 8.8.8.8 / 223.5.5.5) │
│  Cache hit: risposta immediata, in tutto 1-5ms              │
│  Cache miss: si passa alla «ricerca completa» qui sotto     │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Chiede al NS root «dov'è google.com?»
                 ↓
        13 cluster di server root (a~m.root-servers.net)
                 │ ⑤ Risponde «Non lo so, chiedi all'NS di .com: a.gtld-servers.net»
                 ↓
        Server autoritativi del TLD .com (Verisign)
                 │ ⑥ Risponde «Non ho tutto nemmeno io, chiedi all'NS di google.com: ns1.google.com»
                 ↓
        Server autoritativi di google.com (gestiti da Google stessa)
                 │ ⑦ Risponde «record A di google.com = 142.250.x.x»
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ Il resolver ricorsivo mette in cache la risposta (secondo │
│     il TTL) e la restituisce al client; anche ogni livello  │
│     lungo il percorso ne conserva una copia                 │
└─────────────────────────────────────────────────────────────┘

Osservazione chiave: nella pratica il flusso completo in 8 passaggi non avviene quasi mai. Gli indirizzi IP dei siti principali sono quasi sempre già nella cache del resolver ricorsivo, quindi per l'utente comune la risposta arriva al passaggio ④. Solo domini poco noti, siti visitati di rado, TTL scaduti o domini appena registrati attivano il flusso completo.

2. I 5 livelli di cache DNS spiegati

Quando il DNS fu progettato, nel 1983, teneva già conto di un fatto: le ricerche superano le modifiche di un fattore 100.000. Per questo la cache è ovunque e ogni livello conserva i dati per la durata del TTL (Time To Live).

3. Query ricorsive vs iterative: i concetti chiave

3.1 Ricorsiva

Il client (browser / stub del sistema operativo) dice al resolver ricorsivo dell'ISP: «Trovami l'IP di google.com, non mi interessa come.» Il resolver ricorsivo deve completare l'intera ricerca e restituire il risultato finale.

3.2 Iterativa

Quando il resolver ricorsivo dialoga con i server root, TLD e autoritativi, lo scambio è iterativo: chiede alla root, la root risponde «chiedi a .com», va a chiedere a .com, .com risponde «chiedi a google», va a chiedere a google. Ogni passaggio attraversa un solo livello: non funziona come «chiedo alla root e la root fa tutto al posto mio».

4. Provalo tu stesso: dig +trace

dig +trace forza una ricerca iterativa completa e mostra ogni passaggio:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Hop 1: query alla root (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 record NS della root)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Hop 2: query al TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (i 4 NS di .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Hop 3: query ai server autoritativi di cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Finalmente arriva la risposta
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Analisi:

• L'intero processo ha richiesto 5 + 121 + 53 + 12 = 191 ms: la prima ricerca a freddo è davvero lenta
• Ma interrogare lo stesso dominio un secondo dopo richiede solo 1-2 ms, perché la cache ricorsiva dell'ISP lo contiene già (TTL di 300 secondi)
• 104.21.x.x / 172.67.x.x sono indirizzi della CDN di Cloudflare: il vero IP di origine del nostro sito è nascosto dietro la CDN

5. Il TTL spiegato: quanto dura davvero la cache

Il TTL (Time To Live) è il campo con cui il server autoritativo dice a ogni resolver ricorsivo «puoi tenerlo in cache al massimo per questo tempo», espresso in secondi.

Nota: il TTL è il «tempo di cache massimo»: i singoli resolver possono svuotare la cache prima, ma non possono mai prolungarla. Quindi, anche se il TTL autoritativo è di 1 ora, alcuni resolver potrebbero ripetere la query già dopo 10 minuti.

Attenzione: prima di cambiare IP, riduci il TTL (1-5 minuti) e attendi che il vecchio TTL sia scaduto del tutto prima di passare al nuovo; altrimenti alcuni utenti continueranno a raggiungere il vecchio IP per oltre un'ora.

6. Promemoria dei tipi di record DNS

7. Ottimizzazione DNS: come velocizzare la risoluzione

7.1 Scegli un resolver ricorsivo vicino

Cina continentale: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) risolvono più rapidamente i siti cinesi. Altrove: 1.1.1.1 (Cloudflare, la presenza anycast più estesa) / 8.8.8.8 (Google). Vedi ladirectory dei resolver DNS pubblici.

7.2 Attiva DoH (DNS-over-HTTPS)

Cifrare le query DNS tramite HTTPS impedisce agli ISP di vederle o manometterle (bloccando il dirottamento NXDOMAIN). Chrome, Firefox ed Edge lo supportano tutti: basta attivarlo nelle impostazioni.

7.3 Risoluzione anticipata (DNS Prefetch)

Aggiungi <link rel="dns-prefetch" href="//api.example.com"> nel <head> del tuo sito: il browser risolverà il dominio nei momenti di inattività e, quando arriverà la richiesta vera, troverà già la risposta in cache.

7.4 Usa una CDN + NS anycast

Metti i tuoi NS autoritativi su anycast (Cloudflare / Route 53), così gli utenti di tutto il mondo raggiungono l'istanza più vicina e la latenza del passaggio ③ scende da 100ms a 10ms.

7.5 Imposta il TTL con criterio

Imposta un TTL lungo (1-7 giorni) per i record che cambiano raramente (NS / MX) e un TTL breve (5-60 minuti) per i record A che potrebbero dover cambiare.

8. Domande frequenti

8.1 Ho cambiato il DNS ma non è successo niente: perché?

Per prima cosa, considera il TTL attuale. Dopo la modifica del DNS, ogni resolver ricorsivo continuerà a restituire il vecchio IP finché il vecchio TTL non sarà scaduto. La «propagazione globale» richiede in genere circa 2× il TTL (perché i resolver non sono sincronizzati tra loro).

• Client: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Per la cache dei resolver ricorsivi pubblici bisogna attendere la scadenza: 1.1.1.1 e 8.8.8.8 offrono ciascuno uno strumento di «purge» per svuotarla a mano

8.2 Alcuni utenti accedono, altri no: inquinamento DNS

Succede spesso quando si accede a siti esteri dalla Cina continentale: il GFW inietta risposte DNS false / gli ISP dirottano le query. Passare a DoH (DNS cifrato nel browser) permette di aggirare gran parte dell'inquinamento DNS.

8.3 Dopo quanto tempo posso usare un dominio appena registrato?

Dopo la registrazione, il registro del TLD pubblica i tuoi record NS sui server autoritativi di primo livello di .com / .net e così via: di solito servono da 15 minuti a 24 ore. I domini .cn / .com.cn possono richiedere la registrazione ICP prima di essere risolti nella Cina continentale.