Il DNS (Domain Name System) è il protocollo che traduce i nomi di dominio leggibili — come www.evemilano.com — in indirizzi IP numerici utilizzati dai server per instradare il traffico. Senza DNS, ogni connessione richiederebbe la memorizzazione di sequenze numeriche come 192.0.2.44 o 2606:4700::6810:84e5.

Definito nelle RFC 1034 e RFC 1035 (Paul Mockapetris, 1987), il DNS è un sistema di denominazione gerarchico e decentralizzato che costituisce uno dei pilastri fondamentali dell’infrastruttura Internet. Ogni volta che un browser, un client email o un’applicazione API effettua una richiesta, una query DNS viene risolta prima che venga stabilita qualsiasi connessione TCP o UDP.

Questa guida copre il funzionamento tecnico del DNS, i tipi di record, il ruolo di cache e TTL, i protocolli crittografati (DNSSEC, DoH, DoT, DoQ) e un confronto aggiornato dei resolver pubblici.

Come funziona la risoluzione DNS

Quando un utente digita un URL nel browser, il sistema operativo avvia una catena di query DNS che coinvolge fino a quattro tipi di server diversi. Il processo è progettato per essere gerarchico: ogni livello conosce solo il passo successivo, non la risposta finale.

I 4 server coinvolti nella risoluzione

DNS Resolver (Recursore) — Il primo punto di contatto, tipicamente gestito dall’ISP o da un resolver pubblico (Cloudflare, Google). Riceve la query dal client e si occupa di interrogare gli altri server nella catena fino a ottenere la risposta definitiva. Il resolver mantiene una cache locale per evitare query ridondanti.
Root Nameserver — Esistono 13 cluster di root server (da A a M), distribuiti globalmente tramite anycast. Non contengono i record dei singoli domini, ma indirizzano il resolver verso il TLD nameserver corretto (.com, .it, .org, ecc.).
TLD Nameserver — Gestisce i domini di primo livello. Il TLD server per .com conosce quali authoritative nameserver sono responsabili per ogni dominio registrato sotto .com. Restituisce al resolver l’indirizzo del nameserver autoritativo.
Authoritative Nameserver — L’ultima tappa nella catena. Contiene i record DNS effettivi del dominio (A, AAAA, MX, CNAME, ecc.) e restituisce la risposta definitiva al resolver.

Il flusso completo passo per passo

Ecco cosa succede quando il browser richiede www.evemilano.com:

Il browser controlla la propria cache DNS interna
Se non trova corrispondenza, interroga il resolver DNS del sistema operativo
Il resolver verifica la propria cache; se il record è scaduto (TTL esaurito), avvia una query ricorsiva
Il resolver contatta un root nameserver, che risponde con l’indirizzo del TLD server per .com
Il resolver interroga il TLD server .com, che risponde con il nameserver autoritativo per evemilano.com
Il resolver interroga il nameserver autoritativo, che restituisce il record A con l’indirizzo IP
Il resolver memorizza la risposta in cache (rispettando il TTL) e la restituisce al browser
Il browser stabilisce la connessione TCP/TLS con l’indirizzo IP ottenuto

L’intero processo richiede tipicamente 20-120 ms per una query non in cache. Con la cache attiva, la risoluzione è pressoché istantanea (< 1 ms).

Tipi di record DNS

I record DNS sono le istruzioni memorizzate sui nameserver autoritativi. Ogni tipo di record ha una funzione specifica e una sintassi precisa. Questi sono i record che un professionista web deve conoscere e saper configurare.

Record principali

Record	Funzione	Esempio
A	Mappa un dominio a un indirizzo IPv4	`evemilano.com → 104.26.10.78`
AAAA	Mappa un dominio a un indirizzo IPv6	`evemilano.com → 2606:4700:20::681a:a4e`
CNAME	Alias: punta un dominio a un altro dominio (non a un IP)	`www.evemilano.com → evemilano.com`
MX	Indica il mail server per il dominio, con priorità numerica	`evemilano.com → 10 mail.example.com`
NS	Definisce i nameserver autoritativi per la zona DNS	`evemilano.com → ns1.cloudflare.com`
TXT	Testo arbitrario: usato per SPF, DKIM, DMARC, verifica proprietà	`"v=spf1 include:_spf.google.com ~all"`

Record avanzati

Record	Funzione	Caso d’uso
SOA	Start of Authority: metadati della zona (primary NS, email admin, serial, refresh, retry, expire, minimum TTL)	Ogni zona DNS ha esattamente un record SOA. Contiene il serial number che i secondary DNS usano per verificare se la zona è stata aggiornata.
SRV	Service record: specifica host e porta per un servizio	Usato da SIP, XMPP, LDAP. Formato: `_service._proto.name TTL IN SRV priority weight port target`
CAA	Certificate Authority Authorization: limita quali CA possono emettere certificati SSL/TLS per il dominio	`evemilano.com. CAA 0 issue "letsencrypt.org"` — solo Let’s Encrypt può emettere certificati
PTR	Pointer record: risoluzione inversa da IP a dominio	Usato nella verifica reverse DNS per mail server. Un mail server senza PTR corretto viene spesso rifiutato come spam.

Nota: I record TXT sono diventati critici per la sicurezza email. SPF (Sender Policy Framework) definisce quali server possono inviare email per conto del dominio. DKIM firma crittograficamente i messaggi. DMARC istruisce i mail server riceventi su come gestire messaggi che falliscono le verifiche SPF/DKIM. Senza questi tre record correttamente configurati, le email rischiano di finire in spam.

DNS cache e TTL

Il TTL (Time To Live) è un valore in secondi che indica per quanto tempo un record DNS può essere memorizzato in cache prima che il resolver debba interrogare nuovamente il nameserver autoritativo. Il TTL è un meccanismo fondamentale per bilanciare performance e aggiornabilità.

Come funziona la cache DNS

La cache DNS opera su più livelli:

Browser — Chrome, Firefox e altri browser mantengono una cache DNS interna (tipicamente 60 secondi). In Chrome si può ispezionare con chrome://net-internals/#dns
Sistema operativo — Windows (servizio DNS Client), macOS e Linux mantengono una cache di sistema. Su Windows si svuota con ipconfig /flushdns, su macOS con sudo dscacheutil -flushcache
Resolver ISP/pubblico — Il resolver ricorsivo (es. Cloudflare 1.1.1.1) conserva i record fino alla scadenza del TTL

Valori TTL consigliati

Scenario	TTL consigliato	Note
Record statici (A, MX, NS)	3600–86400 s (1–24 ore)	Riduce il carico sui nameserver e velocizza la navigazione
Pre-migrazione DNS	60–300 s	Abbassare il TTL 24-48 ore prima della modifica per accelerare la propagazione
DNS dinamico / failover	30–60 s	TTL basso per consentire failover rapido, ma aumenta il traffico DNS
Record CDN (Cloudflare, ecc.)	Auto / 300 s	I CDN spesso gestiscono il TTL automaticamente con valori ottimizzati

Propagazione DNS

La “propagazione DNS” indica il tempo necessario affinché una modifica ai record DNS venga recepita da tutti i resolver a livello globale. Non si tratta di un vero processo di propagazione attivo: i resolver semplicemente continuano a servire il record in cache fino alla scadenza del TTL, dopodiché richiedono la versione aggiornata.

In condizioni normali, con TTL di 3600 secondi (1 ora), la propagazione completa richiede 1-4 ore. Con TTL alti (86400 s) può servire fino a 24-48 ore, perché alcuni ISP potrebbero non rispettare esattamente il TTL indicato e mantenere i record in cache più a lungo.

Nota: Prima di una migrazione DNS (cambio hosting, cambio nameserver), la best practice è abbassare il TTL a 60-300 secondi almeno 24 ore prima della modifica effettiva. In questo modo, al momento del cambio, i resolver avranno in cache un record con TTL breve e aggiorneranno rapidamente.

DNS sicuro: DNSSEC, DoH, DoT e DoQ

Il DNS tradizionale trasmette le query in chiaro su UDP porta 53, senza alcuna autenticazione o crittografia. Questo lo rende vulnerabile a spoofing, cache poisoning e intercettazione. Tre categorie di protocolli risolvono questi problemi.

DNSSEC (DNS Security Extensions)

DNSSEC aggiunge firme crittografiche ai record DNS. Non cifra le query — il contenuto resta visibile — ma garantisce che la risposta provenga effettivamente dal nameserver autoritativo e non sia stata alterata durante il transito (integrità + autenticità).

Il meccanismo funziona con una catena di trust: ogni zona DNS firma i propri record con una chiave privata (ZSK, Zone Signing Key), e la chiave pubblica è a sua volta firmata dalla zona padre tramite un record DS. La catena risale fino ai root nameserver.

DNSSEC protegge da attacchi di cache poisoning (es. Kaminsky attack) e spoofing DNS, ma non protegge la privacy delle query: un osservatore sulla rete può ancora vedere quali domini vengono richiesti.

DNS over TLS (DoT) — RFC 7858

DoT incapsula le query DNS in una connessione TLS sulla porta dedicata 853. La crittografia impedisce l’intercettazione delle query da parte dell’ISP o di altri osservatori sulla rete.

Il vantaggio di DoT è la separazione netta: opera su una porta dedicata, il che semplifica la gestione in ambito enterprise e il monitoring del traffico DNS. Lo svantaggio è che proprio questa porta dedicata rende il traffico DoT identificabile e potenzialmente bloccabile da firewall restrittivi.

DNS over HTTPS (DoH) — RFC 8484

DoH trasmette le query DNS all’interno di normali richieste HTTPS sulla porta 443. Questo rende il traffico DNS indistinguibile dal traffico web ordinario, impedendo sia l’intercettazione sia il blocco selettivo.

DoH è supportato nativamente da tutti i browser principali (Chrome, Firefox, Edge, Safari) e può essere attivato nelle impostazioni di rete. Firefox usa Cloudflare come resolver DoH predefinito; Chrome utilizza il resolver DoH del provider DNS configurato nel sistema, se disponibile.

DNS over QUIC (DoQ) — RFC 9250

DoQ utilizza il protocollo QUIC (la base di HTTP/3) come trasporto per le query DNS. Rispetto a DoT e DoH basati su TCP+TLS, QUIC offre handshake più rapidi (0-RTT nelle connessioni successive) e migliore resilienza alla perdita di pacchetti.

I benchmark mostrano che DoQ riduce la latenza delle query del 10% rispetto a DoH e si avvicina alle performance del DNS tradizionale su UDP, con solo il 2% di overhead aggiuntivo nonostante la crittografia completa. DoQ è supportato da resolver come AdGuard DNS e NextDNS, e l’adozione è in crescita.

Confronto protocolli DNS sicuri

Protocollo	Porta	Trasporto	Crittografia	Visibilità
DNS classico	53	UDP/TCP	Nessuna	Query e risposte visibili in chiaro
DNSSEC	53	UDP/TCP	Solo firma (no cifratura)	Query visibili, risposte autenticate
DoT	853	TCP + TLS	Completa	Traffico cifrato ma identificabile come DNS
DoH	443	HTTPS	Completa	Indistinguibile dal traffico web
DoQ	853 o 8853	QUIC	Completa	Cifrato, bassa latenza, handshake 0-RTT

L’approccio consigliato nel 2026 è combinare DNSSEC (per l’autenticità delle risposte) con DoH o DoQ (per la privacy delle query). In ambito enterprise, DoT resta valido per la gestibilità della porta dedicata.

Migliori server DNS pubblici

La scelta del resolver DNS impatta direttamente su velocità di navigazione, privacy e sicurezza. Questi sono i principali resolver pubblici, aggiornati al 2026.

Provider	IPv4	IPv6	DoH / DoT	Caratteristiche
Cloudflare	`1.1.1.1` / `1.0.0.1`	`2606:4700:4700::1111`	Entrambi	Il resolver più veloce nei benchmark (~10 ms globali). Nessun log degli IP dei client. DNSSEC validation di default.
Google Public DNS	`8.8.8.8` / `8.8.4.4`	`2001:4860:4860::8888`	Entrambi	La rete DNS più estesa al mondo. Log temporanei (24-48h). Supporto DNSSEC e EDNS Client Subnet per geolocalizzazione CDN.
Quad9	`9.9.9.9` / `149.112.112.112`	`2620:fe::fe`	Entrambi	No-profit svizzero (leggi privacy CH). Blocco automatico domini malevoli tramite threat intelligence. Zero logging.
NextDNS	Personalizzato	Personalizzato	DoH / DoT / DoQ	Resolver configurabile con filtri personalizzati, analytics, blocco ads/tracker. Free tier fino a 300k query/mese.
OpenDNS (Cisco)	`208.67.222.222`	—	DoH	Filtro contenuti configurabile (FamilyShield). Protezione phishing e malware integrata.

Per la maggior parte degli utenti e dei professionisti, Cloudflare 1.1.1.1 offre il miglior bilanciamento tra velocità e privacy. Quad9 aggiunge la protezione contro domini malevoli, utile in contesti aziendali. NextDNS è la scelta più flessibile per chi vuole controllo granulare su filtri e analytics.

Come cambiare i server DNS

Windows 10/11

Apri Impostazioni → Rete e Internet → Proprietà della connessione attiva
In “Assegnazione server DNS” clicca Modifica
Seleziona Manuale e attiva IPv4 (e IPv6 se necessario)
Inserisci il DNS preferito (es. 1.1.1.1) e alternativo (es. 1.0.0.1)
Windows 11 supporta nativamente DoH: nel menu a tendina “DNS over HTTPS” seleziona Attivato (solo crittografato)
Salva le impostazioni

Da command line, il comando equivalente è:

netsh interface ip set dns "Wi-Fi" static 1.1.1.1
netsh interface ip add dns "Wi-Fi" 1.0.0.1 index=2

macOS

Apri Impostazioni di Sistema → Rete
Seleziona la connessione attiva (Wi-Fi o Ethernet) e clicca Dettagli
Vai alla scheda DNS
Rimuovi i server esistenti e aggiungi quelli desiderati (es. 1.1.1.1, 1.0.0.1)
Clicca OK e poi Applica

Da terminale:

sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

Android e iOS

Android 9+ supporta nativamente DoT (DNS privato):

Vai in Impostazioni → Rete e Internet → DNS privato
Seleziona “Nome host del provider DNS privato”
Inserisci one.one.one.one (Cloudflare) o dns.google (Google)

iOS 14+ supporta DoH e DoT tramite profili di configurazione. Cloudflare e NextDNS offrono app dedicate che installano il profilo automaticamente, attivando DNS crittografato a livello di sistema.

Come verificare i record DNS

La diagnostica DNS è un’operazione frequente per chiunque gestisca siti web o infrastruttura. Questi sono i tool principali.

nslookup

Disponibile su Windows, macOS e Linux. Utile per query rapide:

nslookup -type=A evemilano.com
nslookup -type=MX evemilano.com
nslookup -type=TXT evemilano.com 1.1.1.1

Il terzo esempio interroga esplicitamente il resolver Cloudflare anziché quello predefinito del sistema.

dig

dig (Domain Information Groper) è lo strumento standard su Linux e macOS per l’analisi DNS avanzata. Su Windows è disponibile installando BIND o tramite WSL.

# Query A record con output dettagliato
dig evemilano.com A

# Query specifica a Cloudflare DNS con risposta breve
dig @1.1.1.1 evemilano.com A +short

# Trace completo della catena di risoluzione
dig evemilano.com +trace

# Verifica DNSSEC
dig evemilano.com +dnssec

Il flag +trace mostra ogni passaggio della risoluzione, dal root server fino all’autoritativo. Il flag +dnssec mostra i record RRSIG associati, utile per verificare che DNSSEC sia attivo e funzionante.

Tool online

Per verifiche rapide senza accesso al terminale, o per controllare la propagazione DNS da diverse località geografiche:

Google Admin Toolbox Dig — interfaccia web per query DNS di Google
whatsmydns.net — mostra la risoluzione DNS da 20+ località globali, utile per monitorare la propagazione
DNSChecker.org — verifica la propagazione per qualsiasi tipo di record
MXToolbox — diagnostica completa per record MX, SPF, DKIM, DMARC e blacklist

DNS e SEO: cosa sapere

Il DNS ha un impatto diretto sulla velocità di caricamento delle pagine e, indirettamente, sulla capacità di Googlebot di effettuare crawl efficienti.

Tempo di risoluzione DNS — Un resolver lento aggiunge latenza a ogni prima visita. La metrica TTFB (Time To First Byte) include il tempo di risoluzione DNS. Usare un resolver veloce e configurare TTL adeguati riduce questa componente.
DNS prefetch — Il tag <link rel="dns-prefetch" href="//cdn.example.com"> istruisce il browser a risolvere anticipatamente i domini di terze parti, riducendo la latenza per risorse esterne (CDN, analytics, font).
Disponibilità del sito — Nameserver inaffidabili causano downtime. Se il DNS non risolve, il sito è irraggiungibile sia per gli utenti che per i crawler. Usare almeno due nameserver su reti diverse (ridondanza).
Migrazione DNS e migrazione HTTPS — Durante un cambio di hosting o di CDN, una gestione errata del DNS può causare downtime prolungato e perdita temporanea di posizionamento. Abbassare il TTL prima della migrazione è fondamentale.
CDN e anycast DNS — Servizi come Cloudflare utilizzano reti DNS anycast distribuite globalmente, che riducono la latenza di risoluzione e aggiungono protezione DDoS a livello DNS.

Domande frequenti sul DNS

Qual è la differenza tra DNS ricorsivo e autoritativo?

Il DNS ricorsivo (resolver) è l’intermediario che riceve la query dal client e si occupa di attraversare la gerarchia DNS per trovare la risposta. Il DNS autoritativo è il server che detiene effettivamente i record di una zona e fornisce la risposta definitiva. Il resolver interroga l’autoritativo, non viceversa.

Quanto tempo serve per la propagazione DNS?

Dipende dal TTL precedente del record modificato. Con TTL di 3600 s (1 ora), la propagazione effettiva richiede 1-4 ore. Con TTL di 86400 s (24 ore), può servire fino a 48 ore. La best practice è abbassare il TTL 24 ore prima di qualsiasi modifica pianificata.

Cambiare DNS migliora la velocità di navigazione?

Sì, se il resolver attuale è lento. Passare dal resolver dell’ISP a Cloudflare (1.1.1.1) o Google (8.8.8.8) riduce tipicamente il tempo di risoluzione da 50-100 ms a 10-20 ms. L’impatto è percepibile soprattutto nella prima visita a un dominio (quando non c’è cache).

Come si abilita il DNS crittografato?

Su Windows 11, si attiva DoH direttamente dalle impostazioni di rete scegliendo un resolver compatibile (Cloudflare, Google, Quad9). Su Android 9+, il DNS privato (DoT) si configura in Impostazioni → Rete → DNS privato. Su iOS, si installano profili di configurazione forniti dai provider DNS. Nei browser, DoH si attiva nelle impostazioni di sicurezza/privacy.

Cos’è il DNS poisoning e come proteggersi?

Il DNS cache poisoning è un attacco in cui un malintenzionato inietta record DNS falsi nella cache di un resolver, reindirizzando il traffico verso server controllati dall’attaccante. La protezione principale è DNSSEC, che firma crittograficamente i record impedendo la manomissione. Usare resolver che validano DNSSEC (Cloudflare, Google, Quad9 lo fanno tutti di default) è la contromisura più efficace.

Quali record DNS servono per un sito web?

Come minimo: un record A (o AAAA per IPv6) che punta al server, un record CNAME per il sottodominio www, record NS per i nameserver autoritativi e record TXT per SPF/DKIM/DMARC se il dominio invia email. Un record CAA è consigliato per limitare l’emissione di certificati SSL. Per siti con email, i record MX sono obbligatori.

Il DNS è un’infrastruttura che spesso viene data per scontata fino a quando qualcosa non funziona. Una configurazione corretta dei record, la scelta di un resolver affidabile e l’adozione di protocolli crittografati non sono più opzionali: sono requisiti base per qualsiasi progetto web professionale. Per un approfondimento sulla struttura dei domini e sottodomini, consulta la guida dedicata. Per l’implementazione di HTTP header di sicurezza, inclusi quelli relativi al DNS prefetch, vedi la guida tecnica agli header HTTP.