AXFR-Zonentransfers verstehen

Was ist AXFR?

Secondary-DNS-Dienst — AXFR-Zonentransfer und automatische Zonensynchronisation

AXFR (vollständiger Zonentransfer) ist ein Mechanismus des DNS-Protokolls, mit dem sich eine komplette Zone von einem primären Nameserver auf einen sekundären Server replizieren lässt. Braucht ein sekundärer Server eine Kopie einer Zone, öffnet er eine AXFR-Anfrage an den primären Server. Dieser antwortet mit sämtlichen Records der Zone in einem einzigen TCP-Stream.

AXFR ist in RFC 5936 definiert und läuft über TCP auf Port 53 statt über UDP, weil eine komplette Zone meist größer ist als ein einzelnes UDP-Datagramm. Der Transfer umfasst jeden Record der Zone: SOA, NS, A, AAAA, MX, CNAME, TXT und alle übrigen. Kurz gesagt: Über AXFR holt sich ein sekundärer DNS-Server die autoritative Kopie Ihrer DNS-Daten und hält sie aktuell.

Vollständige vs. inkrementelle DNS-Zonentransfers

Es gibt zwei Arten von Zonentransfers:

AXFR (vollständiger Transfer): überträgt jedes Mal die gesamte Zone. Einfach und zuverlässig, verbraucht bei großen Zonen aber mehr Bandbreite.

IXFR (inkrementeller Transfer, RFC 1995): überträgt nur die Records, die sich seit der letzten Seriennummer des sekundären Servers geändert haben. Bei großen Zonen mit häufigen kleinen Änderungen deutlich effizienter.

Die meisten DNS-Programme beherrschen beides. Ein sekundärer Server versucht in der Regel zuerst IXFR und weicht auf AXFR aus, falls der primäre Server keine inkrementellen Transfers unterstützt, falls die angeforderte Seriennummer zu alt ist, um daraus ein Delta zu berechnen, oder falls das IXFR-Journal des primären Servers gekürzt wurde. AXFR ist deshalb die zuverlässige Grundlage, die immer funktioniert; IXFR ist die Optimierung obendrauf.

Wie DNS-Zonentransfer funktioniert

Ein Zonentransfer durchläuft diese Schritte:

1. Der sekundäre Server prüft den SOA-Record auf dem primären Server, entweder per Refresh-Timer oder sobald er eine NOTIFY-Nachricht erhält. 2. Liegt die SOA-Seriennummer des primären Servers höher als die der lokalen Kopie des sekundären Servers, ist ein Transfer fällig. 3. Der sekundäre Server öffnet eine AXFR- (oder IXFR-)Anfrage an den primären Server über TCP-Port 53. 4. Der primäre Server prüft, ob der sekundäre Server zum Transfer berechtigt ist (per IP-ACL und/oder TSIG), und sendet bei Berechtigung die Zonendaten. 5. Der sekundäre Server ersetzt (AXFR) oder aktualisiert (IXFR) seine lokale Kopie und beantwortet Anfragen ab sofort mit den neuen Daten.

Die Timer Refresh, Retry und Expire des SOA-Records steuern, wie oft der sekundäre Server nach Aktualisierungen sucht und wie lange er weiter antwortet, wenn der primäre Server nicht erreichbar ist.

DNS-Zonen-Aktualisierungs- und Wiederholungsintervalle

Der SOA-Record enthält vier Zeitparameter, die das Verhalten beim Zonentransfer steuern:

Refresh: wie oft der sekundäre Server den primären Server auf Aktualisierungen prüft (z. B. 3600 = stündlich).

Retry: wie oft der sekundäre Server es erneut versucht, wenn der primäre Server nicht erreichbar ist (z. B. 900 = alle 15 Minuten).

Expire: wie lange der sekundäre Server die Zone weiter beantwortet, wenn er den primären Server nicht erreicht (z. B. 604800 = 7 Tage). Nach Ablauf stellt der sekundäre Server die Antworten für die Zone ein. Deshalb schützt Sie ein hoher Expire-Wert während eines längeren Ausfalls des primären Servers.

Minimum TTL: die TTL für das Negativ-Caching, also wie lange Resolver eine NXDOMAIN-Antwort zwischenspeichern. Laut RFC 2308 gilt der kleinere Wert aus diesem Feld und der eigenen TTL des SOA-Records.

Für häufig wechselnde Zonen wählen Sie einen niedrigeren Refresh-Wert. Ist jedoch NOTIFY konfiguriert, spielt Refresh kaum noch eine Rolle, weil Änderungen nahezu sofort verteilt werden. Bei stabilen Zonen senken höhere Werte unnötigen Datenverkehr.

DNS-Zonensynchronisation in Echtzeit mit NOTIFY

Statt den Refresh-Timer abzuwarten, sendet der primäre Server unmittelbar nach einer Zonenänderung eine NOTIFY-Nachricht (RFC 1996) an seine sekundären Server. Das NOTIFY teilt dem sekundären Server mit, seine Seriennummer jetzt zu prüfen, was eine SOA-Prüfung und bei Bedarf einen Transfer auslöst.

NOTIFY verkürzt die Verzögerung zwischen einer Änderung auf dem primären Server und ihrem Erscheinen auf den sekundären Servern von Minuten (dem Refresh-Intervall) auf Sekunden.

Die meisten DNS-Programme senden NOTIFY automatisch an jeden Server, der in den NS-Records der Zone aufgeführt ist. Einen sekundären Server, der nicht im NS-Satz steht, was bei einem versteckten oder Stealth-Secondary eines Anbieters häufig vorkommt, tragen Sie als ausdrückliches also-notify-Ziel ein, damit auch er Aktualisierungen erhält.

DNS-Zonentransfers mit dig testen

Mit dig können Sie von Hand eine AXFR anfordern, um zu bestätigen, dass ein Transfer funktioniert, oder um zu prüfen, ob Ihre Zone gefährlich offen liegt. Fragen Sie einen bestimmten Server nach der kompletten Zone:

dig AXFR example.com @ns1.example.com

Erlaubt der Server den Transfer, gibt dig jeden Record der Zone aus. Ist er korrekt abgesichert, erhalten Sie stattdessen:

; Transfer failed.

oder eine Verbindung, die keine Records liefert. Dieses Fehlschlagen ist bei einer öffentlichen Anfrage das gewünschte Ergebnis: Nur Ihre autorisierten sekundären Server sollten die Zone abrufen können.

Von der Seite des sekundären Servers prüfen Sie nach einem Transfer, ob die Seriennummern übereinstimmen:

dig SOA example.com @primary-ip +short
dig SOA example.com @secondary-ip +short

Beide sollten dieselbe SOA-Seriennummer zurückgeben. Zeigt der sekundäre Server eine niedrigere Seriennummer, ist der Transfer nicht abgeschlossen. Prüfen Sie dann NOTIFY, die ACL und TCP-Port 53.

Sicherheit bei DNS-Zonentransfers

Eine AXFR legt Ihre gesamte Zone offen, also jeden Hostnamen, jeden Mailserver und jeden TXT-Record. Ein offener Transfer ist ein klassischer Befund bei der Aufklärung: Wer Ihre Zone abrufen kann, erfährt mit einer einzigen Anfrage Ihre interne Namensgebung, Ihre Staging-Hosts und den Aufbau Ihrer Infrastruktur. Schränken Sie deshalb ein, wer transferieren darf:

IP-basierte ACLs: erlauben AXFR nur von den bekannten IPs Ihrer sekundären Server. Das ist die häufigste und einfachste Maßnahme.

TSIG (Transaction Signatures, RFC 8945): kryptografische Authentifizierung mit einem gemeinsamen Geheimnis. Stärker als eine IP-ACL, weil sie sich nicht durch IP-Spoofing aushebeln lässt und auch dann greift, wenn sich die IP des sekundären Servers ändert.

Firewall-Regeln: halten TCP-Port 53 nur für autorisierte sekundäre Server erreichbar.

Verwenden Sie niemals allow-transfer { any; } (oder das jeweilige Gegenstück in PowerDNS). Testen Sie Ihre eigenen Domains mit dem obigen dig-AXFR-Befehl: Liefert eine öffentliche Anfrage Records, liegt Ihre Zone offen und Sie sollten sie sofort absichern.

Zonentransfers mit TSIG absichern

TSIG ergänzt Transfer-Anfragen um eine Signatur mit gemeinsamem Geheimnis, sodass der primäre Server den sekundären Server unabhängig von dessen IP authentifizieren kann. Erzeugen Sie einen Schlüssel und binden Sie ihn dann auf beiden Servern ein.

Einen Schlüssel erzeugen (BIND-Werkzeug):

tsig-keygen -a hmac-sha256 transfer-key

Das gibt einen Schlüsselblock aus. Auf dem primären BIND-Server definieren Sie den Schlüssel und machen ihn für Transfers zur Pflicht:

key "transfer-key" {
    algorithm hmac-sha256;
    secret "BASE64_SECRET_HERE";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { key "transfer-key"; };
};

Der sekundäre Server wird mit demselben Schlüsselnamen, Algorithmus und Geheimnis konfiguriert und legt diesen Schlüssel vor, wenn er den Transfer anfordert. Verwenden Sie auf beiden Seiten dasselbe Schlüsselmaterial und checken Sie das Geheimnis niemals in die Versionsverwaltung ein.

Beispielkonfigurationen für Zonentransfers

BIND (primary):

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { 192.0.2.1; };
    also-notify { 192.0.2.1; };
};

PowerDNS (primary):

allow-axfr-ips=192.0.2.1/32
also-notify=192.0.2.1
disable-axfr=no

Ersetzen Sie 192.0.2.1 durch die tatsächliche IP-Adresse Ihres sekundären DNS-Servers.

Fehlerbehebung bei DNS-Zonentransfers

Transfer abgelehnt: prüfen Sie die allow-transfer- bzw. ACL-Einstellungen auf dem primären Server und vergewissern Sie sich, dass die IP (oder der TSIG-Schlüssel) des sekundären Servers passt. Testen Sie mit dig AXFR aus dem Netz des sekundären Servers.

Verbindungs-Timeout: AXFR nutzt TCP-Port 53, nicht UDP. Eine Firewall, die nur UDP 53 für normale Anfragen öffnet, lässt die Auflösung funktionieren, bringt Transfers aber unbemerkt zum Scheitern. Öffnen Sie TCP 53 zwischen primärem und sekundärem Server.

Seriennummer steigt nicht: der primäre Server muss bei jeder Änderung die SOA-Seriennummer erhöhen. Achten Sie beim Format YYYYMMDDNN darauf, NN bei mehreren Änderungen am selben Tag hochzuzählen, sonst bemerkt der sekundäre Server keine Änderung.

Sekundärer Server zeigt veraltete Daten: vergewissern Sie sich, dass NOTIFY konfiguriert ist. Ohne NOTIFY aktualisiert der sekundäre Server nur im SOA-Refresh-Intervall.

Transfer einer großen Zone schlägt fehl: sehr große Zonen (mit Millionen von Records) können mitten im Transfer an TCP-Timeout-Grenzen stoßen. Erhöhen Sie die Transfer- und Timeout-Einstellungen auf beiden Seiten und bevorzugen Sie IXFR, damit nur Deltas übertragen werden.

Sie möchten keinen eigenen sekundären Server betreiben und debuggen? SecondDNS bietet verwaltetes Secondary-DNS mit automatischer AXFR-Synchronisierung — kostenlos starten.