Offener Zonentransfer: Wenn das DNS die ganze Zone verrät

Was ein Zonentransfer ist und wofür er gebaut wurde

Eine DNS-Zone ist die Menge aller Einträge, die für einen Namensraum autoritativ beantwortet werden: A- und AAAA-Einträge für Adressen, MX für die Mailzustellung, CNAME-Verweise, TXT-Einträge für Zertifikatsnachweise und Versanddomains, dazu NS und SOA. Damit mehrere Nameserver dieselben Antworten geben, muss dieser Bestand vom primären Server zu den sekundären gelangen. Genau dafür wurde der Zonentransfer gebaut: Der sekundäre Server stellt eine Anfrage vom Typ AXFR, der primäre antwortet mit dem gesamten Inhalt der Zone, eingerahmt vom SOA-Eintrag. Weil diese Antwort in aller Regel nicht in ein einzelnes UDP-Paket passt, läuft AXFR über TCP.

Neben AXFR gibt es den inkrementellen Transfer IXFR, dessen Abfragetyp bei der IANA die Nummer 251 trägt (RFC 1995). Er überträgt statt des ganzen Bestands nur die Unterschiede seit einer bekannten Seriennummer. Kann der Server diese Differenz nicht liefern, gibt er die vollständige Zone zurück und verhält sich damit wie ein AXFR. Wer die Preisgabe eindämmen will, muss deshalb beide Abfragetypen betrachten und nicht nur den bekannteren.

• Der SOA-Eintrag mit seiner Seriennummer entscheidet, ob ein sekundärer Server überhaupt nachzieht.
• Ein NOTIFY vom primären Server verkürzt die Wartezeit, ersetzt den Transfer aber nicht.
• AXFR liefert den gesamten Bestand, IXFR im Regelfall nur die Änderungen seit einer Seriennummer.
• Die Antwort läuft über TCP, weil sie die Größe eines einzelnen UDP-Pakets in der Regel überschreitet.
• Wer den Transfer beantworten darf, steht nicht im Protokoll, sondern in der Konfiguration des Servers.

Der letzte Punkt ist der entscheidende. RFC 5936 hält fest, dass eine DNS-Umsetzung Mittel bereitstellen sollte, um AXFR-Sitzungen auf bestimmte Gegenstellen zu begrenzen, und dass die Zonenverwaltung die Möglichkeit hat, den Zugriff auf einen Transfer einzuschränken (RFC 5936). Beide Sätze sprechen von einer Möglichkeit, nicht von einem Vorgabewert. Ob die Begrenzung gesetzt ist, entscheidet der Betrieb, und diese Entscheidung fällt in der Praxis oft unbemerkt.

Warum der ganze Zonenbestand schwerer wiegt als ein einzelner Eintrag

Ein einzelner DNS-Eintrag ist öffentlich abfragbar, sobald jemand den Namen kennt. Der Unterschied zwischen "öffentlich abfragbar" und "auf einen Schlag lesbar" ist trotzdem groß. NIST beschreibt in seinem Leitfaden zur sicheren DNS-Einrichtung, dass ein Zonentransfer andere Sicherheitsfolgen hat als eine gewöhnliche DNS-Anfrage, weil er sehr viel mehr Informationen preisgibt und mehr Bandbreite und Antwortzeit verbraucht (NIST SP 800-81-2). Wer eine Zone abzieht, muss keine Namen mehr raten.

RFC 9103 wird an dieser Stelle konkret: Der vollständige Zoneninhalt legt sämtliche IP-Adressen der in den Einträgen hinterlegten Endpunkte offen, was Auskundschaftung und Zielauswahl erleichtert, besonders bei IPv6-Adressen und privaten Netzen (RFC 9103). Genau das ist der Punkt, an dem eine Zone mehr verrät als eine Adressliste: Sie liefert die Namen gleich mit. "backup-db" und "staging" sind keine zufälligen Zeichenketten, sondern eine Aufgabenbeschreibung. Wie viel schon ein einzelner Antwortkopf über eine Installation aussagt, steht in unserem Beitrag zu Versionsbannern und Server-Headern.

Der Befund entsteht beim Wechsel, nicht beim Aufsetzen

Wer eine Zone heute neu anlegt, bekommt bei den gängigen Servern und Verwaltungsoberflächen in der Regel eine geschlossene Vorgabe. Auffällig ist deshalb weniger die Erstinstallation als die Änderung: ein Umzug, ein zusätzlicher sekundärer Server, ein Anbieterwechsel, eine Migration auf eine neue Verwaltungsoberfläche. In diesen Momenten wird eine Transferfreigabe geöffnet, weil sonst die Übernahme scheitert, und danach bleibt sie stehen.

• Ein Anbieterwechsel, bei dem die Zone über einen Transfer übernommen und die Freigabe danach nicht zurückgenommen wurde.
• Ein zusätzlicher sekundärer Nameserver, dessen Adresse noch nicht feststand, weshalb die Freigabe vorläufig weit gefasst wurde.
• Ein wiederhergestelltes System, das aus einer alten Sicherung eine ältere Konfiguration mitbringt.
• Ein Server, der aus einer Vorlage stammt, in der die Beschränkung von vornherein fehlte.
• Eine Subdomain, die an einen anderen Nameserver delegiert wurde, dessen Konfiguration niemand mehr prüft.

Die Freigabe ist in diesen Fällen kein Versehen, sondern ein bewusster Zwischenschritt, dessen Rücknahme in der Umzugsliste fehlte. Genauso geht bei einem Wechsel die Frage unter, ob am Ende alle Resolver denselben Stand ausliefern, eine Prüfung, die wir im Beitrag zur DNS-Propagation über mehrere Resolver beschrieben haben.

Die Prüfung dauert eine Minute

Die Frage lässt sich mit Bordmitteln beantworten. Zuerst die autoritativen Nameserver der Zone ermitteln, dann jeden davon einzeln mit einer AXFR-Anfrage ansprechen. Antwortet der Server mit einer Fehlermeldung oder bricht die Verbindung ab, ist der Transfer beschränkt. Kommt eine Liste von Einträgen zurück, ist er offen. Die folgenden Aufrufe verwenden eine Beispieldomain, die nach RFC 2606 für niemanden auflösbar ist.

Der zweite Aufruf zeigt das erwünschte Verhalten: Der Server verweigert den Transfer. Der dritte zeigt den Befund. Die Zeile mit der Übertragungsgröße am Ende ist dabei ein eindeutiges Signal, denn sie erscheint nur, wenn ein Transfer tatsächlich zustande gekommen ist. Für die Dokumentation reicht diese eine Zeile zusammen mit dem Namen des antwortenden Servers und dem Zeitpunkt der Messung.

Vom Zonenabzug zum Angriff

Ein abgezogener Zonenbestand ist selten der Angriff selbst, sondern seine Vorbereitung. Er verkürzt die Phase, in der jemand nach Ansatzpunkten sucht, von Tagen auf Minuten. Drei Wege führen typischerweise weiter, und der erste davon ist die Übernahme verwaister Verweise, die wir im Beitrag zu verwaisten CNAME-Einträgen und Subdomain-Übernahme ausführlich beschrieben haben.

Der dritte Weg grenzt an die Frage nach ähnlich geschriebenen Domains und an die Lage, in der die Einträge selbst nicht mehr die eigenen sind. Wie sich ein solcher Zugriff auf die DNS-Verwaltung erkennen lässt, steht in einem eigenen Beitrag. Der offene Zonentransfer steht in dieser Kette am Anfang: Er kostet nichts und liefert die Grundlage für alles Weitere.

Ein offener Zonentransfer ist kein Einbruch. Er ist eine Auskunft, die niemand beantragt hat und die alles enthält, wonach ein Einbrecher sonst erst fragen müsste.

— XICTRAQ

Beschränken: was konkret konfiguriert wird

Das BSI führt den Zonentransfer im Baustein APP.3.6 DNS-Server. Dort steht als Anforderung, dass Zonentransfers so konfiguriert werden müssen, dass sie nur zwischen primären und sekundären DNS-Servern möglich sind (BSI IT-Grundschutz, APP.3.6.A4). Die Begründung liefert derselbe Baustein in seiner Gefährdungslage: Ohne Einschränkung kann jeder Host, der eine Anfrage an die DNS-Server stellen kann, die gesamten Domain-Informationen dieser Server auslesen (BSI IT-Grundschutz, APP.3.6).

1. Die Adressen der eigenen sekundären Nameserver in einer benannten Liste führen und den Transfer nur dorthin freigeben.
2. Die Vorgabe auf Serverebene schließen, damit eine neu angelegte Zone nicht offen startet.
3. Beide Abfragetypen abdecken, den vollständigen und den inkrementellen Transfer.
4. Die Freigabe zusätzlich mit einem gemeinsamen Schlüssel absichern, statt sie allein an Adressen zu binden.
5. Nach jeder Änderung an Zone oder Server erneut von außen messen, statt in der Konfigurationsdatei nachzusehen.

# Die eigenen sekundären Nameserver als benannte Liste führen,
# damit die Adressen nicht in jeder Zone einzeln stehen
acl "spiegel" {
    198.51.100.14;
    203.0.113.9;
};

# Gemeinsamer Schlüssel für den Transfer (TSIG). Der Wert selbst liegt in einer
# eigenen Datei, die nur der Dienst lesen darf, und steht nicht in dieser Datei.
key "transfer-key" {
    algorithm hmac-sha256;
};

options {
    # Vorgabe für alle Zonen: kein Transfer
    allow-transfer { none; };
};

zone "beispiel.invalid" {
    type primary;
    file "zonen/beispiel.invalid";

    # Gezielt geöffnet: nur die eigenen Spiegel, nur mit Schlüssel
    allow-transfer { key "transfer-key"; spiegel; };
};

# Die Namen der Anweisungen unterscheiden sich je nach eingesetzter Serversoftware.
# Maßgeblich ist die Wirkung: geschlossene Vorgabe, benannte Gegenstellen,
# signierter Transfer.

Eine Beschränkung allein auf Adressen ist besser als keine, aber sie hängt an der Absenderadresse eines Pakets. Das BSI empfiehlt deshalb, Zonentransfers zusätzlich mit Transaction Signatures (TSIG) abzusichern (BSI IT-Grundschutz, APP.3.6.A18). NIST beschreibt denselben Gedanken von der anderen Seite: Die Einschränkungen adressieren die Gefahr der Dienstblockade und mögliche Ausnutzung durch die unbeschränkte Verbreitung von Informationen über interne Ressourcen (NIST SP 800-81-2). Ein gemeinsamer Schlüssel bindet die Freigabe an ein Geheimnis statt an eine Adresse, die sich fälschen lässt.

Was die Beschränkung nicht löst: das Ablaufen der Zone

Ein geschlossener Zonentransfer verhindert nicht, dass sich der Bestand auf anderem Weg rekonstruieren lässt. Bei signierten Zonen, die den älteren NSEC-Datensatz verwenden, ist das Ablaufen der Zone trivial möglich: Die Anfragen nach dem beglaubigten Nachweis der Nichtexistenz erlauben es, sich durch den gesamten Zoneninhalt zu bewegen (RFC 9103). RFC 5155 formuliert dieselbe Ausgangslage für solche signierten Zonen so, dass die dort vorhandenen NSEC-Datensätze die Aufzählung ermöglichen und es trivial ist, den Zoneninhalt durch Anfragen nach nicht existierenden Namen aufzuzählen (RFC 5155).

Der Nachfolger NSEC3 wurde genau gegen dieses Verhalten entworfen und erschwert die Aufzählung deutlich, ohne sie in jedem Fall auszuschließen. Wer eine Zone signiert, sollte das mitplanen. Wie die Signaturkette geprüft und überwacht wird, haben wir im Beitrag zur DNSSEC-Validierung und ihrer Überwachung beschrieben.

Vertraulich übertragen statt nur beschränken

Auch ein beschränkter Zonentransfer läuft im Klartext über das Netz. RFC 9103 nennt das gleich zu Beginn als Ausgangsproblem: Zonentransfers werden im Klartext übertragen, was Angreifern die Gelegenheit gibt, den Inhalt einer Zone durch Mitlesen von Netzverbindungen zu sammeln (RFC 9103). Die Antwort darauf ist der Zonentransfer über TLS. Er soll nach derselben Festlegung über Port 853 aufgebaut werden, sofern primärer und sekundärer Server sich nicht ausdrücklich auf einen anderen Port einigen (RFC 9103).

Für einen Betrieb mit eigenen Nameservern ist das eine erreichbare Verbesserung. Für einen Betrieb mit verwalteten DNS-Diensten hängt es davon ab, was die eingesetzte Umgebung unterstützt. Wichtiger als die Frage nach TLS ist deshalb die Reihenfolge: erst die Freigabe schließen, dann signieren, dann verschlüsseln. Eine verschlüsselte Verbindung zu einem Server, der ohnehin jedem antwortet, ändert an der Preisgabe nichts.

Einmal geprüft ist nicht geprüft

Der Zustand einer DNS-Zone ist kein Dauerzustand. Er ändert sich bei jedem Umzug, bei jedem zusätzlichen Server, bei jeder Wiederherstellung aus einer Sicherung. Eine einmalige Prüfung dokumentiert deshalb einen Zeitpunkt, keine Eigenschaft. Der Unterschied zwischen beiden Betriebsarten lässt sich an fünf Fragen festmachen.

In XICTRAQ gehört diese Prüfung zum Security-Scan, der die Zone regelmäßig gegen dieselbe Frage stellt, und zum DNS- und Domain-Monitoring, das neu auftauchende und verschwundene Einträge meldet. Dieselbe Logik gilt eine Schicht tiefer für die Erreichbarkeit der Adressen selbst; dazu erscheint in dieser Woche der Beitrag zu BGP, RPKI und der Überwachung von Routen.

Was der Alarm auslösen soll

Ein Befund ohne Empfänger ist ein Eintrag in einem Bericht. Damit aus der Messung eine Handlung wird, braucht es einen Weg vom Ergebnis zu der Person, die den Server anfassen darf. Für den offenen Zonentransfer heißt das: eine Meldung über einen Kanal, der ankommt, und eine zweite, wenn niemand annimmt. Wie sich das Melden und Eskalieren einrichten lässt, ohne im Rauschen unterzugehen, ist eine eigene Frage.

Diese Reihenfolge ist übertragbar. Sie gleicht dem Vorgehen bei Schnittstellen, deren Abkündigung über Sunset- und Deprecation-Header angekündigt wird, und dem bei Zeitumstellungen, die Messreihen still verschieben. In allen drei Fällen ist die Messung der einfache Teil und die Zuständigkeit der schwierige.

Der Zonentransfer gehört auf die Prüfliste

Unter den DNS-Befunden gehört der offene Zonentransfer zu denen mit einem günstigen Verhältnis von Aufwand zu Wirkung: Eine Abfrage je Nameserver beantwortet die Frage, eine Konfigurationszeile schließt sie, und der Nachweis ist reproduzierbar. Aufwendig wird er nur, wenn ihn niemand stellt.

1. Die autoritativen Nameserver der Zone auflisten und jeden einzeln mit einer AXFR-Anfrage prüfen.
2. Delegierte Subdomains und selbst verwaltete Reverse-Zonen in dieselbe Prüfung nehmen.
3. Die Freigabe auf die eigenen sekundären Server begrenzen und die Vorgabe auf Serverebene schließen.
4. Den Transfer zusätzlich mit einem gemeinsamen Schlüssel absichern.
5. Nach jedem Umzug, jedem neuen Server und jeder Wiederherstellung erneut von außen messen.
6. Die Prüfung in einen Takt heben, statt sie an einen Termin zu binden.

In XICTRAQ läuft dieser Takt als Teil des Security-Scans, das Ergebnis erscheint im Bericht und auf der Statusseite, und die Historie zeigt, seit wann ein Zustand besteht. Verarbeitet und gehostet in Deutschland.