Che cos’è il trasferimento di zona DNS e perché rappresenta una vulnerabilità di sicurezza?

La ridondanza è la colonna portante del Sistema dei nomi di dominio (DNS). Se un server dei nomi autorevole si disconnette o diventa irraggiungibile, i server di backup devono essere pronti a risolvere le richieste relative al proprio dominio senza interruzioni. Per mantenere sincronizzati questi server secondari, il DNS si avvale dei trasferimenti di zona per replicare automaticamente i record.

Se configurati correttamente, i trasferimenti di zona avvengono in modo trasparente tra server affidabili. Tuttavia, una singola impostazione predefinita o una svista nel controllo degli accessi può rendere questo canale di replica accessibile a tutta la rete Internet. Quando ciò accade, una semplice misura amministrativa volta a facilitare il lavoro si trasforma in una vera e propria fuga di informazioni.

Questa guida illustra cosa sono i trasferimenti di zona DNS, le differenze operative tra AXFR e IXFR, perché i trasferimenti aperti rappresentano un grave rischio per la sicurezza e come proteggere i propri server dei nomi da attività di ricognizione non autorizzate.

Che cos’è un trasferimento di zona DNS?

Un trasferimento di zona DNS consiste nella replica di un file di zona da un server dei nomi primario autoritativo a uno o più server dei nomi secondari tramite la porta TCP 53. Ciò garantisce che i server dei nomi secondari dispongano di copie identiche di tutti i record di risorse necessari per rispondere in modo autorevole alle richieste dei client.

Per comprendere il motivo di questa replica, occorre considerare il funzionamento del DNS autoritativo. Una zona DNS rappresenta uno spazio amministrativo distinto all’interno della gerarchia globale dei domini. Il file di zona contiene il catalogo completo dei record di risorse che definiscono tale spazio, inclusi i record di mappatura degli indirizzi (record A e AAAA), i server di posta (record MX), le posizioni dei servizi (record SRV) e le stringhe di convalida (record TXT).

Affidarsi a un unico server dei nomi crea un punto di guasto unico inaccettabile. Se quel server subisce un guasto hardware, una congestione di rete o interruzioni dovute ad attacchi DDoS (Distributed Denial of Service), i visitatori non potranno risolvere il tuo dominio.

Per evitare tempi di inattività, le organizzazioni implementano server dei nomi secondari. La gestione manuale di questi server risulterebbe inefficiente e soggetta a errori, poiché gli amministratori dovrebbero replicare ogni modifica ai record su più host. I trasferimenti di zona DNS automatizzano questo processo, consentendo ai server secondari di recuperare i dati aggiornati della zona direttamente dall’host principale. Ciò garantisce un’elevata disponibilità e bilancia il volume delle query tra server dei nomi geograficamente dispersi.

Come funzionano i trasferimenti di zone DNS

I trasferimenti di zona DNS seguono un'architettura client-server in cui il server dei nomi secondario funge da client che richiede i dati, mentre il server dei nomi primario funge da server che li fornisce.

Le query DNS standard effettuate dai browser web utilizzano in genere la porta 53 del protocollo UDP (User Datagram Protocol) per garantire velocità e un basso overhead. Al contrario, i trasferimenti di zona avvengono sulla porta 53 del protocollo TCP (Transmission Control Protocol). Il protocollo TCP garantisce la connessione affidabile e con stato, nonché il controllo degli errori necessari per trasmettere grandi volumi di dati strutturati senza perdita di pacchetti.

Il processo di sincronizzazione si basa sul record Start of Authority (SOA), in particolare sul campo relativo al numero di serie:

1. Confronto dei numeri di serie: Il server dei nomi secondario interroga regolarmente il server primario per ottenere il suo record SOA. In alternativa, quando un amministratore aggiorna una zona, il server dei nomi primario può inviare un messaggio DNS NOTIFY non richiesto (RFC 1996) per avvisare i server secondari dell'aggiornamento.
2. Decisione di trasferimento: Il server secondario confronta il numero di serie del server primario con la propria copia locale. Se il numero di serie del server primario è più alto, il server secondario capisce che i record sono stati modificati e avvia una richiesta di trasferimento.
3. Trasmissione dei dati: Il server principale convalida la richiesta e trasmette i record aggiornati tramite la connessione TCP stabilita.

A seconda della configurazione e del volume delle modifiche, i server eseguono questa sincronizzazione utilizzando uno dei due metodi: AXFR o IXFR.

AXFR (trasferimento completo di zona)

Il trasferimento autorevole (AXFR), definito nella RFC 1035 e aggiornato nella RFC 5936, rappresenta il meccanismo di trasferimento originale. Quando viene eseguita una richiesta AXFR, il server dei nomi primario invia l'intero file di zona dall'inizio alla fine, a partire dal record SOA e terminando con esso.

Sebbene sia semplice e affidabile, il protocollo AXFR risulta inefficiente per le zone di grandi dimensioni. Se un’azienda gestisce una zona contenente 50.000 record di risorse e modifica un singolo indirizzo IP, un trasferimento AXFR ritrasmette tutti i 50.000 record. Nelle reti ad alto volume, i ripetuti trasferimenti completi consumano inutilmente larghezza di banda di rete e cicli di elaborazione.

IXFR (Trasferimento incrementale per zone)

Per eliminare il sovraccarico dovuto ai trasferimenti completi, la RFC 1995 ha introdotto il trasferimento incrementale delle zone (IXFR). Anziché copiare l'intero database, l'IXFR invia solo le differenze specifiche tra la versione corrente del server secondario e quella aggiornata del server primario.

Durante uno scambio IXFR, il server secondario invia nella propria richiesta il numero di serie SOA corrente. Il server primario analizza il proprio registro delle modifiche, individua quali record sono stati eliminati e aggiunti nelle versioni intermedie e trasmette solo tali differenze. Ciò riduce drasticamente il consumo di larghezza di banda e accelera la sincronizzazione nelle architetture distribuite.

Confronto tra AXFR e IXFR

Se un server secondario è rimasto offline per un periodo prolungato e il suo numero di serie non rientra nella cronologia delle transazioni del server primario, IXFR non è in grado di colmare tale lacuna. In tale scenario, il sistema ricorre in modo controllato a un trasferimento AXFR completo per ricostruire la zona.

Perché i trasferimenti in zona aperta rappresentano una vulnerabilità di sicurezza

I trasferimenti di zona sono fondamentali per la sincronizzazione amministrativa, ma sono stati progettati tenendo conto della disponibilità piuttosto che della riservatezza. Per impostazione predefinita, le configurazioni dei server dei nomi di vecchia generazione spesso consideravano legittima qualsiasi query AXFR in entrata.

Si verifica un trasferimento di zona aperto quando un server dei nomi autorevole risponde a richieste AXFR provenienti da indirizzi IP non autorizzati. In presenza di questa configurazione errata, chiunque sia connesso a Internet può interrogare il server dei nomi e ricevere una copia completa del file di zona.

Questa vulnerabilità comporta una grave esposizione di informazioni. Anziché ricorrere a metodi di forza bruta basati su tentativi ed errori, un malintenzionato ottiene un inventario autorizzato e strutturato dell’impronta digitale di un’organizzazione. Ciò trasforma una fase di ricognizione manuale in un’individuazione istantanea ed esaustiva del sistema. I trasferimenti di zona aperti rimangono una delle vulnerabilità DNS più documentate vulnerabilità DNS più comuni , poiché espongono al pubblico i piani operativi interni.

Cosa imparano gli hacker da un trasferimento di zona

Quando un autore di attacchi ottiene un file di zona tramite una query AXFR aperta, acquisisce l'accesso a dati che raramente sono visibili tramite le normali query DNS:

• Elenchi completi dei sottodomini: Gli aggressori individuano tutti i sottodomini registrati, compresi gli host che prendono il nome da funzioni interne, reparti o tecnologie proprietarie.
• Host di sviluppo e staging: I sottodomini come dev.example.com, test-api.example.com o qa-vpn.example.com eseguono spesso software in fase di pre-rilascio che non dispone di firewall di livello produttivo, patch di sicurezza aggiornate o controlli di accesso rigorosi.
• Portali amministrativi e remoti: I collegamenti alla rete intranet, i portali dei dipendenti, i punti di terminazione VPN e le interfacce di gestione dei database compaiono spesso direttamente nell'elenco dei record.
• Architettura di posta e instradamento: I record MX e i corrispondenti indirizzi IP degli host di posta rivelano la topologia di filtraggio della posta elettronica di un'organizzazione, i salti di instradamento e i servizi di consegna di terze parti.
• Dati di verifica di terze parti: I record TXT non sottoposti a revisione spesso contengono token di verifica per piattaforme cloud, integrazioni SaaS, strumenti di analisi e stringhe di verifica storiche che forniscono indicazioni sulle dipendenze dell’infrastruttura interna.

In che modo una falla nel trasferimento di zona favorisce altri attacchi

Le informazioni ottenute tramite un trasferimento di zona aperto fungono da trampolino di lancio operativo per sofisticati attacchi successivi:

• Conquista dei sottodomini: I file di zona contengono spesso record CNAME "sospesi" che puntano a risorse cloud dismesse, come bucket Amazon S3 abbandonati, GitHub Pages o istanze Microsoft Azure. Grazie a un elenco completo dei record CNAME, gli aggressori possono appropriarsi della risorsa orfana presso il provider di terze parti e pubblicare contenuti non autorizzati sotto il dominio verificato della vittima.
• Spear phishing e ingegneria sociale: Scoprire le convenzioni di denominazione dei server interni, gli indirizzi dei portali dei dipendenti e i rapporti con i fornitori consente agli aggressori di creare esche di ingegneria sociale altamente credibili. Quando gli autori delle minacce fanno riferimento a nomi host interni reali in un’e-mail mirata, i destinatari sono significativamente più propensi a fidarsi della comunicazione. Per capire come gli avversari sfruttano le informazioni sull’infrastruttura per la raccolta mirata delle credenziali, leggi la nostra analisi su spear phishing.
• Superfici di attacco ampliate: I trasferimenti di zona spesso espongono gli schemi di indirizzamento IP interni quando le reti private vengono accidentalmente integrate nelle zone pubbliche. Ciò fornisce agli aggressori i dettagli di routing necessari per sondare i firewall perimetrali e prendere di mira le interfacce amministrative interne.

Inoltre, sebbene i trasferimenti di zona di per sé non manipolino il traffico, la comprensione della topologia di caching e di routing di un’azienda può facilitare attacchi secondari quali l’avvelenamento della cache DNS.

Come verificare se il proprio dominio consente i trasferimenti di zona

Gli amministratori della sicurezza devono verificare se i server dei nomi autoritativi consentono trasferimenti di zona non autorizzati. L'obiettivo è confermare che le query esterne che richiedono copie complete della zona ricevano un rifiuto esplicito anziché i record completi.

Gli amministratori valutano questa situazione avviando una query AXFR da una postazione di rete esterna e non attendibile, indirizzata a ciascun server dei nomi autorevole elencato nei record NS del dominio:

• Comportamento sicuro: Il server dei nomi rifiuta immediatamente la richiesta, restituendo uno stato REFUSED o SERVFAIL. Non viene trasmesso alcun record di zona.
• Comportamento vulnerabile: Il server dei nomi accetta la connessione, conferma la richiesta AXFR e restituisce in streaming l'elenco completo dei record di risorse del dominio.

Oltre ai controlli periodici a campione, gli ambienti aziendali traggono vantaggio dalla sorveglianza automatizzata. I controlli automatici della configurazione individuano i casi in cui gli aggiornamenti dei server dei nomi rimuovono inavvertitamente le restrizioni di trasferimento. 

PowerDMARC include controlli automatici sull'esposizione AXFR all'interno del suo suite di monitoraggio della sicurezza DNS , avvisando gli amministratori nel momento stesso in cui un server autorevole inizia a rispondere a richieste pubbliche di trasferimento di zona.

Come proteggere i trasferimenti di zone DNS

Per proteggere il proprio dominio dai trasferimenti di zona non autorizzati è necessario implementare rigide restrizioni di accesso e moderni controlli crittografici. In linea con le linee guida ufficiali del NIST sulla sicurezza del DNS si pone una base di riferimento affidabile per l’integrità del dominio.

Implementare i seguenti controlli di sicurezza nell'intera infrastruttura DNS:

1. Limitare i trasferimenti in base all'indirizzo IP: Non consentire mai query AXFR o IXFR senza restrizioni. Dichiarare esplicitamente gli indirizzi IP dei server dei nomi secondari autorizzati all’interno dei blocchi di configurazione dei server dei nomi (ad esempio tramite la direttiva allow-transfer di BIND) e rifiutare tutte le richieste provenienti da indirizzi non presenti in tale lista bianca.
2. Autenticazione tramite TSIG: Limitare l'accesso esclusivamente in base all'indirizzo IP offre una protezione di base, ma in determinate topologie di rete gli indirizzi IP possono essere falsificati. Implementare le firme di transazione (TSIG) per autenticare la comunicazione tra i server dei nomi utilizzando segreti crittografici condivisi.
3. Disattivare i trasferimenti sui sistemi autonomi: Se il tuo dominio si affida a un unico server dei nomi o utilizza un moderno provider DNS gestito che si sincronizza tramite backplane API proprietari, disabilita completamente i trasferimenti di zona.
4. Implementare il DNS a orizzonte diviso: Mantenere file di zona separati per le reti aziendali interne e i servizi pubblici esterni. I nomi host interni, gli ambienti di test e i sottodomini di staging non devono mai trovarsi in un file di zona accessibile al pubblico.
5. Mantenere aggiornati i daemon dei server dei nomi: Le vulnerabilità nel software DNS possono consentire agli aggressori di aggirare le regole ACL o provocare l'esaurimento delle risorse. Utilizzate versioni aggiornate e corrette del software server come BIND, PowerDNS, Knot DNS o NSD per ridurre al minimo l'esposizione alle vulnerabilità zero-day e agli gli attacchi di amplificazione DNS.
6. Registrazione e avvisi relativi alle richieste di trasferimento: Monitorare i log delle query dei server dei nomi alla ricerca di richieste AXFR o IXFR non autorizzate. Tentativi ripetuti di trasferimento provenienti da indirizzi IP sconosciuti indicano spesso un'attività di ricognizione da parte di malintenzionati.
7. Eseguire regolarmente la verifica dei record di zona: Esaminate regolarmente i vostri file di zona per individuare ed eliminare i record obsoleti, in particolare le voci CNAME non aggiornate che puntano a risorse di hosting cloud di terze parti scadute.

Autenticazione dei trasferimenti con TSIG e crittografia con XoT

Le firme delle transazioni (TSIG), standardizzate nella RFC 2845 e riviste nella RFC 8945, aggiungono l'autenticazione crittografica alla messaggistica DNS. Il protocollo TSIG si basa su segreti simmetrici condivisi stabiliti tra i server dei nomi primario e secondario.

Una volta configurato, il server dei nomi secondario firma la propria richiesta AXFR o IXFR con un hash crittografico derivato dalla chiave condivisa e dal timestamp corrente. Il server dei nomi primario verifica la validità della firma utilizzando la propria chiave. Se la firma corrisponde e rientra in un intervallo di tempo accettabile, il trasferimento procede; se la chiave manca o non è valida, il server primario rifiuta la connessione.

Sebbene il TSIG attesti l’identità e garantisca l’integrità dei dati, non crittografa il contenuto della zona stesso durante il transito. Per colmare questa lacuna in materia di riservatezza, l’Internet Engineering Task Force (IETF) ha pubblicato la RFC 9103, che specifica il trasferimento di zone DNS su TLS (XoT). XoT racchiude le sessioni AXFR e IXFR all’interno di un tunnel crittografato Transport Layer Security (TLS), impedendo intercettazioni, attacchi man-in-the-middle e manomissioni sulle reti di transito.

Monitoraggio dell'esposizione al trasferimento di zona con PowerDMARC

Per garantire la sicurezza dell'infrastruttura dei server dei nomi sono necessarie sia configurazioni difensive dei server sia una monitorabilità esterna continua. Mentre i team responsabili dell'infrastruttura gestiscono gli elenchi di accesso alle zone, gli analisti della sicurezza devono disporre di una visibilità continua per garantire che errori amministrativi o migrazioni al cloud non espongano in modo impercettibile i record.

PowerDMARC integra un sistema dedicato al rilevamento delle vulnerabilità AXFR nelle sue complete migliori soluzioni di sicurezza DNS .

Concepito come piattaforma di monitoraggio dei record DNS esterni e di conformità alle norme di sicurezza, piuttosto che come proxy di filtraggio in linea o firewall, il servizio DNS Security Monitoring & Compliance di PowerDMARC esegue controlli automatici sui vostri server dei nomi autoritativi:

• Controlli di esposizione AXFR: Esegue test continui sui server dei nomi autoritativi da postazioni esterne per verificare che i trasferimenti di zona non autorizzati vengano bloccati.
• Registrazione dei log di audit per le perdite di zona: Segnala e registra immediatamente i casi in cui un server dei nomi secondario o primario consenta erroneamente il trasferimento di dati AXFR.
• Rilevamento delle modifiche ai record: Monitora i movimenti seriali SOA e tiene traccia di aggiunte, modifiche o cancellazioni nei record delle risorse pubbliche.
• Verifica della sincronizzazione dei server dei nomi: Verifica che i server dei nomi secondari contengano record identici e sincronizzati rispetto alle autorità primarie.
• DNSSEC e supervisione dei record CNAME "dangling": Avvisa gli amministratori in caso di catene DNSSEC interrotte e identifica i record CNAME obsoleti prima che possano essere sfruttati per il controllo dei sottodomini.

La combinazione di rigorosi controlli di accesso ai server dei nomi con un monitoraggio continuo e automatizzato dei record garantisce che la topologia DNS rimanga riservata, resiliente e conforme agli standard di sicurezza aziendali.

Domande frequenti

Qual è lo scopo di un trasferimento di zona DNS?

Un trasferimento di zona DNS replica i dati della zona da un server dei nomi autorevole primario ai server dei nomi secondari tramite la porta TCP 53. Questa replica garantisce alta disponibilità, bilanciamento del carico e tolleranza ai guasti nelle reti distribuite, prevenendo errori di risoluzione dei domini nel caso in cui il server primario non fosse disponibile.

Qual è la differenza tra AXFR e IXFR?

AXFR esegue un trasferimento completo della zona, trasmettendo l'intero file di zona e tutti i record di risorse associati, indipendentemente dal fatto che siano state apportate modifiche. IXFR esegue un trasferimento incrementale, trasmettendo solo le aggiunte e le eliminazioni specifiche dei record avvenute a partire dall'ultimo numero seriale sincronizzato del server secondario.

Il trasferimento di una zona DNS costituisce un attacco?

No, un trasferimento di zona è un meccanismo amministrativo standard definito dagli standard di Internet. Si configura come incidente di sicurezza solo quando un server dei nomi autorevole è configurato in modo errato, consentendo trasferimenti AXFR aperti e senza restrizioni a client pubblici non autorizzati, permettendo così agli aggressori di scaricare la mappa completa dell’infrastruttura di dominio di un’organizzazione.

Quale porta utilizza un trasferimento di zona?

I trasferimenti di zona utilizzano la porta TCP 53. Mentre le ricerche DNS ricorsive standard si avvalgono della porta UDP 53 per garantire maggiore velocità, i trasferimenti di zona richiedono il protocollo TCP per stabilire una connessione affidabile in grado di trasmettere record di zona di grandi dimensioni, composti da più pacchetti, senza troncamento dei dati né perdita di pacchetti.

Che cos’è il TSIG e in che modo garantisce la sicurezza dei trasferimenti di zona?

Il TSIG (Transaction Signatures) è un meccanismo di autenticazione DNS definito nella RFC 8945. Utilizza chiavi crittografiche simmetriche condivise per firmare le richieste e le risposte relative al trasferimento di zona, garantendo che i server dei nomi primari e secondari si autenticino reciprocamente e verifichino l'integrità dei dati prima di trasmettere i record di zona.

I provider di servizi DNS gestiti consentono i trasferimenti di zona?

La maggior parte dei moderni provider di servizi DNS gestiti su cloud disabilita per impostazione predefinita i tradizionali trasferimenti AXFR pubblici, utilizzando API proprietarie e reti anycast interne per replicare i record. Tuttavia, alcuni provider cloud offrono configurazioni AXFR opzionali e sicure per supportare ambienti ibridi quando si collegano server dei nomi secondari esterni personalizzati.

Parole finali

I trasferimenti di zona DNS sono fondamentali per garantire la disponibilità continua della rete e una risoluzione affidabile dei domini. Tuttavia, se non vengono soggetti ad alcuna restrizione, diventano una porta aperta sulla rete aziendale, fornendo agli autori delle minacce un elenco dettagliato di sottodomini, portali amministrativi e ambienti di test dimenticati.

Per garantire la sicurezza dei trasferimenti di zona non è necessario rinunciare alla ridondanza. Limitando i trasferimenti agli indirizzi IP secondari autorizzati, autenticando gli scambi con chiavi TSIG, crittografando le sessioni con XoT e mantenendo una rigorosa “igiene” delle zone, è possibile proteggere le proprie risorse di denominazione senza compromettere la disponibilità.

Fai oggi stesso il primo passo per mettere in sicurezza la tua infrastruttura di dominio: utilizza il nostro Domain Analyzer gratuito per verificare lo stato di salute del tuo DNS pubblico, oppure implementa il monitoraggio della sicurezza DNS di PowerDMARC per proteggere la tua infrastruttura da esposizioni non autorizzate.