- Comprendere l'architettura gerarchica del Domain Name System e la delega di zona
- Eseguire interrogazioni mirate sui record DNS autoritativi e ricorsivi
- Condurre un audit sistematico dell'infrastruttura DNS di un dominio pubblico
- Verificare la robustezza e la conformità delle policy email (SPF, DKIM, DMARC)
- Individuare misconfigurazioni, record orfani e rischi di Subdomain Takeover
- Utilizzare strumenti web-based e da riga di comando per il troubleshooting di rete
Fondamenti dell'Architettura DNS e Superficie di Attacco
Tag: Architettura DNS | Tag: Superficie di Rischio
Il Domain Name System (DNS) costituisce l'infrastruttura critica su cui poggia l'intera raggiungibilità dei servizi di rete. Basato su un modello a database distribuito e gerarchico (Root Server, TLD Server, Server Autoritativi), una sua configurazione errata o debole espone l'intera organizzazione a vettori d'attacco severi quali Man-in-the-Middle, DNS Spoofing, dirottamento del traffico e intercettazione dei flussi email.
Eseguire un Audit DNS significa mappare, validare e verificare periodicamente la coerenza di tutti i Resource Record (RR) pubblicati per una specifica zona, garantendo riservatezza, integrità e disponibilità del dominio.
| Tipologia Record | Funzione Tecnica | Criticità tipica in fase di Audit |
|---|---|---|
| A / AAAA | Mappatura hostname verso indirizzi IPv4 / IPv6 | Esposizione involontaria di IP interni o interfacce di gestione riservate |
| CNAME | Alias canonico verso un altro Fully Qualified Domain Name (FQDN) | Puntamento a domini o bucket cloud scaduti (vulnerabilità di takeover) |
| NS | Delega autoritativa dei name server per la zona | Lame delegation, name server non sincronizzati o non protetti |
| MX | Instradamento prioritario dei server di posta in ingresso | Priorità mal configurate, server di fallback non aggiornati |
| TXT | Attributi testuali generici, validazione domini e framework antispam | Record SPF multipli o sintatticamente errati, chiavi DKIM deboli |
| SOA | Parametri operativi primari della zona (serial, TTL, timer di refresh) | Serial number non incrementati, timer di expire eccessivamente bassi |
Strumenti Operativi: Google Admin Toolbox Dig e CLI
Tag: Google Admin Toolbox | Tag: Terminale Dig
Per condurre le verifiche di audit in modo indipendente dai server DNS configurati sulla scheda di rete locale (che potrebbero introdurre risposte alterate da cache locali o policy proxy aziendali), è prassi servirsi di resolver pubblici neutrali o suite di analisi cloud native.
https://toolbox.googleapps.com/apps/dig/.
Permette di interrogare direttamente i resolver ricorsivi Google Public DNS (8.8.8.8 / 8.8.4.4) su qualsiasi record arbitrario, eliminando il rumore della cache locale della postazione di lavoro.
Qualora sia necessario operare direttamente dall'infrastruttura server o da script automatici di audit, è possibile eseguire gli stessi comandi nativamente tramite terminale:
Utilizzo dell'utility standard dig (Domain Information Groper):
# Interrogazione specifica del record MX verso resolver 8.8.8.8
dig @8.8.8.8 example.com MX +noall +answer
# Interrogazione completa di tutti i record TXT con formattazione pulita
dig @8.8.8.8 example.com TXT +short
# Tracciamento gerarchico iterativo partendo dai Root Server
dig example.com +trace
Utilizzo di cmdlet PowerShell nativi per l'audit:
# Risoluzione record MX tramite resolver Google Public DNS
Resolve-DnsName -Name example.com -Type MX -Server 8.8.8.8
# Recupero di tutti i record di zona (Any query)
Resolve-DnsName -Name example.com -Type ANY -Server 8.8.8.8
Validazione delle Policy di Autenticazione Email
Tag: SPF | Tag: DKIM & DMARC
Uno degli ambiti più critici di un audit DNS riguarda l'ispezione dei record TXT deputati all'autenticazione della posta elettronica. L'assenza o la configurazione permissiva di tali parametri permette a soggetti malevoli di inviare email fingendosi il dominio legittimo (CEO Fraud, phishing mirato).
| Protocollo | Scopo Tecnico | Pattern di Verifica Audit |
|---|---|---|
| SPF Sender Policy Framework |
Definisce la lista esaustiva degli indirizzi IP autorizzati a trasmettere posta a nome del dominio. | Verificare che termini con ~all (SoftFail) o -all (HardFail). Non deve superare il limite massimo di 10 DNS lookup per non invalidare la query. Mai inserire più di un record SPF per zona. |
| DKIM DomainKeys Identified Mail |
Garantisce l'integrità del messaggio mediante firma asimmetrica verificabile tramite chiave pubblica su DNS. | Interrogare il sottodominio selettore (es. selettore._domainkey.dominio.tld) verificando che la lunghezza della chiave RSA sia di almeno 2048 bit. |
| DMARC Domain-based Message Authentication |
Stabilisce l'azione da intraprendere (none, quarantine, reject) se SPF o DKIM falliscono, abilitando reportistica. | Verificare il record TXT su _dmarc.dominio.tld. La policy ottimale di produzione deve tendere a p=reject con mail di telemetria attiva (rua=mailto:...). |
include, a, mx, ptr, exists). Se il limite viene superato, i mail server riceventi sollevano l'eccezione PermError, invalidando di fatto l'autenticazione.
Laboratorio Pratico Guidato: Esecuzione di un Audit DNS
Tag: Procedura Step-by-Step | Tag: Diagnostica Google Toolbox
La seguente procedura descrive i passaggi metodologici per sottoporre ad audit un dominio d'esempio (utilizzeremo convenzionalmente scuola-digitale.edu.it) tramite l'interfaccia web di Google Admin Toolbox Dig.
- Accedere all'interfaccia Google Dig.
- Digitare nel campo di testo il nome del dominio target.
- Selezionare il pulsante di filtro NS.
- Annotare i server restituiti nella sezione di risposta.
Verifica di conformità: Devono essere presenti almeno due server autoritativi, posizionati preferibilmente su Subnet e Autonomous System (AS) differenti, per garantire tolleranza ai guasti.
- Selezionare il filtro MX su Google Dig per il dominio in esame.
- Verificare i valori numerici di priorità associati a ciascun host.
Output atteso tipico:
10 mail.scuola-digitale.edu.it.
20 backupmx.scuola-digitale.edu.it.
Assicurarsi che gli indirizzi puntati siano FQDN validi (Record A) e mai record CNAME, come prescritto dalla RFC 2181.
- Interrogare i record TXT del dominio radice.
- Localizzare la stringa che inizia con
v=spf1. - Nel campo di input, digitare il percorso completo del record DMARC aggiungendo il prefisso:
_dmarc.scuola-digitale.edu.it, mantenendo il filtro su TXT.
Esempio di output corretto e robusto:
# Risultato TXT del dominio:
"v=spf1 include:_spf.google.com ip4:195.120.40.10 -all"
# Risultato TXT di _dmarc.scuola-digitale.edu.it:
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@scuola-digitale.edu.it; pct=100"
p=reject garantisce che qualsiasi email che fallisca contemporaneamente SPF e DKIM venga rigettata a monte dai server SMTP mondiali, impedendo abusi d'identità.
Troubleshooting: Anomalie Ricorrenti ed Errori di Configurazione
Tag: Risoluzione Problemi | Tag: Errori Tipici
| Anomalia Rilevata | Causa Tecnica | Azione Correttiva |
|---|---|---|
| CNAME and Other Data Violation | È stato associato un record CNAME al vertice della zona (apex domain, es. dominio.tld) dove sono presenti SOA e NS. |
Sostituire il CNAME al vertice con un record A / AAAA (o usare record ALIAS / ANAME gestiti a livello di DNS provider). |
| Multiple SPF Records | Esistono due o più record TXT che iniziano con v=spf1. |
Fondere tutti i meccanismi autorizzativi in un unico record SPF consolidato. Record SPF multipli causano invalidazione automatica. |
| Dangling DNS Records | Record CNAME punta a un servizio cloud (AWS S3, GitHub Pages, Azure) la cui sottoscrizione o risorsa è stata cancellata. | Rimuovere immediatamente il record CNAME obsoleto per prevenire il Subdomain Takeover. |
| TTL Eccessivamente Alto o Basso | Time-To-Live configurato a valori sproporzionati (es. > 86400s per record volatili o < 60s su zone statiche). | Impostare valori bilanciati: tipicamente 3600s (1 ora) per record standard o 300s in fase di migrazione pianificata. |
- L'audit DNS è una procedura di sicurezza preventiva finalizzata alla mappatura e alla bonifica dei record di risoluzione di una zona.
- L'utilizzo di resolver pubblici terzi come Google Admin Toolbox Dig previene gli errori indotti dalla cache DNS locale e permette diagnosi isolate.
- I record critici per la sicurezza applicativa ed email sono primariamente NS, MX, TXT (contenenti SPF, DKIM, DMARC) e CNAME.
- Le policy antispam richiedono massimo un record SPF (con limite stringente di 10 lookup) e una policy DMARC strutturata (
p=quarantineop=reject). - I record orfani verso servizi esterni dismessi espongono a vulnerabilità critiche di acquisizione illegittima del sottodominio (Subdomain Takeover).
- A strutturare una metodologia completa di audit DNS per domini di secondo e terzo livello.
- A interrogare in modo selettivo i Resource Record (A, AAAA, MX, NS, TXT, SOA) tramite tool web-based e command-line interface.
- A interpretare e correggere i parametri di autenticazione email SPF e DMARC per la prevenzione dello spoofing.
- A riconoscere le violazioni agli standard RFC come la collisione dei CNAME e le de-sincronizzazioni di zona.
Parole chiave
I termini principali introdotti in questa guida sono: