Zonentransfer

Was ist ein DNS Zonentransfer?

Ein DNS Zonentransfer ist ein Mechanismus, um eine vollständige oder inkrementelle Kopie einer DNS-Zone von einem autoritativen Nameserver auf einen anderen zu übertragen. Er stellt die zentrale Technik zur Replikation von DNS-Daten zwischen Primary und Secondary Nameservern dar. Auf diese Weise halten Sekundärserver ihre Datenbestände synchron, ohne dass ein Administrator die Zonendateien manuell kopieren muss. Zonentransfers sichern die Ausfallsicherheit und Lastverteilung des Domain Name Systems und werden über TCP abgewickelt, sobald die zu übertragende Datenmenge die Größe eines einzelnen UDP-Pakets überschreitet.

Primary und Secondary Nameserver

Das Konzept des Zonentransfers setzt eine klare Rollenverteilung voraus. Der Primary Nameserver, auch Master genannt, hält die maßgebliche, vom Administrator gepflegte Version der Zone. Er ist die Quelle der Wahrheit für alle Resource Records dieser Domain. Secondary Nameserver, auch Slaves, beziehen ihre Daten ausschließlich vom Primary und geben sie als autoritative Antworten an Clients weiter. Änderungen an den Zonendaten erfolgen ausschließlich auf dem Primary. Die Secondary holen sich die aktualisierten Daten per Zonentransfer ab. Ein Secondary kann gleichzeitig als Primary für weitere Server dienen, was kaskadierte Replikationsstrukturen ermöglicht.

Vollständiger Zonentransfer (AXFR)

AXFR steht für Authoritative Transfer und bezeichnet den vollständigen Zonentransfer. Bei einem AXFR-Request fordert der Secondary die gesamte Zone vom Primary an. Der Primary sendet sämtliche Resource Records in einer oder mehreren TCP-Nachrichten, gefolgt von einer abschließenden Wiederholung des SOA-Records (Start of Authority), der das Ende der Übertragung signalisiert.

Der Ablauf beginnt mit einer SOA-Abfrage durch den Secondary, um die Seriennummer der Zone zu prüfen. Ist die Seriennummer des Primary höher als die lokal gespeicherte, initiiert der Secondary einen AXFR-Request per TCP auf Port 53. Der Primary streamt die Zone als Sequenz von DNS-Nachrichten, die jeweils mehrere Resource Records enthalten können. Nach dem letzten Record wiederholt der Primary den SOA, um die Vollständigkeit zu bestätigen. Der Secondary baut aus den empfangenen Daten seine lokale Zonendatei auf und beantwortet fortan Anfragen mit dem aktualisierten Stand.

Inkrementeller Zonentransfer (IXFR)

IXFR steht für Incremental Zone Transfer und wurde mit RFC 1995 eingeführt. Statt der gesamten Zone überträgt der Primary nur die seit der letzten Synchronisation geänderten Resource Records. Dazu vergleicht der Primary zwei Versionen der Zone anhand ihrer Seriennummern und ermittelt die gelöschten und hinzugefügten Records. Die Übertragung enthält pro geänderter Resource Record Group eine alte und eine neue Version, sodass der Secondary die Änderungen sequentiell anwenden kann.

Voraussetzung ist, dass der Primary die Historie der Zonenänderungen vorhält und die angefragte ältere Seriennummer noch in seinem Journal verfügbar ist. Ist dies nicht der Fall, lehnt der Primary den IXFR-Request ab und bietet stattdessen einen vollständigen AXFR an. IXFR reduziert die übertragene Datenmenge und die CPU-Last auf beiden Seiten erheblich und ist insbesondere bei großen Zonen mit wenigen Änderungen die bevorzugte Methode.

Technische Details der Übertragung

Zonentransfers verwenden DNS-Nachrichten im Standardformat, jedoch mit einem speziellen Query-Type im Frage-Teil. Der Secondary sendet eine Anfrage mit QTYPE AXFR (Code 252) für den vollständigen oder IXFR (Code 251) für den inkrementellen Transfer. Die Antworten werden über TCP übertragen, da UDP auf eine maximale Paketgröße von 512 Byte ohne EDNS beschränkt ist und Zonen diese Grenze fast immer überschreiten.

Die TCP-Verbindung wird mit einem Drei-Wege-Handshake auf Port 53 aufgebaut. Der Secondary sendet die Transferanforderung, der Primary antwortet mit einem oder mehreren DNS-Paketen. Jedes Paket beginnt mit einem 2-Byte-Längenfeld, das die Größe des folgenden DNS-Pakets angibt. Dies erlaubt dem Empfänger, die TCP-Segmente korrekt zu den DNS-Nachrichten zusammenzufügen. Nach Abschluss der Übertragung wird die TCP-Verbindung geschlossen. Während des gesamten Transfers bleibt die Verbindung exklusiv für diese eine Zone bestehen.

Die Rolle des SOA-Records

Der SOA-Record (Start of Authority) spielt eine zentrale Rolle beim Zonentransfer. Er enthält unter anderem die Seriennummer der Zone, die E-Mail-Adresse des Administrators sowie mehrere Timer für die Steuerung der Synchronisation.

• Seriennummer: Eine monoton steigende Zahl, die der Administrator bei jeder Änderung manuell erhöht. Moderne Systeme verwenden Datums- und Uhrzeitformate wie YYYYMMDDNN. Der Secondary vergleicht seine lokale Seriennummer mit der des Primary und löst nur bei einer höheren Nummer einen Transfer aus.
• Refresh: Der Zeitabstand in Sekunden, nach dem der Secondary die Seriennummer des Primary routinemäßig prüft.
• Retry: Der Abstand, in dem ein gescheiterter Transferversuch wiederholt wird.
• Expire: Die maximale Zeit, die ein Secondary ohne erfolgreichen Kontakt zum Primary die Zone weiterhin als autoritativ ausliefern darf. Danach erklärt er die Zone für ungültig.
• Minimum (TTL): Der Standardwert für die Time-to-Live von Resource Records, die keine eigene TTL spezifizieren.

Sicherheitsaspekte des Zonentransfers

Zonentransfers können ein erhebliches Sicherheitsrisiko darstellen, da sie die komplette interne Netzwerkstruktur einer Domain offenlegen. Ein Angreifer, der einen Zonentransfer erfolgreich anfordert, erhält alle Subdomains, Hostnamen und IP-Adressen einer Organisation. Dies erleichtert die Planung gezielter Angriffe und die Auskundschaftung der Infrastruktur.

Aus diesem Grund müssen Zonentransfers strikt kontrolliert werden. Nameserver sind so zu konfigurieren, dass sie AXFR- und IXFR-Anfragen nur von explizit autorisierten IP-Adressen beantworten. In BIND geschieht dies über die allow-transfer-Direktive in der Zonenkonfiguration. Eine typische Absicherung erlaubt Transfers nur an die bekannten IP-Adressen der Secondary Nameserver und blockiert alle anderen Anfragen.

Historisch waren viele Nameserver so eingestellt, dass sie Zonentransfers an beliebige Anfragende lieferten. Tools wie dig mit dig axfr @ns1.example.com example.com konnten ungeschützte Zonen vollständig auslesen. Heutige Best Practices und Sicherheitsrichtlinien verbieten offene Transfers grundsätzlich, und Penetrationstests prüfen regelmäßig auf dieses Versäumnis.

Zonentransfer und DNSSEC

Mit der Einführung von DNSSEC (Domain Name System Security Extensions) wächst die Datenmenge in den Zonen durch zusätzliche Signature Records (RRSIG, DNSKEY, NSEC) erheblich an. Der Zonentransfer transportiert diese Signaturen zusammen mit den normalen Resource Records. DNSSEC selbst schützt nicht den Transfer, sondern die Authentizität der Daten. Der Schutz des Transfers erfolgt unabhängig davon über TSIG (Transaction Signatures), eine symmetrische Signatur zwischen Primary und Secondary, die Manipulationen und Replay-Angriffe auf die übertragenen Zonendaten verhindert. TSIG authentisiert die Transferpartner und gewährleistet die Integrität der übertragenen Daten auf dem Transportweg.

Typische Werkzeuge und Diagnose

Zur Diagnose und zum Test von Zonentransfers stehen verschiedene Werkzeuge zur Verfügung. dig erlaubt die direkte Anforderung eines AXFR mit dem Befehl dig axfr @nameserver domain. Kommt der Transfer zustande und werden Resource Records aufgelistet, ist der Server unzureichend geschützt. Der Befehl dig soa domain zeigt die Seriennummer und die Timer-Werte der Zone an.

Host und nslookup bieten ebenfalls die Möglichkeit, Transferanfragen zu stellen, wenn auch weniger komfortabel als dig. In der Praxis werden Zonentransfers meist automatisiert durch den Refresh-Mechanismus der Sekundärserver ausgelöst. Manuelle Eingriffe sind nur zur Fehlersuche oder zur Initialsynchronisation nach der Einrichtung eines neuen Sekundärservers erforderlich.

Grenzen und Best Practices

Zonentransfers sind keine Echtzeitreplikation. Zwischen dem Refresh-Intervall und dem tatsächlichen Transfer kann eine im SOA spezifizierte Zeitspanne liegen, in der Sekundärserver veraltete Daten ausliefern. Für hochdynamische Umgebungen können kurze Refresh-Werte oder NOTIFY-Nachrichten eingesetzt werden, mit denen der Primary die Sekundärserver aktiv über Änderungen informiert und einen sofortigen Abgleich anstößt.

Die Wahl zwischen AXFR und IXFR sollte zugunsten des IXFR ausfallen, sobald die Nameserver-Software dies unterstützt. IXFR reduziert Bandbreite und Last und beschleunigt die Synchronisation. Die Seriennummer muss bei jeder Änderung der Zone zwingend erhöht werden, da unterlassene Inkremente zu inkonsistenten Datenbeständen und schleichenden Fehlern im DNS führen. Ein Monitoring der Seriennummern und der Transfer-Logs hilft, Ausfälle und Konfigurationsfehler frühzeitig zu erkennen.