Il DNS è una di quelle configurazioni che spesso viene impostata quando nasce un progetto e poi viene lasciata praticamente invariata per anni.
Nel frattempo, però, cambiano server, provider, servizi cloud, piattaforme email e applicazioni.
Il risultato può essere una configurazione DNS piena di record che non riflettono più la situazione reale.
Questo è ciò che viene generalmente indicato come DNS misconfiguration: una configurazione DNS errata, incompleta, incoerente o non più necessaria.
Non tutti gli errori DNS sono vulnerabilità.
Alcuni però possono aumentare la superficie di attacco o causare problemi di sicurezza.
1. Record che puntano a servizi non più utilizzati
È uno dei casi più comuni.
Per esempio:
old.example.com → old-provider.com
Il progetto è stato chiuso, ma il record è ancora presente.
Prima di eliminare il record bisogna capire se viene ancora utilizzato.
Se non serve più, dovrebbe essere rimosso.
2. CNAME verso risorse esterne abbandonate
Un caso più delicato riguarda i CNAME:
blog.example.com → customer.provider.com
Se la risorsa presso il provider viene eliminata ma il CNAME rimane, si può creare una situazione che merita una verifica.
In determinati casi può essere possibile un subdomain takeover.
Il record non è quindi automaticamente vulnerabile, ma la relazione con il servizio esterno deve essere verificata.
3. Record A o AAAA non aggiornati
Supponiamo che un server venga spostato:
Prima:
example.com → 192.0.2.10
Dopo:
example.com → 192.0.2.20
Se rimane un vecchio record o un vecchio sottodominio che continua a puntare verso 192.0.2.10, potrebbe essere ancora possibile raggiungere un'infrastruttura che si pensava fosse stata dismessa.
Questo è particolarmente importante dopo:
- migrazioni;
- cambi di hosting;
- ristrutturazioni dell'infrastruttura;
- sostituzione di server;
- passaggi al cloud.
4. Dimenticare IPv6
Un'organizzazione può proteggere correttamente il proprio server IPv4 ma dimenticare che esiste anche un record AAAA.
Per esempio:
example.com
A → server IPv4
AAAA → server IPv6
Se l'infrastruttura IPv6 non viene gestita con la stessa attenzione, può diventare una parte della superficie pubblica trascurata.
La regola dovrebbe essere semplice:
ogni percorso attraverso cui un servizio è raggiungibile deve essere gestito e protetto.
5. Record DNS di ambienti di test
È frequente trovare nomi come:
dev.example.com
test.example.com
staging.example.com
preview.example.com
Avere un ambiente di staging non è un problema.
Lasciarlo esposto senza le stesse attenzioni dedicate alla produzione può invece diventarlo.
Un ambiente di test può utilizzare software differente, configurazioni temporanee o dati che non dovrebbero essere pubblicamente accessibili.
6. Nameserver non più coerenti
Il dominio dipende dai suoi nameserver autorevoli.
Se la configurazione del registrar e quella DNS non sono gestite correttamente, possono verificarsi problemi di disponibilità o configurazioni incoerenti.
Quando si cambia provider DNS è quindi importante verificare che:
- i nameserver siano corretti;
- la nuova zona DNS contenga tutti i record necessari;
- i vecchi servizi siano stati rimossi;
- non rimangano configurazioni duplicate o dimenticate.
7. Record MX obsoleti
Anche la posta elettronica può essere coinvolta.
Per esempio:
example.com
MX 10 old-mail.example.net
Se l'organizzazione ha migrato la posta verso un nuovo provider, quel record dovrebbe essere controllato.
Una configurazione MX errata può causare problemi di consegna delle email e, in alcuni scenari, creare comportamenti inattesi.
8. Record TXT dimenticati
I record TXT vengono utilizzati per molti scopi.
È quindi abbastanza normale trovare record relativi a servizi che non vengono più utilizzati.
Per esempio:
example.com TXT "service-verification=..."
oppure configurazioni SPF, DKIM o DMARC relative a servizi precedenti.
Non significa che debbano essere eliminati automaticamente.
Prima bisogna capire a cosa servono.
9. CAA non configurato
I record CAA permettono di indicare quali Certificate Authority sono autorizzate a emettere certificati per un dominio.
Non averne uno non significa automaticamente che il dominio sia vulnerabile.
La loro utilità dipende dalla strategia di gestione dei certificati dell'organizzazione.
In contesti strutturati, però, possono contribuire a rendere più esplicita la politica relativa all'emissione dei certificati.
10. DNS e infrastruttura non documentati
Questo è forse il problema più grande.
Non tanto il singolo record sbagliato, ma il fatto che nessuno sappia spiegare perché esista.
Un dominio con decine di record dovrebbe avere almeno una minima documentazione.
Per esempio:
api.example.com
→ API di produzione
→ server interno
→ proprietario: Team Development
→ criticità: alta
Se invece trovi:
old2.example.com
→ ???
→ nessun proprietario
→ nessuna documentazione
vale la pena indagare.
Come controllare una configurazione DNS
Un primo controllo può essere eseguito con strumenti comuni.
Per esempio:
dig example.com
Per un record specifico:
dig A example.com
dig AAAA example.com
dig MX example.com
dig TXT example.com
Per un CNAME:
dig CNAME blog.example.com
Questi comandi permettono di osservare la configurazione pubblicamente visibile.
DNS corretto non significa automaticamente infrastruttura sicura
È importante non confondere i due concetti.
Un dominio può avere una configurazione DNS perfettamente corretta e allo stesso tempo avere:
- un pannello amministrativo esposto;
- un servizio obsoleto;
- un'API mal configurata;
- un server non aggiornato;
- un ambiente di staging accessibile.
Il DNS è quindi una parte dell'analisi, non l'analisi completa.
Una checklist semplice
Periodicamente conviene chiedersi:
- Tutti i record esistenti sono ancora necessari?
- Tutti i sottodomini sono conosciuti?
- I CNAME puntano ancora a servizi validi?
- Esistono vecchi indirizzi IP?
- IPv4 e IPv6 sono entrambi gestiti?
- Gli ambienti di test sono conosciuti?
- I record MX sono corretti?
- I TXT appartengono ancora a servizi attivi?
- I nameserver sono quelli previsti?
- Ogni record importante ha un proprietario?
Se una di queste domande non ha una risposta, il record merita almeno una verifica.
In sintesi
Una configurazione DNS sicura non significa avere una configurazione complessa.
Spesso significa semplicemente avere una configurazione conosciuta, documentata e aggiornata.
I problemi più comuni derivano da:
- vecchi record;
- servizi esterni dismessi;
- ambienti di test dimenticati;
- indirizzi IP obsoleti;
- configurazioni IPv6 trascurate;
- record email non più necessari;
- assenza di un inventario.
La gestione del DNS dovrebbe quindi essere considerata parte della gestione della superficie di attacco.
MiHakero può aiutare a confrontare ciò che è osservabile dall'esterno con ciò che dovrebbe essere presente, evidenziando gli elementi che meritano un approfondimento.