DNS-Zonen und Zonentransfers verstehen

DNS wirkt oft wie eine einzige globale Datenbank, ist hinter den Kulissen aber ein sorgfältig aufgeteiltes System. Die Verantwortung ist in Zonen gegliedert, jede Zone wird von mehreren autoritativen Servern ausgeliefert, und diese Server bleiben über einen Mechanismus namens Zonentransfer synchron. Wer diese Bausteine versteht, kann Verzögerungen bei der Propagation besser eingrenzen, ein zuverlässiges DNS-Setup wählen und eines der häufigsten Informationslecks im Internet vermeiden: den uneingeschränkten Zonentransfer. Dieser Artikel erklärt die Konzepte und schließt mit praktischen Konfigurations- und Testbeispielen.

Zonen und Domains: nicht dasselbe

Eine Domain ist ein Knoten im DNS-Baum samt allem, was darunter liegt. example.com ist eine Domain, shop.example.com ebenfalls. Eine Zone ist dagegen eine administrative Grenze: der Teil des Namensraums, der als Einheit verwaltet und von einem Satz autoritativer Nameserver veröffentlicht wird.

Oft sehen Domain und Zone identisch aus. Ein kleines Unternehmen hält vielleicht alle Records für example.com in einer einzigen Zonendatei. Wird aber ein Teil des Baums delegiert, laufen die Grenzen auseinander. Übergibt man eu.example.com an ein anderes Team mit eigenen Nameservern, behält die Elternzone nur NS-Records (und gegebenenfalls Glue-Adressen), die auf diese verweisen, und eu.example.com wird zu einer eigenen Zone. Die Domain example.com umfasst eu.example.com weiterhin, die Zone dagegen nicht.

Dieselbe Logik gilt ganz oben: Die Root-Zone delegiert .com, die .com-Zone delegiert example.com an die vom Inhaber registrierten Nameserver und so weiter. Schlagen Sie eine Domain mit dem WHOIS- und RDAP-Lookup von TLDix nach, sind die angezeigten Nameserver genau diese Delegation durch die Registry.

Was in einer Zone steckt

Eine Zone ist eine Sammlung von Resource Records. Die gängigsten sind unten aufgeführt.

Jede Zone hat genau einen SOA-Record an ihrem Apex und mindestens einen, meist zwei oder mehr NS-Records.

Der SOA-Record und seine Seriennummer

Der Start-of-Authority-Record beschreibt, wie die Zone gepflegt werden soll. In einer Zonendatei sieht ein typischer SOA so aus:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
              2026100701 ; serial
              7200       ; refresh
              900        ; retry
              1209600    ; expire
              300 )      ; negative caching TTL

• MNAME (ns1.example.com.) benennt den primären Server.
• RNAME (hostmaster.example.com.) ist das Postfach des Administrators, wobei der erste Punkt für das @-Zeichen steht.
• Serial ist eine Versionsnummer der Zone. Secondaries vergleichen sie mit ihrer eigenen Kopie; hat der Primary eine höhere Seriennummer, übertragen sie die Zone.
• Refresh gibt an, wie oft Secondaries die Seriennummer prüfen.
• Retry legt fest, wie lange sie nach einer fehlgeschlagenen Prüfung bis zum nächsten Versuch warten.
• Expire bestimmt, wie lange ein Secondary weiter antwortet, wenn er den Primary gar nicht erreicht. Danach stellt er die Auslieferung der Zone ein, statt veraltete Antworten zu geben.
• Minimum dient heute als TTL für negative Antworten wie NXDOMAIN (RFC 2308).

Eine verbreitete Konvention ist eine datumsbasierte Seriennummer im Format JJJJMMTTnn, etwa 2026100701 für die erste Änderung am 7. Oktober 2026. Der häufigste Fehler in handgepflegten Zonen: die Seriennummer nicht zu erhöhen. Der Primary liefert dann die neuen Daten aus, die Secondaries holen sie aber nie ab – Nutzer erhalten je nach erreichtem Server unterschiedliche Antworten. Seriennummern folgen der Sequence-Space-Arithmetik (RFC 1982); müssen Sie eine Nummer je verringern, geschieht das in geplanten Schritten, nicht durch simples Eintippen eines kleineren Werts.

Primäre und sekundäre Server

Die meisten Zonen werden aus Gründen der Ausfallsicherheit und Performance von mehreren autoritativen Servern veröffentlicht. Einer ist der Primary (früher Master genannt), auf dem die Zone bearbeitet oder generiert wird, etwa aus einer Datenbank oder über die API eines Anbieters. Die anderen sind Secondaries (früher Slaves), die schreibgeschützte Kopien vom Primary beziehen.

Aus Sicht eines Resolvers sind alle in den NS-Records genannten autoritativen Server gleichwertig; er kann jeden von ihnen fragen. Deshalb ist Konsistenz so wichtig: Hinkt ein Secondary hinterher, sieht ein Teil Ihres Traffics veraltete Records. Viele Organisationen nutzen einen Hidden Primary – einen Server, der nicht in den öffentlichen NS-Records steht und nur die Secondaries versorgt, was seine Angriffsfläche verringert.

Secondaries bei einem anderen Anbieter oder in einem anderen Netz sind zudem ein klassischer Weg, Ausfälle zu überstehen, denn eine Störung bei einem Anbieter nimmt dann nicht mehr die gesamte Zone vom Netz.

Vollständige (AXFR) und inkrementelle Transfers (IXFR)

Braucht ein Secondary Daten, fordert er einen Zonentransfer über TCP an.

AXFR: die gesamte Zone

AXFR, standardisiert in RFC 5936, überträgt jeden Record der Zone und beginnt und endet mit dem SOA-Record. Das Verfahren ist einfach und robust und kommt immer zum Einsatz, wenn ein Secondary noch keine Kopie hat. Bei großen Zonen verschwendet es allerdings Bandbreite und Zeit, nach jeder kleinen Änderung eine Vollkopie zu wiederholen.

IXFR: nur das, was sich geändert hat

IXFR, definiert in RFC 1995, erlaubt dem Secondary, seine aktuelle Seriennummer zu senden und nur die Unterschiede zu erhalten: gelöschte und hinzugefügte Records zwischen den Versionen. Dafür muss der Primary ein Journal der jüngsten Änderungen führen. Kann er die Unterschiede nicht liefern, etwa weil das Journal geleert wurde, weicht er auf eine vollständige Übertragung aus.

NOTIFY: kein Warten mehr auf den Refresh-Timer

Würde man sich allein auf das Refresh-Intervall verlassen, könnten Änderungen Stunden brauchen, bis sie die Secondaries erreichen. Der in RFC 1996 beschriebene DNS-NOTIFY-Mechanismus löst das. Ändert sich die Zone, schickt der Primary eine NOTIFY-Nachricht an seine Secondaries. Jeder Secondary fragt daraufhin den SOA ab, sieht die höhere Seriennummer und startet sofort einen IXFR oder AXFR. In der Praxis verkürzt das die Aktualisierung der Secondaries auf Sekunden. Refresh bleibt als Sicherheitsnetz bestehen, falls ein NOTIFY verloren geht.

Beachten Sie, dass dies etwas anderes ist als das, was gemeinhin Propagation genannt wird. Sind alle autoritativen Server synchron, entsteht die verbleibende Verzögerung durch Resolver weltweit, die ältere Records bis zum Ablauf ihrer TTL zwischenspeichern.

Warum offene Zonentransfers ein Problem sind

Erlaubt ein Server AXFR für jeden, kann jeder den vollständigen Inhalt der Zone herunterladen. Das kann interne Hostnamen, Staging-Systeme, VPN-Endpunkte, Mail-Infrastruktur und Namensmuster preisgeben – Informationen, die die Aufklärung für Angreifer trivial machen. Diese Fehlkonfiguration findet sich nach wie vor im Internet, oft als Überbleibsel von Standardeinstellungen oder alten Setups. Die Regel ist einfach: Nur Ihre eigenen Secondaries dürfen die Zone übertragen.

IP-basierte Einschränkungen sind ein guter erster Schritt, doch IP-Adressen können sich ändern oder geteilt sein. TSIG ergänzt eine Authentifizierung.

Transfers mit ACLs und TSIG absichern

TSIG (Transaction Signature, RFC 8945) signiert DNS-Nachrichten mit einem gemeinsamen geheimen Schlüssel und einem HMAC-Algorithmus wie HMAC-SHA256. Der Primary beantwortet nur Transferanfragen, die mit dem richtigen Schlüssel signiert sind, und der Secondary kann prüfen, dass die Daten tatsächlich vom Primary stammen und unterwegs nicht verändert wurden. TSIG verschlüsselt die Zone nicht; für Vertraulichkeit lassen sich, wo unterstützt, neuere Standards wie XoT (Zonentransfer über TLS, RFC 9103) einsetzen.

Ein Schlüssel wird in BIND typischerweise mit tsig-keygen erzeugt. Die Konfiguration auf dem Primary könnte dann so aussehen:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.db";
    allow-transfer { key "xfer-key"; };
    also-notify { 198.51.100.20; };
    notify yes;
};

Und auf dem Secondary:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

server 192.0.2.10 { keys { "xfer-key"; }; };

zone "example.com" {
    type secondary;
    primaries { 192.0.2.10; };
    file "/var/cache/bind/example.com.db";
};

Bewahren Sie das Secret sicher auf, tauschen Sie es aus, wenn Personal oder Anbieter wechseln, und verwenden Sie, wo praktikabel, pro Secondary-Beziehung einen eigenen Schlüssel. Ältere BIND-Versionen nutzen die Schlüsselwörter master und slave statt primary und secondary; aktuelle Releases akzeptieren beide.

Zonentransfers mit dig testen

Prüfen Sie die Einschränkungen nach der Konfiguration von einem Rechner, der keinen Zugriff haben sollte:

dig @ns1.example.com example.com AXFR

Ein korrekt abgesicherter Server antwortet mit Transfer failed oder dem Status REFUSED. Von einem autorisierten Secondary testen Sie mit dem Schlüssel:

dig @192.0.2.10 example.com AXFR -y hmac-sha256:xfer-key:REPLACE-WITH-SECRET
dig @192.0.2.10 example.com IXFR=2026100701

Um zu bestätigen, dass alle autoritativen Server synchron sind, vergleichen Sie die Seriennummern:

dig +nssearch example.com
dig @ns2.example.com example.com SOA +short

Meldet ein Server eine ältere Seriennummer, prüfen Sie die Zustellung von NOTIFY, die Firewall-Regeln für TCP-Port 53 und die Logs auf beiden Seiten. Testen Sie Transfers nur gegen Server, die Sie selbst betreiben oder für die Sie eine Testerlaubnis haben.

Das Gesamtbild gesund halten

Zonen und Transfers sind nur ein Teil dessen, was eine Domain erreichbar hält. Die Delegation bei der Registry muss auf die richtigen Nameserver zeigen, DNSSEC-Signaturen müssen gültig bleiben (Secondaries können signierte Zonen ausliefern, Schlüssel und DS-Record müssen aber zusammenpassen, wie in Warum DNSSEC für die Domainsicherheit unverzichtbar ist erklärt), und die Domain selbst darf nicht ablaufen. Wer seine Domains und deren Verlängerungstermine im TLDix-Domainpanel verwaltet, erkennt Probleme, bevor Nutzer sie bemerken. Mit einer klaren SOA-Strategie, aktiviertem NOTIFY, per TSIG beschränkten Transfers und regelmäßigen Prüfungen mit dig wird Ihr DNS konsistent – und von außen deutlich schwerer auszuspähen.