Governance del DNS: i quattro modi in cui gli asset DNS falliscono

La maggior parte degli asset DNS non viene gestita. Si accumula. I record vengono creati per ottime ragioni, i progetti che li supportavano terminano e nessuno riconcilia ciò che è pubblicato con ciò che è ancora vero. Chi eredita l'asset si ritrova ogni decisione presa da persone che nel frattempo se ne sono andate, di solito senza alcuna documentazione e senza modo di capire quali record siano ancora rilevanti.

Questo accumulo fallisce in quattro modi specifici, ciascuno con una causa diversa, un costo diverso e un modo diverso di essere individuato.

Ognuno di questi casi inizia allo stesso modo. Qualcuno crea un record per una buona ragione, il progetto che supportava finisce e nessuno riconcilia il record con la realtà in seguito.

La maggior parte degli asset DNS funzionano come un armadio che nessuno apre. È tutto lì dentro, la porta si chiude e finché la posta arriva e il sito si carica, nessuno ha motivo di controllare. Poi qualcuno ha bisogno di una cosa specifica, apre la porta e scopre cosa si è realmente accumulato.

Per anni la situazione è stata tollerabile perché nulla ti diceva diversamente. I framework secondo cui i team di sicurezza vengono valutati erano costruiti sugli esiti, non sui meccanismi. NIST CSF si chiede se gestisci gli asset. NCSC CAF si chiede se comprendi i tuoi sistemi. Nessuno di questi nomina i record DNS come una classe di asset con requisiti di igiene propri, perciò la governance del DNS è rimasta una disciplina non scritta che i team preparati adottavano e tutti gli altri rimandavano.

Le cose sono cambiate in tre anni e quattro documenti, perlopiù europei. L'UE ha scritto requisiti tecnici dettagliati per le organizzazioni che gestiscono l'infrastruttura DNS, ENISA li ha trasformati in linee guida attuabili con esempi di evidenze e NIST ha aggiornato la sua guida al deployment DNS per la prima volta dal 2013. Così il passaggio è stato dall'igiene DNS come buona pratica non scritta a qualcosa che ti può essere richiesto di dimostrare con prove.

Questa guida illustra ciò che questi documenti richiedono effettivamente, a chi si applicano, i quattro modi in cui gli asset DNS falliscono nella pratica e un framework in cinque fasi per governare un asset che non puoi vedere pienamente. È scritta per i team che ereditano grandi portafogli di domini su più registrar e fornitori, dove nessuno ha realmente costruito l'asset di cui ora sono responsabili.

Due delle quattro modalità di fallimento sono già state trattate in dettaglio, e questa guida si limita a rimandare alle relative risorse invece di ripeterle. Inizia da dangling DNS: come trovarlo e risolverlo prima del takeover per vedere cosa dicono OWASP e AWS sui record che rimangono a puntare su risorse cloud eliminate, e come i trasferimenti di zona aperti espongono la tua rete interna per scoprire cosa possono restituire due zone reali consegnate in una sola query.

Due aspetti di questa sequenza meritano attenzione. Il primo è la direzione presa: nel 2022 l'UE ha fissato un obbligo, nel 2024 lo ha tradotto in requisiti tecnici, nel 2025 ENISA ha pubblicato cosa costituisce prova di conformità. I regolatori sono passati da "gestisci il tuo rischio" a "questa è la prescrizione, e così puoi dimostrare di rispettarla". Il DNS è stato nominato esplicitamente in ogni passaggio.

Il secondo è che NIST è arrivato autonomamente a conclusioni simili. SP 800-81r3 non è una reazione a NIS2, ma una revisione da parte di un ente statunitense di linee guida vecchie di tredici anni. Il fatto che due processi su continenti diversi siano approdati entrambi all'igiene del DNS in questo periodo dice più del problema che dei singoli regolatori.

Qui la maggior parte delle trattazioni su NIS2 e DNS diventa imprecisa, e la distinzione conta se stai decidendo cosa la tua organizzazione deve fare.

NIS2 è una direttiva, non un regolamento, quindi ha effetto attraverso la legge di recepimento di ciascuno Stato Membro e non vincola direttamente e uniformemente le aziende in tutta Europa. Gli articoli 2 e 3 elencano i 18 settori e le soglie dimensionali per le entità "essenziali" e "importanti", ma ci sono eccezioni già previste e gli Stati Membri possono anche designare autonomamente entità come rientranti nell'ambito a prescindere dalla dimensione. Gli obblighi di gestione del rischio previsti dall’articolo 21 hanno una forma orientata agli esiti, e il DNS vi rientra come parte della sicurezza di rete e della gestione degli asset piuttosto che come voce nominata. Cosa questo significhi in pratica dipende da come la legge nazionale recepisce la direttiva, quindi la regola pratica settoriale e dimensionale è un punto di partenza, non una risposta definitiva.

Il Regolamento di esecuzione 2024/2690 vincola una lista precisa. I suoi requisiti tecnici dettagliati si applicano a fornitori di servizi DNS, registry di TLD, fornitori di cloud, data center, CDN, managed service, managed security service, marketplace online, motori di ricerca e social network platform e trust service provider. I registrar non sono indicati come categoria autonoma in questo Allegato, ma possono comunque essere coperti dagli obblighi NIS2 mediante recepimento nazionale, anche se quella è una base giuridica separata. Se sei un’impresa che gestisce i propri domini, questo regolamento non ti impone direttamente i requisiti dell’Allegato. Molto probabilmente però vincola diversi tuoi fornitori. Le linee guida tecniche ENISA sono la prosecuzione pratica, incluse tabelle di mappatura rispetto agli standard europei e internazionali.

NIST SP 800-81r3 è una guida volontaria rivolta a tutti. Nessun vincolo, nessun test di campo di applicazione. È un utile riferimento tecnico insieme a legge, contratti e regolamenti di settore, anche perché è il tipo di documento che un auditor o il questionario di sicurezza di un cliente può citare quando chiede come gestisci il DNS, proprio perché si applica ovunque. NIST ha pubblicato possibili aggiornamenti ed errata a luglio 2026, quindi verifica la pagina aggiornata, non una copia cache prima di fare riferimento a dettagli. Per un'analisi concreta di cosa prevede la revisione, dai DNS protettivo all'hardening dei server autoritativi, leggi Ivan Ristic su NIST's secure DNS deployment guide invece di un riassunto qui.

In pratica: la maggior parte delle imprese non è soggetta direttamente ai requisiti tecnici del CIR 2024/2690, mentre la NIS2 potrebbe o meno essere applicabile a seconda di come il tuo paese l'ha recepita. NIST SP 800-81r3 è l'unico di questi documenti che puoi adottare subito, senza attendere un chiarimento sull'ambito o una scadenza di recepimento.

Il fallimento più comune e il meno drammatico. Il DNS smette di risolversi correttamente e, proprio perché di solito smette di risolversi correttamente solo a volte, nessuno se ne accorge.

• Deleghe deboli si presentano quando i record NS della zona padre puntano a un nameserver che non è autoritativo per la zona figlia o che non risponde affatto per quella. La delega è formalizzata, ma il server non fa la sua parte. La risoluzione dipende quindi dal nameserver scelto dal resolver: il dominio funziona per alcune persone e restituisce SERVFAIL per altre. Entrambi sono comportamenti corretti. Solo uno è visibile a chi sta testando.
• Record orfani puntano a infrastrutture che non esistono più. Un server è stato dismesso, un load balancer è stato sostituito, un servizio è migrato, ma il record A o CNAME resta. A volte semplicemente non funziona, altre volte l'indirizzo viene riassegnato a un altro tenant e allora il record punta all'infrastruttura di un altro.
• Guasti di risoluzione parziale sono i più difficili da scoprire, perché eludono il funzionamento del monitoraggio tradizionale. Un controllo che chiede “questo dominio si risolve?” da un solo punto di vista, su un solo resolver, riceve una risposta positiva. Nel frattempo una parte degli utenti si imbatte in un nameserver con dati obsoleti, o in un resolver che valida DNSSEC quando il tuo non lo fa, o in un percorso dove uno dei tanti NS è morto. Il fallimento è reale e riproducibile, solo che non si verifica da dove qualcuno sta guardando.

Questa categoria persiste perché il DNS è progettato per essere resiliente. La ridondanza fa sì che un nameserver rotto su quattro di solito non provochi un’interruzione visibile. Rende il servizio solo leggermente più lento e meno affidabile, degradando silenziosamente e senza mai generare un segnale abbastanza chiaro da spingere qualcuno a indagare.

Un trasferimento di zona, o AXFR, è il modo in cui un nameserver primario replica un file di zona completo a un secondario. È necessario, normale e pericoloso quando non è ristretto, perché un nameserver che non limita i trasferimenti agli IP fidati consegnerà tutta la zona a chiunque la chieda.

Una query restituisce ogni hostname della zona, con indirizzi. Nessuna scansione, nessun brute-force sui sottodomini, nessun tentativo alla cieca. Negli asset che abbiamo analizzato, ciò ha significato convenzioni di naming interne, infrastruttura voce, ambienti di sviluppo dentro le zone di produzione e mappe quasi complete della rete in una sola risposta.

Il modello da conoscere: le zone padre di solito sono protette, perché sono quelle che tutti ricordano di controllare. Le sottodomain delegate, affidate a un altro team o dedicate a un prodotto, curano una propria configurazione e non sono controllate da nessuno. Abbiamo trattato questo in dettaglio, inclusi esempi reali di zone, in come i trasferimenti di zona aperti espongono la tua rete interna.

Un record pendente punta a un servizio di terze parti dopo che il servizio è stato dismesso. Se il nome dietro quel record può essere di nuovo rivendicato da qualcun altro, il dominio va con esso.

La dinamica è semplice e poco affascinante. Un team avvia un sito per una campagna su un website builder, uno storage bucket o un cloud service, vi punta un record DNS e il progetto alla fine termina. Il servizio sparisce. Il record resta, perché crearne uno è un atto pianificato, eliminarlo non è compito preciso di nessuno.

Ciò che trasforma un record pendente in una presa di controllo è la piattaforma dall'altra parte.

Durante una consulenza con un cliente abbiamo eseguito una scansione DNS sull’asset di domini, verificando a cosa puntassero effettivamente i record rispetto a quanto chi ci lavorava ancora pensava puntassero. Un dominio era stato creato anni prima per una campagna marketing, con un record A che risolveva su un website builder di terze parti. La campagna era finita, il sito sparito. Il record era ancora lì, ancora risolutivo, apparentemente ignorato da quando il progetto era finito.

Abbiamo verificato se la piattaforma avrebbe permesso a qualcun altro di rivendicarlo. Lo ha fatto. Nessuna challenge TXT DNS per dimostrare il controllo della zona, nessun file da piazzare sul dominio, nessun check che la configurazione precedentemente fosse stata fatta da altri e nessuna segnalazione al vecchio proprietario. La piattaforma ha considerato il solo record DNS come prova sufficiente di volontà, che è il presupposto su cui poggia tutto il fallimento. Un record che punta a un servizio non dice nulla su chi sia legittimato a rivendicare ciò che sta dietro.

Nello stesso pomeriggio il dominio è stato associato a un account sotto il nostro controllo e serviva una pagina scritta da noi, sull’hostname reale del cliente, sul suo dominio reale, senza avvisi di certificato e senza nulla di apparentemente fuori posto. Un visitatore che digitava quell’indirizzo, o ci arrivava tramite una vecchia email della campagna, non avrebbe avuto motivo di dubitare.

Abbiamo segnalato il problema lo stesso giorno. Dopo la conferma interna il record DNS è stato cancellato in serata, chiudendo l’esposizione. La vulnerabilità era presente da quanto il record esisteva, probabilmente anni. Trovarla, dimostrarla e chiuderla ha richiesto solo un pomeriggio. La parte difficile non è mai stata la soluzione.

Ed è proprio questo che rende takeover più serio degli altri casi di fallimento. Un leak offre informazioni a un attaccante. Una presa di controllo gli offre un canale di consegna affidabile e funzionante. Contenuti serviti da un dominio già affidato dal visitatore non innescano istintivamente i campanelli di allarme come un dominio simile, rendendo il phishing, la distribuzione di malware e il dirottamento del traffico molto più semplici.

I cloud provider sono espliciti sul fatto che questo aspetto non viene gestito da loro. AWS documenta che molti servizi permettono a un nuovo cliente di rivendicare un nome di risorsa già usato, che non esiste un meccanismo universale di verifica dominio tra servizi e che i suoi team di incident response vedono attaccanti scansionare DNS pubblici alla ricerca di record puntati verso risorse non più esistenti [5]. OWASP lo considera un problema operativo e raccomanda inventario, rimozione dei record prima delle risorse dipendenti e monitoraggio degli errori restituiti dal provider quando una risorsa è morta [6]. Entrambi hanno ragione e mettono il lavoro sulle tue spalle. Per i dettagli su come trovare e sanare questi record, vedi dangling DNS: come trovarlo e risolverlo prima del takeover.

Il fallimento che sopravvive agli audit, perché tutto sembra a posto.

DNSSEC non funzionante è il caso più lampante, ed è asimmetrico. Una zona firmata con firme scadute o un record DS che non corrisponde più alla chiave attuale fa fallire la validazione in modo evidente, che è DNSSEC che funziona anche se si mostra come un’interruzione inspiegabile. Il fallimento silenzioso è invece la zona che sembra firmata ma in cui la validazione non avviene mai lungo il percorso. Si ottiene l’apparenza di DNSSEC ma senza protezione. La nostra guida su NIST's DNS deployment guidance spiega come distribuire DNSSEC correttamente.

Un record TLSA pubblicato non è, da solo, una distribuzione DANE; è valido per DANE solo quando la catena DNSSEC è verificata in sicurezza. Per SMTP, un risultato TLSA insicuro viene trattato come TLS opportunistico pre-DANE, non come DANE autenticato.

Record NS e SOA incoerenti significano che i tuoi nameserver non sono d’accordo su cosa contenga la zona. Se il set di NS al padre non corrisponde ai NS della zona figlia, i resolver possono raggiungere server che tu pensi non siano più autoritativi. Se i numeri seriali SOA differiscono tra nameserver, potrebbero servire dati diversi, e la risposta ricevuta dall’utente dipende dal server raggiunto. Entrambe queste condizioni non sono rilevabili interrogando un solo nameserver e ottenendo una risposta valida.

Ciò che accomuna questa categoria è che i controlli danno esito positivo. Puoi avere una scansione pulita, una zona firmata e un record DANE, ma non ottenere nessuna delle protezioni che dovrebbero offrire.

Due aspetti da evidenziare in questa mappatura.

La delega debole compare due volte, in due diversi casi di fallimento, ed è l’esempio più chiaro di quanto la tassonomia sia utile. La sezione 3.2.1 la considera un problema di disponibilità, cioè una delega che punta a un server inesistente rende la zona figlia non raggiungibile o accessibile a intermittenza. La sezione 3.6.2 vede la stessa configurazione errata come una via di takeover, dove una sottodominio delegata a un provider DNS il cui contratto è scaduto può essere presa in carico da un attore minaccioso stipulando un nuovo contratto con lo stesso fornitore. Una sola configurazione errata, due esiti completamente diversi, e la maggior parte dei team cerca solo il primo scenario.

La drift e il thrash di zona, nella sezione 3.2.2, sono le forme nominate del problema di incoerenza. Impostare valori troppo alti di Refresh e Retry nei record SOA di una zona che cambia spesso fa sì che i secondari servano dati obsoleti. Impostarli troppo bassi genera carico superfluo di trasferimento su primario e secondari. Entrambi degradano il servizio senza provocare un’interruzione evidente.

Tutto ciò che segue dipende da questo punto e qui la maggior parte dei programmi fallisce silenziosamente. L’obiettivo è la copertura totale: ogni dominio, zona e record su ogni registrar, fornitore DNS, account cloud e autorità di certificazione, a prescindere dall’esistenza attuale del team che li ha creati. L’errore è compilare l’elenco dalla memoria istituzionale, perché proprio i record che causano incidenti sono quelli che nessuno ricorda. Domini ereditati da acquisizioni e mai migrati. Sottodomini delegati a un team che poi si è riorganizzato. Siti di campagna creati dal marketing senza ticket. Un elenco ottenuto chiedendo alle persone cosa possiedono sarà sicuramente errato — e lo sarà proprio nei punti critici. Il nostro blog su dangling DNS mostra cosa succede ai record che non finiscono nelle liste di nessuno.

Una volta che sai cosa esiste, definisci cosa significa “buono” così che ogni deviazione risulti visibile. Serve tracciare quali registrar e fornitori DNS sono autorizzati, quali indirizzi cloud e CA ti aspetti di vedere, come dev’essere la postura di autenticazione email su ciascun dominio mittente e quali zone sono firmate con DNSSEC. Il punto è la comparazione: una modifica NS non autorizzata e una migrazione pianificata producono lo stesso evento DNS — solo il baseline ti dice quale dei due stai guardando. Asset senza baseline non sono ciechi al cambiamento, sono ciechi al significato dei cambiamenti.

Metti a confronto in modo continuo l’asset live con il baseline, poi classifica ciò che emerge. Circa l’1% dei nomi in un grande asset cambia ogni giorno: in 37.500 record parliamo di 375 eventi quotidiani. Un feed puro di cambiamenti a tale volume viene ignorato in meno di due settimane, il che è peggio che non averlo, perché simula un monitoraggio. La classificazione rende il tutto gestibile: separa i cambiamenti di routine lato fornitore dai record che iniziano a puntare a luoghi indesiderati, e filtra l’atteso per far emergere l’inaspettato.

Valuta l’asset rispetto a NIST SP 800-81r3, usando la mappatura sopra per tradurre ogni modalità di fallimento in una serie di controlli. Ricontrolla ogni giorno, non periodicamente, e traccia il tasso di superamento nel tempo invece di considerare ogni scansione separata. Una scansione pulita ti dà una foto di un istante. Un andamento in calo per sei settimane segnala deriva — il segnale che serve veramente — ed arriva molto prima di qualunque guasto.

Segmenta l’asset così che il modello resti sostenibile, e segmenta sia i cambiamenti sia gli asset. Una modifica NS su un dominio che gestisce traffico di autenticazione clienti non è lo stesso evento che su una registrazione difensiva inattiva, e trattarli allo stesso modo garantisce che quello importante si perda. Metti in relazione i cambiamenti con le issue aperte: un record che cambia mentre ha già una criticità aperta deve essere gestito come emergenza invece che andare in coda. Se segni tutto come critico, il programma collassa sotto il proprio peso in un trimestre.

Il salto che conta di più è dal livello 2 al livello 3, perché è lì che il rilevamento smette di dipendere dal fatto che qualcuno decida di controllare.

Verifica questi punti sulla tua infrastruttura. Qualsiasi punto a cui non puoi rispondere con sicurezza rappresenta già di per sé una criticità.

• Sei in grado di produrre un elenco di tutti i domini di proprietà della tua organizzazione, presso ogni registrar
• L'elenco include i domini acquisiti tramite fusioni e acquisizioni
• Sai quale provider DNS ospita ogni zona
• Puoi elencare ogni sottodominio delegato a un nameserver che non controlli
• Ogni zona ha un proprietario nominato che lavora ancora in azienda

• Ogni record NS in ogni zona padre punta a un nameserver che è autoritativo per la zona figlia
• I numeri di serie SOA corrispondono su tutti i nameserver per ogni zona
• Il set NS nel padre corrisponde al set NS pubblicato nella zona figlia
• Esegui i test di risoluzione da più resolver e aree geografiche, non solo da uno

• I trasferimenti di zona sono limitati a indirizzi IP secondari nominati su ogni nameserver
• Hai testato AXFR contro ogni sottodominio delegato, non solo il padre
• Nessuna zona contiene nomi host che rivelano convenzioni di naming interne o infrastrutture non pubbliche
• Gli ambienti di sviluppo e test non si trovano nelle zone di produzione

• Puoi elencare ogni record DNS che punta a una piattaforma SaaS di terzi, servizio cloud o bucket di storage
• La rimozione del record DNS è un passaggio obbligatorio durante la disattivazione di qualsiasi servizio terzo
• Sai quali di queste piattaforme verificano la proprietà del dominio prima di consentirne l'associazione
• Qualcuno revisiona questi record su base programmata e non solo in caso di incidente

• Sai quali zone sono firmate con DNSSEC e quali no
• La scadenza delle firme è monitorata, non data per scontata
• Ogni zona che pubblica record TLSA per DANE è firmata DNSSEC
• I record DS nel padre corrispondono alle chiavi attuali nella zona figlia
• Hai testato che la validazione effettivamente fallisca quando dovrebbe

• Esiste una base che definisce registrar, provider, intervalli cloud e autorità di certificazione autorizzati
• Le modifiche ai record NS, MX e TXT generano un avviso
• L'infrastruttura è suddivisa per importanza e non trattata uniformemente
• Qualcuno è responsabile in modo nominativo della igiene DNS e non solo per assunzione implicita

La fase che blocca la maggior parte dei programmi è la prima, perché tutto ciò che segue dipende dal conoscere cosa esiste. I controlli di configurazione cloud-native sono utili ma progettati per il singolo account. Gli scanner open-source abbracciano un ambito più ampio ma vengono eseguiti solo quando qualcuno si ricorda di farlo. Nessuno dei due copre un'infrastruttura distribuita su più registrar, provider DNS e account cloud appartenenti a team che non rispondono alla sicurezza.

Red Sift ASM costruisce quell'inventario collegandosi direttamente ai tuoi registrar, provider DNS e account cloud invece di affidarsi a un elenco mantenuto manualmente. Monitora continuamente la configurazione DNS e DNSSEC sull'intero perimetro, segnala i record sospesi e le risorse reclamabili appena compaiono e valida la configurazione DANE, il che significa che le criticità descritte in questa guida emergono come rilievi anziché come incidenti.

• [1] Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio del 14 dicembre 2022 relativa a misure per un livello comune elevato di cybersicurezza nell’Unione
• [2] Regolamento di esecuzione (UE) 2024/2690 della Commissione del 17 ottobre 2024
• [3] Guida tecnica di implementazione NIS2
• [4] Secure Domain Name System (DNS) Deployment Guide, NIST SP 800-81r3
• [5] Threat Tactic Spotlight: Subdomain Takeover
• [6] Subdomain Takeover Prevention Cheat Sheet