Il DNS (Domain Name System) è uno dei pilastri invisibili di Internet. Senza di lui, ogni sito web, servizio, API o applicazione sarebbe raggiungibile solo conoscendone l’indirizzo IP. Il suo compito è semplice: tradurre nomi di dominio leggibili in indirizzi IP.

🌐 Perché il DNS è fondamentale

Senza DNS, Internet funzionerebbe solo a indirizzi numerici. È il sistema che rende la rete utilizzabile dagli esseri umani: ricordiamo rfnode.net, non una sequenza di numeri.

Cos’è il DNS, davvero

Il DNS è un enorme database distribuito. Un dispositivo manda una domanda (query), come “qual è l’indirizzo di rfnode.net?”, e riceve una risposta fatta di uno o più record: un indirizzo IP o altre informazioni sul dominio, per esempio dove consegnare la posta. Nessun server conosce tutto: ogni parte del database è gestita da chi possiede quel dominio, e il sistema collega i pezzi.

Il protocollo usa di norma la porta UDP 53, perché le richieste sono piccole e veloci. Passa a TCP 53 quando la risposta è troppo grande per un singolo pacchetto UDP (anche con DNSSEC, che aggiunge firme) e per i trasferimenti di zona tra server.

📖 Glossario rapido

  • Resolver ricorsivo: il server a cui il tuo dispositivo chiede la risposta. Fa il giro dei server al posto tuo e ricorda i risultati.
  • Nameserver autoritativo: il server che conosce davvero i record di un dominio e dà la risposta definitiva.
  • Zona: la parte di spazio dei nomi gestita da un certo soggetto, con tutti i suoi record.
  • Record: una singola informazione del DNS (indirizzo, alias, server di posta…).
  • TTL: il tempo, in secondi, per cui una risposta può essere conservata in cache.

La struttura gerarchica del DNS

I nomi di dominio si leggono da destra a sinistra, dal livello più generale a quello più specifico. Nell’indirizzo www.rfnode.net. il punto finale, di solito omesso, rappresenta la radice.

🌳 La gerarchia del DNS in un colpo d’occhio

  • Root (.) – livello più alto
  • TLD – .com, .net, .it, .org…
  • Dominio – esempio: rfnode.net
  • Sottodomini – www.rfnode.net, mail.rfnode.net

Ogni livello conosce solo chi gestisce il livello sotto di lui: questo meccanismo si chiama delega. La radice non sa l’indirizzo di rfnode.net, ma sa chi gestisce .net; a sua volta il TLD sa quali server gestiscono rfnode.net. I server radice sono identificati da 13 indirizzi logici (dalla lettera A alla M), replicati in centinaia di sedi nel mondo con una tecnica chiamata anycast, così che rispondano rapidamente e reggano anche in caso di attacco.

Come avviene una risoluzione DNS

1. Le cache locali

Prima di fare qualsiasi richiesta, il browser e il sistema operativo controllano se conoscono già la risposta (nella loro cache o nel file hosts, una piccola rubrica locale). Se la trovano, il giro finisce qui.

2. Il sistema operativo interroga il resolver

“Qual è l’IP di rfnode.net?” Il dispositivo manda la domanda a un resolver ricorsivo, che può essere:

  • il DNS del router;
  • il DNS dell’ISP;
  • un DNS pubblico (Cloudflare, Google, Quad9…).

Anche il resolver ha una cache: se ha già la risposta, la restituisce subito.

3. Le query iterative

Se la risposta non è in cache, è il resolver (non il browser) a interrogare i server uno dopo l’altro:

  • root server: “non so dov’è rfnode.net, ma ecco chi gestisce .net”;
  • server del TLD (.net): “non so l’indirizzo, ma ecco i nameserver di rfnode.net”;
  • nameserver autoritativi: “ecco il record che cerchi”.

4. Risposta del nameserver

Il nameserver restituisce i record richiesti. I tipi più comuni sono questi:

Record A cosa serve Esempio
A Indirizzo IPv4 example.com. 300 IN A 192.0.2.10
AAAA Indirizzo IPv6 example.com. 300 IN AAAA 2001:db8::10
CNAME Alias: un nome che punta a un altro nome www.example.com. IN CNAME example.com.
MX Server che ricevono la posta del dominio, con priorità example.com. IN MX 10 mail.example.com.
TXT Testo libero: usato per SPF, DKIM, DMARC e verifiche di proprietà example.com. IN TXT "v=spf1 …"
NS Nameserver che gestiscono la zona example.com. IN NS ns1.example.com.
PTR DNS inverso: da un IP a un nome. Importante per i server di posta 10.2.0.192.in-addr.arpa. IN PTR mail.example.com.
CAA Indica quali autorità possono emettere certificati HTTPS per il dominio example.com. IN CAA 0 issue "letsencrypt.org"

5. Cache

La risposta viene memorizzata dal resolver per il tempo definito dal TTL. Un TTL di 300 secondi vuol dire che per cinque minuti il resolver risponde senza interrogare nessuno. È ciò che rende il DNS veloce, ma anche il motivo per cui una modifica a un record non è visibile a tutti subito: bisogna aspettare che scadano le cache.

6. Connessione

Il browser si collega all’IP ottenuto e inizia la connessione vera e propria con il sito.

⚡ Happy Eyeballs (RFC 8305)

Quando un sito ha sia IPv6 sia IPv4, i sistemi moderni provano prima IPv6. Se non c’è risposta in pochi millisecondi, tentano in parallelo anche IPv4 e usano la connessione che si stabilisce per prima. Così un problema su un protocollo non rallenta la navigazione.

IPv4 e IPv6

IPv4

142.250.184.206

Quattro numeri da 0 a 255 separati da punti. Spazio: circa 4,3 miliardi di indirizzi, ormai esauriti.

IPv6

2a00:1450:4002:80b::200e

Otto gruppi esadecimali separati da due punti; una serie di gruppi di zeri consecutivi si abbrevia con ::. Spazio: circa 3,4 × 1038 indirizzi (340 sestilioni), abbastanza da dare un indirizzo a ogni dispositivo.

🔍 IPv4 vs IPv6

  • IPv4: pochi indirizzi, quindi spesso si usa il NAT, che fa condividere un solo indirizzo pubblico a molti dispositivi.
  • IPv6: indirizzi abbondanti, NAT non necessario, intestazione dei pacchetti più semplice e indirizzi aggregabili in modo più efficiente.
  • IPv6 supporta IPsec e l’autoconfigurazione (SLAAC), ma l’uso di IPsec non è obbligatorio.
  • I due protocolli convivono: molte reti funzionano con entrambi (dual stack).

Strumenti avanzati: dig, nslookup, host

Sono tre programmi da riga di comando per interrogare il DNS e capire cosa risponde davvero.

dig

Il più completo. Mostra la risposta, i TTL e i dettagli della query.

dig rfnode.net A
dig rfnode.net AAAA
dig rfnode.net MX +short

Per interrogare un resolver preciso, per esempio quello di Cloudflare, e per scoprire il nome associato a un IP (DNS inverso):

dig @1.1.1.1 rfnode.net
dig -x 192.0.2.10

L’opzione +trace mostra il percorso completo, dalla radice ai nameserver autoritativi, come se fosse il resolver a farlo:

dig +trace rfnode.net

Nell’output cerca la sezione ANSWER SECTION: contiene i record, con il TTL rimasto e il tipo.

nslookup

Più semplice e presente su quasi tutti i sistemi, Windows compreso.

nslookup rfnode.net

host

Rapido e con un output leggibile. Per tipi di record specifici si usa -t.

host rfnode.net
host -t MX rfnode.net

🛠️ Quando usare cosa

  • dig → completo, professionale, ideale per diagnosticare problemi
  • nslookup → semplice e universale
  • host → rapido e minimale

💡 Tip per chi legge da Windows

Su Windows i comandi come dig o host restituiscono l’errore “Termine non riconosciuto” (o la sovrapposizione con Get-Host) perché il sistema include nativamente solo nslookup.
Se vuoi eseguire query avanzate come dig +trace senza software terzi, il modo migliore è abilitare Linux su Windows: apri PowerShell e lancia wsl --install -d Ubuntu. Una volta installato, ti basterà digitare wsl in qualsiasi terminale per passare all’ambiente Linux ed eseguire tutti i comandi della guida, oppure connetterti alla tua VPS via SSH!

DNS e sicurezza

Il DNS nasce negli anni ’80, quando la sicurezza non era una priorità: le risposte non venivano autenticate. Da qui derivano molti attacchi.

DNS Spoofing / Cache Poisoning

Un attaccante riesce a far accettare a un resolver una risposta falsa, che resta in cache e reindirizza gli utenti verso un IP malevolo. Il caso più noto è la falla scoperta da Dan Kaminsky nel 2008, che rendeva l’attacco molto più rapido. Difese: resolver aggiornati, porte e identificativi casuali nelle query, DNSSEC.

Hijacking del dominio

L’attaccante prende il controllo del dominio dal lato del registrar o del pannello DNS (per esempio con una password rubata) e cambia i record o i nameserver. Difese: 2FA, password uniche, blocco del trasferimento del dominio e controllo regolare delle impostazioni.

MITM sul DNS

Chi si trova sul percorso tra te e il resolver (una rete Wi-Fi aperta, per esempio) può leggere o modificare le richieste DNS non cifrate. Difese: DoH o DoT per proteggere il tratto fino al resolver, e DNSSEC per verificare che la risposta sia autentica.

🚨 Minacce reali

  • Spoofing → risposte falsificate
  • Hijacking → dominio sotto controllo dell’attaccante
  • MITM → manipolazione del traffico DNS
  • Filtri ISP → blocchi o reindirizzamenti decisi dal provider o imposti dalla legge

Best practice

Per chi gestisce un dominio

DNSSEC

Aggiunge firme crittografiche ai record, così un resolver può verificare che la risposta arrivi dal vero proprietario e non sia stata alterata. Attenzione: DNSSEC autentica, non cifra. Si attiva dal pannello del registrar o del provider DNS.

TTL ragionati

  • record che cambiano spesso o che richiedono un cambio rapido (failover) → TTL bassi;
  • record stabili → TTL alti, che riducono il carico e rendono il servizio meno dipendente dai nameserver;
  • prima di una migrazione, abbassa il TTL con qualche giorno di anticipo e rialzalo dopo.

Nameserver ridondanti

Usa almeno 2–3 nameserver, meglio se su reti e sedi diverse, così un guasto non rende il dominio irraggiungibile.

Autenticazione forte

  • 2FA sul registrar e sul pannello DNS;
  • password lunghe e uniche;
  • registrar lock (blocco del trasferimento) attivo;
  • registrar affidabili e rinnovo automatico, per non perdere il dominio per una scadenza.

Record di protezione

Imposta un CAA per limitare chi può emettere certificati per il dominio, e i record SPF, DKIM e DMARC se gestisci la posta. Per un server di posta configura anche un PTR coerente con il suo nome.

Per chi usa un resolver

DoH / DoT

DNS over HTTPS e DNS over TLS cifrano il traffico DNS, ma solo tra il tuo dispositivo e il resolver: nessuno sulla rete locale può leggerlo, però il resolver continua a vedere quali domini cerchi. Scegli quindi un resolver di cui ti fidi.

Resolver che validano DNSSEC

Molti resolver pubblici, come Cloudflare, Google e Quad9, controllano le firme DNSSEC e scartano le risposte alterate.

🧩 Le regole d’oro

  • Attiva DNSSEC sul tuo dominio
  • Usa DoH/DoT con un resolver affidabile
  • TTL coerenti con quanto cambiano i record
  • Almeno 2–3 nameserver ridondanti
  • 2FA e registrar lock sul dominio
  • Monitoraggio continuo e controllo delle scadenze

Conclusione

Il DNS è molto più di una “rubrica di Internet”: è un sistema complesso, distribuito e vitale. Capirlo significa capire come funziona Internet, e saperlo interrogare con gli strumenti giusti permette di risolvere in pochi minuti molti problemi di rete.