SeriennummernänderungenBearbeiten
Der Präambelteil des Zonentransfers stützt sich auf die Seriennummer, und nur auf die Seriennummer, um festzustellen, ob sich die Daten einer Zone geändert haben und somit die eigentliche Datenübertragung erforderlich ist. Bei einigen DNS-Serverpaketen werden die Seriennummern der SOA-Ressourcendatensätze von den Administratoren von Hand gepflegt. Bei jeder Bearbeitung der Datenbank müssen zwei Änderungen vorgenommen werden, eine an dem zu ändernden Datensatz und die andere an der Zonenseriennummer. Der Prozess erfordert Genauigkeit: Der Administrator kann vergessen, die Seriennummer zu ändern, oder sie falsch ändern (sie reduzieren). RFC 1912 (Abschnitt 2.2 SOA-Datensätze) empfiehlt die Verwendung des Wertes JJJJMMTTnn als Nummer (JJJJ=Jahr, MM=Monat, TT=Tag, nn=Revisionsnummer). Dies führt erst im Jahr 4294 zu einem Überlauf.
Einige DNS-Serverpakete haben dieses Problem gelöst, indem sie die Seriennummer automatisch aus dem Zeitstempel der letzten Änderung der Datenbankdatei auf der Festplatte konstruieren. Dies ist zum Beispiel bei djbdns der Fall. Das Betriebssystem stellt sicher, dass der Zeitstempel der letzten Änderung immer dann aktualisiert wird, wenn ein Administrator die Datenbankdatei bearbeitet, so dass die Seriennummer automatisch aktualisiert wird und die Administratoren nicht für jede einzelne Änderung zwei Änderungen (an zwei verschiedenen Stellen) vornehmen müssen.
Außerdem entspricht das Paradigma der Datenbankreplikation, für das die Überprüfung der Seriennummer (und der Zonentransfer selbst) entwickelt wurde, bei dem ein einziger zentraler DNS-Server die primäre Version der Datenbank hält und alle anderen DNS-Server lediglich Kopien davon haben, einfach nicht dem vieler moderner DNS-Serverpakete. Moderne DNS-Serverpakete mit hochentwickelten Datenbank-Backends wie SQL-Servern und Active Directory ermöglichen es den Administratoren, Aktualisierungen der Datenbank an mehreren Stellen vorzunehmen (solche Systeme verwenden Multi-Master-Replikation), wobei der eigene Replikationsmechanismus des Datenbank-Backends die Replikation auf alle anderen Server übernimmt. Dieses Paradigma passt einfach nicht zu dem einer einzigen, zentralen, monoton ansteigenden Zahl von Änderungen und ist daher mit der Zonenübertragung weitgehend unvereinbar. Moderne DNS-Serverpakete mit ausgefeilten Datenbank-Backends erzeugen oft eine „Shim“-Seriennummer, die die Existenz einer einzigen zentralen Stelle simuliert, an der Aktualisierungen vorgenommen werden, aber das ist bestenfalls unvollkommen.
Glücklicherweise verwenden DNS-Server, die solche ausgefeilten Datenbank-Backends verwenden, aus diesem und mehreren später dargelegten Gründen im Allgemeinen selten den Zonentransfer als ihren Datenbankreplikationsmechanismus und setzen stattdessen die weitaus besseren verteilten Datenbankreplikationsmechanismen ein, die die Backends selbst bereitstellen.
SeriennummernvergleicheEdit
Seriennummernvergleiche sollen die in RFC 1982 definierte Seriennummernarithmetik verwenden. Dies wurde jedoch in RFC 1034 nicht eindeutig spezifiziert, was dazu führt, dass nicht alle Clients die Überprüfung der Seriennummer in der Präambel auf dieselbe Weise durchführen. Einige Clients prüfen lediglich, ob sich die vom Server gelieferte Seriennummer von der dem Client bekannten Seriennummer unterscheidet oder ungleich Null ist. Andere Clients prüfen, ob die vom Server gelieferte Seriennummer innerhalb eines bestimmten Bereichs der dem Client bereits bekannten Seriennummer liegt. Wieder andere Clients führen die letztgenannte Prüfung durch und prüfen zusätzlich, dass die vom Server gelieferte Seriennummer nicht Null ist.
Mehrere RessourcendatensätzeBearbeiten
Ursprünglich wurde bei der eigentlichen Datenübertragung jeder Satz von Ressourcendatensätzen für einen einzelnen Domänennamen und Typ in einer separaten Antwortnachricht vom Server an den Client übertragen. Dies ist jedoch ineffizient, und einige DNS-Server-Software hat Optimierungen implementiert, die darauf abzielen, dass der Antwortkompressionsmechanismus im DNS-Protokoll die Gesamtbandbreitenanforderungen der Datenübertragungen reduziert, wie z. B.:
- Durchführen einer „zusätzlichen Abschnittsverarbeitung“, um alle „Glue“-Ressourcendatensätze in dieselbe Antwort wie einen NS-, SRV- oder MX-Ressourcendatensatz einzuschließen
- Sammeln aller Ressourcendatensätze, die sich auf einen einzigen Domänennamen beziehen, und Senden dieser Datensätze, wenn sie in eine einzige Antwort passen
Einige Clients wurden so geschrieben, dass sie nur das ursprüngliche Antwortformat erwarten, und würden die Datenübertragung nicht durchführen, wenn solche Optimierungen verwendet werden. Mehrere DNS-Serverpakete verfügen daher über eine Konfigurationseinstellung, die es Administratoren ermöglicht, die Verwendung von Antworten im „Einzelantwortformat“ für diejenigen Clients festzulegen, die dies benötigen.
Offenlegung von DatenBearbeiten
Die in einer DNS-Zone enthaltenen Daten können unter dem Aspekt der Betriebssicherheit sensibel sein. Dies liegt daran, dass Informationen wie die Hostnamen von Servern öffentlich bekannt werden können, was dazu genutzt werden kann, Informationen über eine Organisation zu ermitteln und sogar eine größere Angriffsfläche zu bieten. Im Juni 2017 aktivierte die für russische Top-Level-Domains zuständige Registrierstelle versehentlich DNS-Zonentransfers über AXFR, was dazu führte, dass 5,6 Millionen Datensätze versehentlich offengelegt wurden.
Im Jahr 2008 entschied ein Gericht in North Dakota, USA, dass die Durchführung eines Zonentransfers als unbefugter Außenstehender, um Informationen zu erhalten, die nicht öffentlich zugänglich sind, eine Verletzung des Gesetzes von North Dakota darstellt.