Il numero di serie cambiaModifica
La porzione di preambolo del trasferimento di zona si basa sul numero di serie, e solo sul numero di serie, per determinare se i dati di una zona sono cambiati, e quindi se è necessario il trasferimento effettivo dei dati. Per alcuni pacchetti di server DNS, i numeri di serie dei record di risorse SOA sono mantenuti dagli amministratori a mano. Ogni modifica al database comporta due cambiamenti, uno al record che viene modificato e l’altro al numero di serie della zona. Il processo richiede precisione: l’amministratore può dimenticare di cambiare il numero di serie o cambiarlo in modo errato (ridurlo). RFC 1912 (sezione 2.2 record SOA) raccomanda di usare il valore YYYYMMDDnn come numero (YYYY=anno, MM=mese, DD=giorno, nn=numero di revisione). Questo non traboccherà fino all’anno 4294.
Alcuni pacchetti di server DNS hanno superato questo problema costruendo automaticamente il numero di serie dal timestamp dell’ultima modifica del file di database su disco. Questo è il caso di djbdns, per esempio. Il sistema operativo assicura che il timestamp dell’ultima modifica sia aggiornato ogni volta che un amministratore modifica il file del database, aggiornando automaticamente il numero di serie, e quindi sollevando gli amministratori dalla necessità di fare due modifiche (in due posti diversi) per ogni singolo cambiamento.
Inoltre, il paradigma della replica del database per cui il controllo del numero di serie (e in effetti il trasferimento di zona stesso) è progettato, che coinvolge un singolo server DNS centrale che tiene la versione primaria del database con tutti gli altri server DNS che ne tengono semplicemente delle copie, semplicemente non corrisponde a quello di molti moderni pacchetti server DNS. I moderni pacchetti di server DNS con back-end di database sofisticati come i server SQL e Active Directory permettono agli amministratori di fare aggiornamenti al database in più posti (tali sistemi impiegano la replica multi-master), con il meccanismo di replica del back-end del database che gestisce la replica a tutti gli altri server. Questo paradigma semplicemente non corrisponde a quello di un singolo, centrale, monotonicamente crescente numero per registrare i cambiamenti, e quindi è incompatibile con il trasferimento di zona in larga misura. I moderni pacchetti di server DNS con sofisticati back-end di database spesso creano un numero di serie “shim”, simulando l’esistenza di un unico luogo centrale in cui vengono effettuati gli aggiornamenti, ma questo è al meglio imperfetto.
Fortunatamente, per questo e per diverse ragioni descritte più avanti, i server DNS che usano tali sofisticati database back-end in generale raramente usano il trasferimento di zona come meccanismo di replica del loro database, e di solito invece impiegano i meccanismi di replica del database distribuito di gran lunga superiori che i back-end stessi forniscono.
Confronti di numeri serialiModifica
I confronti dei numeri seriali sono intesi per usare l’aritmetica dei numeri seriali come definita in RFC 1982. Tuttavia, questo non è stato chiaramente specificato in RFC 1034, con il risultato che non tutti i client eseguono il controllo del numero di serie, nel preambolo, nello stesso modo. Alcuni client controllano semplicemente che il numero di serie fornito dal server sia diverso da quello conosciuto dal client, o non nullo. Altri client controllano che il numero di serie fornito dal server sia all’interno di un dato intervallo del numero di serie già conosciuto dal client. Altri client ancora eseguono quest’ultimo controllo e inoltre controllano che il numero di serie fornito dal server non sia zero.
Record di risorse multipleModifica
In origine, nel trasferimento effettivo dei dati ogni set di record di risorse per un singolo nome di dominio e tipo veniva trasferito in un messaggio di risposta separato dal server al client. Tuttavia, questo è inefficiente, e alcuni software di server DNS hanno implementato ottimizzazioni, orientate a consentire il meccanismo di compressione della risposta nel protocollo DNS per ridurre i requisiti di larghezza di banda totale dei trasferimenti di dati, come ad esempio:
- effettuare “l’elaborazione di sezioni aggiuntive” per includere qualsiasi set di record di risorse “colla” nella stessa risposta di un set di record di risorse NS, SRV o MX
- raccogliere tutti i set di record di risorse relativi a un singolo nome di dominio insieme e inviarli, se vanno bene, in una singola risposta
Alcuni client sono stati scritti per aspettarsi solo il formato di risposta originale, e non riuscirebbero a eseguire il trasferimento dei dati se tali ottimizzazioni fossero impiegate. Diversi pacchetti di server DNS hanno quindi un’impostazione di configurazione che permette agli amministratori di specificare l’uso di risposte in “formato risposta singola” per quei client che lo richiedono.
Esposizione dei datiModifica
I dati contenuti in una zona DNS possono essere sensibili dal punto di vista della sicurezza operativa. Questo perché informazioni come gli hostname dei server possono diventare di dominio pubblico, il che può essere utilizzato per scoprire informazioni su un’organizzazione e persino fornire una superficie di attacco più ampia. Nel giugno 2017 la società di registrazione responsabile dei domini di primo livello russi ha accidentalmente abilitato i trasferimenti di zona DNS tramite AXFR, il che ha portato all’esposizione accidentale di 5,6 milioni di record.
Nel 2008 un tribunale del North Dakota, USA, ha stabilito che eseguire un trasferimento di zona come estraneo non autorizzato per ottenere informazioni non pubblicamente accessibili costituisce una violazione della legge del North Dakota.