Che cos'è il DNS? Come i nomi di dominio diventano indirizzi IP

Il DNS (Domain Name System) associa nomi come example.com ai dati che servono subito dopo a un client, il più delle volte un indirizzo IP. Le applicazioni chiedono un nome e il DNS restituisce dei record. Il DNS non è un web server, un browser o un livello di cifratura. Risponde a domande di lookup e basta.

#In breve

Quando digiti un nome in un browser, il sistema operativo o il browser controllano prima la propria cache. Se non c'è una risposta utilizzabile, il client invia una query a un resolver ricorsivo. Quel resolver è spesso gestito dal tuo provider internet, dal tuo datore di lavoro o da un servizio pubblico come 8.8.8.8.

Il resolver risponde dalla sua cache quando può. Altrimenti percorre la gerarchia del DNS. Chiede a un root server quali server gestiscono il dominio di primo livello (come .com), chiede a quel server quali nameserver usa il dominio, poi chiede il record a uno di quei nameserver autoritativi. Il server autoritativo contiene i dati reali. Il resolver conserva la risposta per il tempo consentito dal TTL del record, poi la restituisce al client.

Nel traffico reale i passaggi sono di più: catene di CNAME, validazione DNSSEC, voci in un file hosts locale, trasporti DNS cifrati e diversi livelli di cache. Finito il DNS, il browser deve ancora aprire una connessione, negoziare TLS e aspettare la risposta del server.

#I primi record che incontrerai

#Prova su un dominio che puoi documentare

Usa un dominio che possiedi o gestisci. Se vuoi solo esercitarti, example.com è uno dei nomi riservati alla documentazione (RFC 2606). Limitati ai nomi che puoi interrogare, ed evita di scansionare host che non hai il permesso di testare.

Su Linux o macOS, con dig installato:

dig example.com A
dig example.com AAAA
dig example.com MX

Su Windows, nslookup è incluso nel sistema operativo:

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

L'output qui sotto è stato catturato su una macchina Windows il 2026-11-08 con nslookup, usando il resolver predefinito della macchina (dns.google, 8.8.8.8). La risposta è arrivata da quel resolver, e non dal server autoritativo del dominio. La macchina stampava le etichette in portoghese. Qui sono riportate in inglese. I valori sono un'istantanea e saranno diversi sulla tua macchina e nelle esecuzioni successive.

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

Name:    example.com
Addresses:  2606:4700:10::ac42:93f3
	  2606:4700:10::6814:179a
	  172.66.147.243
	  104.20.23.154

Lo stesso resolver ha restituito un record MX per il dominio:

example.com	MX preference = 0, mail exchanger = (root)

Un mail exchanger (root) significa che la destinazione è un singolo punto. È un null MX, che dice ai mittenti che il dominio non accetta posta (RFC 7505).

Infine, una query TXT per lo stesso nome:

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

example.com	text =

	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com	text =

	"v=spf1 -all"

La seconda stringa è una policy SPF. -all dice che nessun server è autorizzato a inviare posta per questo dominio, e questo è coerente con il null MX visto sopra. La prima stringa è un valore opaco; stringhe come questa si usano di solito per dimostrare a un servizio di possedere un dominio. Come dice la tabella, un record TXT mostra cosa ha pubblicato il proprietario e non dimostra altro.

Due dettagli di questa esecuzione. La riga Non-authoritative answer conferma che la risposta è arrivata dalla cache o dalla ricerca di un resolver, e non dal server del dominio. E gli indirizzi IPv6 sono comparsi per primi, ma non devi fare affidamento sull'ordine: un'esecuzione successiva può elencarli diversamente o restituire indirizzi diversi.

Per osservare la cache, usa dig. Stampa un numero TTL prima di ogni record. Esegui la stessa query due volte entro la finestra del TTL. Se un resolver ha messo in cache la risposta, il secondo numero sarà più basso del primo.

#La cache e perché le risposte cambiano

Ogni record ha un TTL, un tempo in secondi che dice ai resolver per quanto possono conservare la risposta. Un TTL breve permette al proprietario di spostare un servizio in fretta, ma fa anche arrivare più query ai server autoritativi. Un TTL lungo riduce il carico, ma le vecchie risposte possono sopravvivere per un po' dopo una modifica.

Quindi una risposta è un'istantanea. Durante una modifica due resolver possono non essere d'accordo, ed entrambi possono avere ragione rispetto alla propria cache. Quando devi sapere cosa ha pubblicato il proprietario, chiedi direttamente a un nameserver autoritativo, per esempio con dig example.com A @<nameserver> usando un server elencato nei record NS del dominio, oppure segui la catena con dig +trace example.com A.

#DNS, OSINT e sicurezza

Consultare i record DNS pubblici di un dominio è un normale primo passo in un inventario degli asset. Un'azienda può rivedere i propri nomi, i propri record di posta e gli indirizzi che ci stanno dietro. I ricercatori combinano spesso questi dati con i log di certificate transparency e le informazioni sui proprietari.

Da una risposta DNS non si possono dedurre due cose. Primo, un record in un risultato di ricerca non è un permesso di scansionare l'host a cui punta. Secondo, un indirizzo IP non identifica chi gestisce la macchina. Con provider di hosting, CDN e server condivisi, un solo indirizzo può servire molti siti senza alcun legame tra loro.

Un record sospetto non è nemmeno la prova di un attacco. Errori di configurazione, servizi scaduti e nomi abbandonati sono comuni. Controlla la risposta autoritativa, lo storico delle modifiche e il proprietario del dominio prima di trarre una conclusione. Cache poisoning e spoofing sono problemi distinti, con prove distinte.

#Errori tipici

• Considerare permanente una singola risposta. Controlla il TTL e ripeti la query più tardi.
• Leggere un CNAME come un indirizzo IP. Segui l'alias fino ad arrivare a un record A o AAAA.
• Dare per scontato che il resolver usato sia il server autoritativo. L'output ti dice quale server ha risposto.
• Leggere un record TXT come la prova che un controllo di sicurezza funziona.
• Scansionare un host perché il DNS puntava lì. Un lookup e una scansione sono azioni diverse con permessi diversi.

#Cosa imparare dopo

Il DNS è uno dei passaggi di una richiesta web. Poi impara come HTTP e TLS gestiscono quello che succede dopo che il nome è diventato un indirizzo, usando le RFC e la documentazione elencate nelle fonti. Quindi leggi il prossimo articolo di questo percorso, sull'OSINT, prima di eseguire query come parte di un'attività di recon. Limita la pratica a domini e sistemi tuoi o che hai il permesso scritto di testare.