Record DNS sospesi: cosa sono e come prevenire il dirottamento dei sottodomini

Un record DNS "dangling" è una voce DNS che continua a puntare a una risorsa che non esiste più, come un servizio cloud cancellato, un server dismesso o una piattaforma di terze parti inattiva. Il record continua a essere risolto anche se la destinazione a cui rimanda non esiste più, e proprio questa discrepanza è ciò che gli aggressori cercano di sfruttare.

Per i team IT e di sicurezza, la difficoltà raramente consiste nell'individuare un singolo record errato. Si tratta piuttosto di mantenere una visibilità costante su domini, sottodomini e record di autenticazione, mentre l'infrastruttura sottostante è in continua evoluzione. Ogni migrazione, cambio di fornitore e servizio dismesso lascia dietro di sé dei record potenzialmente errati.

Cosa sono i record DNS pendenti?

Un record DNS "dangling" è una voce DNS che punta a una risorsa che non esiste più o che è inaccessibile. I criminali informatici su Internet sono sempre alla ricerca di tali voci DNS, poiché sono soggette a fughe di informazioni. Alcune di queste voci potrebbero contenere informazioni sensibili relative a un dominio, trasformandosi in una vera e propria miniera d’oro di dati da cui gli autori delle minacce possono trarre vantaggio.

Situazioni comuni che causano un DNS "dangling"

Configurazioni errate del DNS. Il Domain Name System è configurato separatamente dalla risorsa Internet con cui vogliamo interagire. I record DNS aggiunti al DNS puntano a queste risorse, consentendoci di accedervi. In alcuni casi, una risorsa precedentemente configurata può essere disconfigurata dal proprio host. Ad esempio, un record DNS è stato configurato dal proprietario di un dominio per puntare all’IP di un server. Questo server ora non è più in uso. Il record DNS ora punta a una risorsa che non esiste più e può quindi essere definito una voce “DNS dangling”.

Risorse cloud scadute o eliminate. Se un servizio cloud utilizzato dal proprietario di un dominio scade o viene eliminato, qualsiasi record DNS che punta a quel servizio diventa un record DNS "dangling" . Questo record DNS rimane comunque attivo e qualsiasi malintenzionato può utilizzare la risorsa per diffondere contenuti dannosi.

Indirizzi IP obsoleti. Un'azienda può migrare i propri servizi verso un nuovo provider, mentre gli indirizzi IP precedenti vengono dismessi. Se il team dimentica di aggiornare o rimuovere i vecchi record DNS, tali record diventano vulnerabili al subdomain takeover e possono essere facilmente sfruttati.

Disattivazione o interruzione del servizio. Un server di posta elettronica, un account di hosting o un fornitore di servizi di terze parti viene interrotto o dismesso; tuttavia, i record DNS come MX, A e CNAME rimangono attivi e configurati. Gli aggressori possono sfruttare questi record DNS attivi e "sospesi" per impersonare il servizio interrotto.

Quali record DNS rimangono "sospesi" e quali sono i rischi associati a ciascuno di essi

La vulnerabilità risiede nel divario tra il livello DNS e il livello delle risorse. Un record può essere sintatticamente corretto e tuttavia rappresentare un pericolo quando la destinazione a cui fa riferimento non è più di proprietà dell'utente o non è più attiva. La tabella sottostante illustra tale divario in base al tipo di record.

Errore comune

Considerare una ricerca DNS andata a buon fine come prova che il record è in regola. Un record “dangling” viene risolto normalmente, poiché la voce in sé è valida. Ciò che conta è se la vostra organizzazione possiede e controlla ancora la destinazione. Verificare la risoluzione senza controllare la proprietà è il motivo per cui questi record superano gli audit.

Dove compaiono più spesso i record "dangling"

Alcune parti di una tenuta producono questi documenti in modo molto più affidabile rispetto ad altre. Sapere quali sono ti permette di effettuare i controlli in base alla probabilità, anziché dover setacciare l’intera zona ogni volta.

• Bucket di archiviazione cloud e host di siti statici: i nomi dei bucket sono univoci a livello globale e possono essere registrati nuovamente a piacimento, quindi un bucket eliminato con un CNAME attivo è uno degli obiettivi più facili da rivendicare
• Sottodomini personalizzati CDN e SaaS: help.example.com, status.example.com e careers.example.com di solito rimandano a piattaforme di terze parti che liberano il nome host nel momento in cui l'abbonamento scade
• Strumenti di marketing e per le landing page: i sottodomini delle campagne vengono configurati rapidamente da team esterni al reparto IT e raramente sono soggetti a un processo di disattivazione
• Ambienti di staging e di test: i record dev, uat e staging sopravvivono ai progetti che li hanno creati, e nessuno se ne accorge perché nessun traffico reale dipende da essi
• Domini acquisiti o controllati: le zone ereditate presentano record i cui proprietari originari non sono più disponibili, e raramente sono accompagnate dalla relativa documentazione
• Fornitori di servizi di posta elettronica e assistenza non più attivi: Voci MX, CNAME DKIM e inclusioni SPF relative a una piattaforma per la quale hai smesso di pagare lo scorso anno

Il filo conduttore che li accomuna è la deriva della proprietà. Ogni record è stato creato correttamente da qualcuno che ne aveva l’autorità, ma poi è sopravvissuto al rapporto che ne giustificava l’esistenza. Ecco perché la responsabilità della pulizia spetta a chi disattiva un servizio piuttosto che a chi amministra il DNS.

Record TXT DMARC

I record DMARC vengono pubblicati come record TXT e spesso includono destinazioni di segnalazione tramite i tag rua e ruf. Se tali destinazioni rimandano a caselle di posta inattive o non monitorate, i team perdono la visibilità sui fallimenti di autenticazione e sui tentativi di spoofing senza che venga segnalato alcun errore. Verificate come pubblicate un record DMARC ogni volta che gli indirizzi di segnalazione o i proprietari cambiano.

Record TXT SPF

I record SPF elencano i servizi di invio autorizzati tramite indirizzi IP e includono meccanismi di controllo. Se un record SPF fa riferimento a un servizio di terze parti obsoleto o a un dominio abbandonato, l’autenticazione diventa inaffidabile e un malintenzionato che registri quel dominio del fornitore abbandonato ne eredita l’autorizzazione all’invio. Inoltre, con l’aumentare del numero di mittenti SaaS, i record superano il limite di 10 ricerche DNS, pertanto il “flattening” SPF li mantiene entro tale limite. Scopri di più sul SPF.

Record TLS-RPT

I record TLS-RPT definiscono dove SMTP TLS devono essere inviati. Se la destinazione di segnalazione è inattiva, configurata in modo errato o non più monitorata, i team non vengono a conoscenza dei guasti alla sicurezza del trasporto che compromettono la consegna della posta crittografata. Scopri di più su TLS-RPT e MTA-STS.

Record CNAME DKIM

I record DKIM possono essere pubblicati come record CNAME che puntano all’host DKIM di un provider di invio. Se l’account del provider viene eliminato o il dominio di destinazione diventa inattivo, la firma e la verifica DKIM cessano di funzionare senza alcun avviso. Ad esempio, il sottodominio mail.domain.com è un alias del record CNAME info.domain.com. Pertanto, quando un server effettua la ricerca di mail.domain.com, verrà reindirizzato a info.domain.com. Il tuo sistema di autenticazione DKIM viene spesso aggiunto al DNS come record CNAME.

Nota: i record MX, NS, A, AAAA, CNAME e TXT possono tutti diventare "dangling" quando fanno riferimento a infrastrutture inattive, servizi dismessi o provider di terze parti abbandonati. Questo articolo si concentra sui record di autenticazione e-mail, poiché sono proprio questi errori a rimanere invisibili più a lungo.

In che modo il DNS "dangling" porta al controllo dei sottodomini

Nascoste Vulnerabilità del DNS come il DNS "dangling" possono portare allo sfruttamento dei domini e a minacce informatiche. In settori regolamentati quali quello finanziario, sanitario, dell’istruzione, della vendita al dettaglio e del settore pubblico, i problemi irrisolti relativi al DNS e all’autenticazione complicano inoltre le verifiche di sicurezza e la preparazione agli audit.

L'attacco stesso segue una sequenza prevedibile, il che è utile perché mostra esattamente in quale punto un controllo interrompe la catena.

1. Enumerazione dei sottodomini. L'autore dell'attacco esegue una scansione del dominio alla ricerca di sottodomini utilizzando strumenti DNS pubblici, registri di trasparenza dei certificati o l'enumerazione con forza bruta.
2. Identificazione di record non risolvibili. L'autore dell'attacco individua un record CNAME, A o MX che punta a un servizio esterno che restituisce una risposta del tipo "account inesistente" o "non reclamato".
3. Richiesta di risorse. L'autore dell'attacco registra lo stesso account, bucket o nome host sulla piattaforma esterna, che si tratti di un bucket di archiviazione cloud, di un endpoint CDN o di un sottodominio SaaS.
4. Dirottamento del traffico. Poiché il tuo record DNS punta ancora a quel sottodominio, ogni richiesta indirizzata a esso viene ora instradata attraverso l'infrastruttura controllata dall'autore dell'attacco.
5. Abuso della fiducia acquisita. Il sottodominio di fiducia provvede quindi a pubblicare pagine di phishing, ospitare malware, rubare cookie di sessione, inviare e-mail contraffatte o raccogliere credenziali, il tutto sotto il nome di dominio della vostra organizzazione.

Che cos’è un attacco di appropriazione di un sottodominio?

Quando un malintenzionato rileva una voce DNS "dangling" che punta a una risorsa non più configurata, può appropriarsi della risorsa abbandonata e instradare il traffico attraverso un'infrastruttura da lui controllata. L'autore dell'attacco prende il controllo del (sotto)dominio a cui punta il record DNS "dangling", instradando così l'intero traffico verso un dominio da lui controllato, con accesso completo ai contenuti e alle risorse di tale dominio.

Il danno va ben oltre la semplice alterazione di una pagina. Le azioni degli aggressori includono il furto di credenziali tramite pagine di accesso contraffatte, malware ospitato su un sottodominio affidabile, l’usurpazione del marchio tramite e-mail e sul web, l’intercettazione dei cookie di sessione, l’abuso di SEO sfruttando l’autorità del dominio, l’abuso nella consegna delle e-mail a causa di record MX o SPF configurati in modo errato e il danno alla reputazione che emerge in seguito durante le verifiche di conformità.

Nome host "dangling" vs. record DNS "dangling"

I due termini sono strettamente correlati e vengono utilizzati in modo intercambiabile, sebbene descrivano concetti diversi. Un record DNS "dangling" è la voce stessa, ovvero un record CNAME o A che esiste ancora nel file di zona ma che punta a una risorsa rimossa o senza proprietario. Un nome host "dangling" è il sottodominio che risolve verso una destinazione che nessuno all’interno della propria organizzazione controlla più.

In pratica, è il record a creare il nome host. Se dev.example.com ha un record CNAME che punta a un account di hosting disattivato, allora dev.example.com è un nome host "dangling" e il record CNAME è il record "dangling" che sta alla base. La distinzione è importante perché gli scanner segnalano l’uno o l’altro, mentre entrambi richiedono la stessa correzione: verificare la proprietà del sito di destinazione, quindi rimuovere o reindirizzare il record.

Come individuare i record DNS non associati

Individuare tempestivamente i record DNS che puntano a risorse non configurate può contribuire a proteggere il vostro marchio. È possibile procedere in due modi: manualmente o in modo automatizzato.

Rilevamento manuale

Sebbene richieda molto tempo, una verifica manuale può aiutare a individuare i record DNS obsoleti, soprattutto a seguito di migrazioni al cloud, cambi di fornitore, dismissione di servizi o integrazione di nuovi mittenti.

• Verifica le voci DNS: Confronta tutti i record DNS presenti nel tuo sistema di gestione DNS con le risorse attive nel tuo ambiente. Cerca le voci che puntano a servizi o indirizzi IP inesistenti.
• Verifica delle configurazioni DNS: Utilizzare strumenti come nslookup o dig per interrogare ogni record e verificare che la risorsa corrispondente sia configurata e attiva. Una risposta DNS di per sé non costituisce prova di sicurezza, pertanto è necessario confermare che il dominio di destinazione sia di proprietà della propria organizzazione e da essa gestito attivamente.
• Verifica la presenza di servizi orfani: Verificare la presenza di servizi quali hosting di terze parti, piattaforme cloud o provider CDN che potrebbero essere stati disattivati senza che siano state rimosse le voci DNS associate.

Per la convalida record per record, è anche possibile sottoporre ogni voce a un strumento di verifica dei record DNS per verificare a quale indirizzo è attualmente risolto prima di decidere se mantenerlo.

Perché il rilevamento manuale non funziona su larga scala

Sebbene i metodi manuali siano accurati, sono soggetti a errori umani e possono diventare ingestibili nel caso di domini con configurazioni DNS di grandi dimensioni o complesse. Diversi fattori ne compromettono l’affidabilità ben prima che una zona raggiunga dimensioni considerevoli.

• Proprietà decentralizzata del DNS tra team e reparti
• Ambienti di test e di staging dimenticati che contengono ancora record DNS attivi
• Shadow IT e integrazioni SaaS di terze parti non monitorate
• Risorse cloud scadute che non sono mai state oggetto di un processo formale di dismissione
• Zone DNS multiple ereditate tramite acquisizioni o domini delle controllate
• Documentazione scarsa relativa a un'infrastruttura obsoleta di cui nessuno è attualmente responsabile

Rilevamento automatico

Il monitoraggio automatizzato diventa necessario quando i domini, i sottodomini, i mittenti e i servizi cloud cambiano a un ritmo più rapido rispetto al ciclo di audit. Anziché ricorrere a controlli periodici, una piattaforma centralizzata individua continuamente, nell’intero portafoglio, i record inattivi, le configurazioni di autenticazione non funzionanti e le modifiche sospette.

Il vantaggio pratico risiede nella tempestività piuttosto che nell’approfondimento. Una verifica trimestrale finirà comunque per individuare lo stesso dato, ma lo farà solo dopo un trimestre di esposizione. Il monitoraggio continuo colma quel lasso di tempo che intercorre tra la cessazione del servizio e il controllo successivo, che è proprio il momento in cui si concretizza il rischio di subentro.

Come correggere i record DNS non risolti

Una volta individuato un record "dangling", l'ordine delle operazioni è fondamentale. Cancellare il record prima di recuperare la risorsa può lasciare una finestra aperta, mentre saltare la fase relativa al TTL comporta che la correzione impieghi ore a propagarsi anziché pochi minuti.

1. Identificare il record e la sua destinazione. Utilizzare strumenti DNS o una piattaforma di monitoraggio per individuare la voce specifica e il suo attuale indirizzo di destinazione.
2. Verifica la titolarità del destinatario. Verifica se la tua organizzazione controlla ancora la destinazione interrogando il provider o il registro degli account.
3. Per prima cosa, riduci il valore del TTL. Impostalo tra 60 e 300 secondi prima di apportare modifiche, in modo che gli aggiornamenti si propaghino rapidamente una volta che avrai agito.
4. Recupera la risorsa se è possibile rivendicarla. Se l'obiettivo è un bucket cloud o un endpoint CDN non rivendicato, rivendicalo prima di intervenire sul DNS per chiudere la finestra di acquisizione.
5. Elimina o reindirizza il record. Rimuovilo se il servizio è stato dismesso. Se deve rimanere attivo, reindirizzalo verso una risorsa di cui sei attualmente proprietario e che hai configurato.
6. Verifica la propagazione. Utilizzare dig o nslookup per verificare che il record venga risolto correttamente e che la vecchia destinazione non risponda più.
7. Documentare la modifica. Annotare cosa è cambiato, perché, quando e da chi, quindi aggiornare l'inventario DNS e assegnare la responsabilità a lungo termine.

Come prevenire il dirottamento dei sottodomini causato da record DNS "dangling"

La prevenzione combina le buone pratiche relative al DNS con un monitoraggio continuo. I controlli riportati di seguito rivestono la massima importanza per i team IT, i team di sicurezza e gli MSP che gestiscono più domini.

• Rimuovere immediatamente i record DNS inutilizzati: eliminare i record CNAME, A, AAAA, MX e TXT quando i servizi vengono dismessi, anziché lasciarli attivi per ogni evenienza
• Verifica le destinazioni di terze parti prima di collegarti ad esse: verifica innanzitutto che le risorse cloud, CDN, e-mail e di hosting siano attive e di proprietà della tua organizzazione
• Monitorare i record di autenticazione delle e-mail: verificare regolarmente DMARC, SPF, DKIM, MTA-STS, TLS-RPT e BIMI per individuare eventuali riferimenti inattivi o errati
• Proprietà dei documenti: tenere un inventario di domini, sottodomini, mittenti e titolari dei servizi, indicando un titolare specifico in ogni record
• Incorporare la pulizia del DNS nella procedura di dismissione: rendere la rimozione dei record una fase obbligatoria ogni volta che un servizio cloud, una piattaforma SaaS o un account di hosting viene dismesso
• Imposta avvisi automatici: tieni d'occhio i servizi orfani, le variazioni del DNS e i nuovi sottodomini che compaiono nella tua zona
• Effettuare verifiche periodiche di conformità: mensili o trimestrali a seconda della complessità, e immediatamente dopo ogni migrazione, cambio di provider o acquisizione di dominio

Cosa fare con i sottodomini obsoleti o inutilizzati

Quando un sottodominio non è più necessario, la decisione porta solitamente a uno dei cinque esiti seguenti.

• Elimina il record quando il sottodominio non ha più alcuna giustificazione commerciale
• Recuperare la risorsa esterna abbandonata quando il sottodominio deve rimanere attivo e l'account è ancora rivendicabile
• Parcheggia in sicurezza indirizzandolo verso una risorsa interna controllata, mai verso una piattaforma esterna, quando deve effettuare la risoluzione ma non fornire alcun servizio
• Reindirizzamento solo se sussiste una motivazione aziendale e dopo aver verificato che il sito di destinazione sia di proprietà dell'azienda e attivo
• Documentare documentare ogni decisione e assegnare la responsabilità prima di mettere fuori servizio qualsiasi cosa

Come aiuta PowerDMARC

PowerDMARC centralizza il monitoraggio dell'autenticazione dei domini e delle e-mail, consentendo ai team di individuare eventuali problemi relativi a DMARC, SPF, DKIM, MTA-STS, TLS-RPT e BIMI senza dover controllare manualmente ogni singolo record DNS. L'obiettivo non è individuare un singolo record non valido, ma garantire una visibilità continua su ogni dominio, sottodominio e record di autenticazione che influisce sul vostro livello di sicurezza.

• Pannello di controllo centralizzato: dominio, sottodominio e stato di autenticazione visualizzabili da un'unica schermata
• Rilevamento rapido dei problemi: le configurazioni errate vengono individuate prima che possano compromettere la sicurezza o la deliverability
• Gestione automatizzata dell'SPF: meno errori di ricerca e fonti di invio più pulite man mano che le piattaforme SaaS cambiano
• Preparazione alla conformità: supporto alla preparazione degli audit per i team dei settori finanziario, sanitario, dell'istruzione, della vendita al dettaglio e del settore pubblico
• Assistenza specialistica: assistenza globale per aiutare a indagare, convalidare e correggere rapidamente un record a rischio

Per i fornitori di servizi, il raggruppamento centralizzato dei domini e l’accesso basato sui ruoli rendono pratico il monitoraggio simultaneo di numerosi ambienti client. I programma MSP e MSSP è strutturato proprio intorno a questo flusso di lavoro.

Se vuoi farti un'idea veloce della tua postura attuale, controlla il tuo dominio con l'analizzatore gratuito. Inserisci il tuo dominio, clicca su "Verifica ora" e potrai visualizzare le configurazioni dei tuoi record DNS, gli errori di configurazione rilevati e consigli pratici per risolverli.

Domande frequenti

Questi aspetti riguardano le questioni operative che sorgono una volta chiarito il concetto.

Come si risolvono i record DNS non risolti?

Individua il record obsoleto, verifica se la tua organizzazione possiede ancora l'oggetto di riferimento, quindi riduci il TTL. Se la risorsa è recuperabile, recuperala prima; altrimenti, elimina il record o reindirizzalo, verifica la propagazione con il comando `dig` e documenta la modifica.

Che cos’è un nome host “dangling”?

Un sottodominio che punta a una destinazione non più controllata dal proprietario del dominio. È il record DNS "dangling" a generarlo. Se dev.example.com punta a un account cloud disattivato, si tratta di un nome host "dangling".

I record DNS non risolti possono compromettere la sicurezza della posta elettronica?

Sì. I record DMARC, SPF, DKIM, MTA-STS e TLS-RPT diventano tutti "sospesi" quando fanno riferimento a domini inattivi, mittenti obsoleti o caselle di posta di segnalazione non monitorate. Il risultato sono errori di autenticazione e lacune di visibilità non rilevate.

Con quale frequenza le organizzazioni dovrebbero verificare i record DNS?

Dopo ogni disattivazione del servizio, migrazione del provider, acquisizione di un dominio o cambio di mittente. Aggiungere verifiche periodiche mensili o trimestrali a seconda della complessità, nonché un monitoraggio continuo per individuare eventuali scostamenti tra una verifica e l’altra.

Il fatto che un record sia "dangling" significa sempre che un sottodominio può essere acquisito?

No. L'acquisizione richiede che la risorsa di destinazione sia rivendicabile da qualcun altro, cosa comune nel caso di bucket cloud, endpoint CDN e sottodomini SaaS. Un record che punta a un IP non più attivo comporta comunque interruzioni del servizio e rischi di intercettazione.

A chi dovrebbe spettare internamente la responsabilità della pulizia dei record DNS?

La responsabilità della dismissione dei servizi spetta a chi ne è responsabile, non solo all’amministratore del DNS. I record diventano obsoleti nel momento stesso in cui un servizio viene dismesso, pertanto la loro eliminazione deve rientrare nella checklist di offboarding piuttosto che in una revisione separata del DNS.

• Informazioni su
• Ultimi messaggi

Yunes Tarada

Esperto di sicurezza dei domini e della posta elettronica presso PowerDMARC

Yunes è un Operations Team Lead di PowerDMARC, esperto di autenticazione e sicurezza delle e-mail. Yunes è un Azure Administrator Associate certificato da Microsoft con certificazioni in CompTIA A+ e molte altre.

Ultimi messaggi di Yunes Tarada (vedi tutti)

• Guida alla configurazione di TinkMail: DKIM, DMARC e SPF - 19 agosto 2026
• Guida alla configurazione di DKIM, DMARC e SPF in PandaDoc - 19 agosto 2026
• Guida alla configurazione di DKIM, DMARC e SPF di Moloni - 18 agosto 2026