Zusammenfassung

  • RFC 9103 verhindert, dass ein passiver Beobachter den Inhalt eines Klartext-Zonentransfers einsammelt. Sichtbare Endpunkte, Zeit- und Größensignale, DNSSEC-Enumeration und gewöhnliche autoritative Antworten bleiben davon getrennt.
  • Eine belastbare XoT-Aussage verlangt eigene Nachweise für Primäridentität, zonenspezifische Berechtigung, TLS-Zwang, Abschluss, Annahme der Replik, den gesamten transfer group und die spätere Verwahrung.

Der Beobachter musste nie um Erlaubnis bitten

Ein Primary kann AXFR nur für bekannte Adressen freigeben und TSIG verlangen. Damit wird ein unberechtigter Client abgewiesen. Läuft die genehmigte Antwort dennoch über Klartext-TCP, muss ein Beobachter auf dem Pfad weder die ACL umgehen noch den gemeinsamen Schlüssel kennen. Er liest die Records mit, die an den legitimen Secondary gehen.

RFC 9103 schließt genau diesen Weg. Das im August 2021 auf dem IETF Standards Track veröffentlichte Dokument definiert XFR over TLS für vollständige AXFR- und inkrementelle IXFR-Übertragungen. Das ist bedeutsam: Ein Replikationsstrom kann in kurzer Zeit eine dichte Übersicht über Namen, Adressen und betriebliche Beziehungen liefern.

Das Bedrohungsmodell bleibt bewusst begrenzt. Geschützt werden aktueller Zoneninhalt und Zonengröße während der Übertragung. Nicht verborgen werden die Existenz der Zone, der Vorgang des Transfers oder die beteiligten Nameserver. Aus verschlüsseltem Verkehr können weiterhin Zeit, Größe und Beziehungen abgeleitet werden.

Die richtige Aussage lautet deshalb: Der geprüfte Pfad gab den Payload nicht mehr als Klartext an passive Beobachter preis. „Die Zone ist privat“ wäre eine andere, wesentlich größere Behauptung.

TSIG und TLS belegen verschiedene Eigenschaften

RFC 8945 beschreibt TSIG als Authentisierung von DNS-Transaktionen mit gemeinsamem Geheimnis. RFC 5936 nutzt TSIG zur Autorisierung von Transfer-Clients und zur Integritätssicherung. TSIG verschlüsselt jedoch nicht. Eine gültig signierte Klartextübertragung kann authentisch und zugleich lesbar sein.

TLS schützt den Kanal. Nach RFC 9103 authentisiert der Secondary den Primary mit einem Strict-Privacy-Profil. Der Primary prüft die Berechtigung des Clients durch gegenseitiges TLS oder durch eine IP-ACL zusammen mit gültigem TSIG beziehungsweise SIG(0). Strict TLS liefert Serverauthentisierung und Kanalvertraulichkeit; mTLS ergänzt Clientauthentisierung; TSIG belegt Datenursprung. Diese Belege sind komplementär.

Eine angenommene TLS-Verbindung ist keine pauschale Zonenerlaubnis. Mehrere Zonen und Anfragen können denselben Kanal nutzen. Übliche Implementierungen wenden ihre ACL erst auf die konkrete XFR-Anfrage an. Offener Port, erfolgreicher Handshake und genehmigter Transfer einer bestimmten Zone sind drei Zustände.

Der Ausnahmeweg bestimmt die Reichweite des Versprechens

Alle beteiligten Primaries und Secondaries bilden nach RFC 9103 den transfer group. Für eine gruppenweite Vertraulichkeit müssen sämtliche AXFR- und IXFR-Wege XoT erzwingen. Ein alter Secondary, eine Migrationsausnahme oder ein Klartext-Backend hinter einem TLS-Proxy erhält die Schwachstelle.

Opportunistic TLS genügt nicht. Es kann ohne erfolgreich verifizierte Serveridentität fortfahren oder bei fehlendem TLS auf Klartext zurückfallen. Das kann in anderen Zusammenhängen nützlich sein, trägt aber nicht die Zusage, dass Zonentransfers nie in Klartext erscheinen.

Auch Fallback ist zu unterscheiden. IXFR kann auf derselben authentisierten TLS-Verbindung zu AXFR werden; dann steigen Umfang und mögliche Verkehrssignale, nicht zwingend die Klartextexposition. Ein Wechsel von TLS zu Klartext ändert dagegen die Sicherheitsbehauptung selbst.

Einige negative Tests sind leicht: Transfer ohne TSIG, von einer nicht erlaubten Adresse oder über Klartext. Schwerer ist der Nachweis, dass jeder Secondary unsignierte Daten verwirft, Strict TLS nutzt und seine weiteren Peers ebenfalls schützt. Die Koordination und Durchsetzung dieser gemeinsamen Richtlinie liegt ausdrücklich außerhalb der RFC.

Nach der Zustellung beginnt eine neue Kontrollfläche

Nehmen wir einen korrekten Ablauf an: Primary authentisiert, Secondary autorisiert, TLS 1.3 aktiv, IXFR beendet, neue Seriennummer akzeptiert. Der Pfadbeobachter sieht den Inhalt nicht mehr. Dafür liegt nun eine Zonenkopie in einem weiteren Verwaltungsbereich.

Sie kann in Zonefile, Journal, Datenbank, Snapshot, Backup oder Support-Log vorkommen. Interne Personen und Werkzeuge können zugreifen. Der Betreiber kann sie an weitere Secondaries übertragen. Der autoritative Dienst beantwortet weiterhin beabsichtigte öffentliche Anfragen.

Das sind keine TLS-Fehler. Es sind Folgen der gelungenen Replikation. Deshalb muss der Nachweis auch Speicherorte, lokale Zugriffe, Backup- und Log-Aufbewahrung, weitere Ziele sowie Aufnahme und Entfernung von Peers erfassen. Der Widerruf eines Zertifikats oder TSIG-Schlüssels stoppt die nächste Übertragung, holt aber keine bereits gelieferte Kopie zurück.

ZONEMD zeigt eine weitere Grenze. RFC 8976 definiert einen Digest für ein eigenständiges Zonenobjekt. RFC 9103 nennt ihn komplementär und orthogonal zum Kanal. Ein Digest verbirgt keine Übertragung; ein vertraulicher Kanal beweist nicht Richtigkeit, Aktualität oder menschliche Legitimation des Inhalts.

Das öffentliche DNS bleibt öffentlich

Transferüberwachung und Zonen-Enumeration sind getrennte Wege. NSEC kann das Durchlaufen einer signierten Zone ermöglichen. NSEC3 erschwert es durch gehashte Owner Names, beseitigt aber nicht jede Möglichkeit. Gewöhnliche autoritative Anfragen liefern weiterhin die für die Öffentlichkeit bestimmten Records.

XoT schließt also den hochverdichteten Klartextstrom der Replikation. Es versteckt weder jede Relation noch jeden Namen und bindet einen autorisierten Empfänger nicht nach der Zustellung. Genau diese begrenzte Aussage ist stark, weil sie überprüfbar ist.

Acht Felder für einen Vertraulichkeitsnachweis

Umfang nennt Zone, Richtlinienversion, transfer group und Verantwortliche. Primary-Identität hält Authentisierungsnamen oder SPKI-Pin, Zertifikat, TLS-Version und Endpunkt fest. Secondary-Zulassung enthält mTLS oder ACL plus TSIG/SIG(0), die zonenspezifische Entscheidung und Ablehnungstests.

Transport beschreibt AXoT oder IXoT, Klartextverbot, Fallback und Proxy-Grenzen. Abschluss hält angefragte und akzeptierte Seriennummer, IXFR-zu-AXFR-Wechsel und Fehler fest. Replikverwahrung dokumentiert Speicherung, Zugriff, Backups, Logs und weitere Transfers.

Restexposition umfasst normale Anfragen, NSEC/NSEC3, sichtbare Beziehungen sowie Zeit- und Größensignale. Revalidierung wird durch Änderungen an Zertifikat, Schlüssel, ACL, Proxy, Secondary, Topologie, Signierung oder Betreiber ausgelöst.

Ein TLS-Handshake belegt einen Kanal. TSIG belegt eine Nachricht. Eine akzeptierte Seriennummer belegt Replikzustand. Keiner dieser Nachweise belegt allein die Vertraulichkeit aller Kopien.

Quellen