Zusammenfassung

  • Der aktuelle DNSOP-Entwurf beschreibt ein NS-RRSet mit genau einem leeren Ziel, das eine Kindzonengrenze ohne öffentlich nutzbare autoritative Server signalisiert.
  • Damit soll eine öffentlich authentifizierte Nichtexistenz nicht als Wahrheit über eine private DNS-Sicht fortgeschrieben werden, in die ein mobiles Gerät später wechselt.
  • Veröffentlichung des Elternbereichs, beobachtete Referral-Antwort, privater Pfad, Kindautorität, DNSSEC-Prüfung und Anwendungsergebnis bleiben getrennte Belege.

Eine Delegation enthielt zwei Behauptungen

Eine gewöhnliche Delegation erklärt sowohl den Beginn einer Kindzone als auch die Server, über die sie erreichbar ist. Bei Split DNS kann nur die erste Aussage stimmen. example.com liegt im globalen DNS, während corp.example.com ausschließlich über interne Resolver bedient wird. Einen öffentlichen Nameserver zu erfinden, würde die Konfiguration nicht vervollständigen, sondern verfälschen.

Revision 00 trennt die Aussagen durch ein streng geformtes RRSet: ein einzelner NS-Eintrag mit leerem NSDNAME, dargestellt als NS und Punkt. Das bedeutet nicht, dass die Kindzone fehlt. Es bedeutet, dass der Eltern-Namespace eine Grenze kennt, aber keinen autoritativen Server für den weiteren Weg bereitstellt. Ein Gemisch aus normalen NS-Zielen und leerem Ziel ist nach dem Entwurf keine solche Delegation.

Verwandte Konventionen existieren bereits. Null MX erklärt, dass eine Domain keine Mail annimmt. Ein Punkt als SRV-Ziel erklärt den Dienst für nicht verfügbar. AliasMode SVCB nutzt ebenfalls ein leeres Ziel. Diese Beispiele beweisen keine Verbreitung der neuen NS-Semantik; sie zeigen, warum ein ausdrückliches Fehlen präziser sein kann als eine fingierte Adresse.

Der Cache überschreitet die Netzgrenze

Außerhalb des Unternehmens kann ein Gerät einen internen Namen im globalen DNS abfragen. Ein DNSSEC-validierender Resolver erhält eine authentifizierte negative Antwort und speichert sie. Nach dem Wechsel in das interne Netz antwortet eine private Autorität positiv. Wird der alte Beleg als namespace-übergreifende Wahrheit behandelt, erscheint die legitime interne Antwort als bogus.

Der zone cut to nowhere begrenzt die öffentliche Aussage. Der Elternbereich behauptet nicht länger, unterhalb gebe es keine Zone. Er liefert eine Referral-Antwort, deren Kindserver weder auflösbar noch erreichbar sind. Laut Entwurf ist keine Sonderlogik nötig; Resolver behandeln sie wie andere Delegationen mit unerreichbaren Servern. Von außen bleibt die Kindzone unerreichbar.

Entscheidend ist der Grund. Eine authentifizierte Nichtexistenz und eine bestätigte, aber hier nicht begehbare Grenze können für die aktuelle Anwendung gleich enden. Nach einem Netzwechsel haben sie andere Folgen für Cache und Validierung.

Sechs Zustände brauchen sechs Belege

Zuerst steht die Konfiguration: Der Elternbereich enthält exakt das einzelne leere NS-Ziel. DNSSEC kann als zweiter Beleg authentifizieren, was der signierte Elternbereich veröffentlicht hat. Keiner der beiden nennt einen privaten Server.

Der dritte Beleg ist die tatsächliche Beobachtung durch den Resolver samt TTL und Validierungsstatus. Alte Caches oder fehlerhafte Zwischenstellen können Konfiguration und Drahtantwort trennen.

Der vierte Zustand ist die private Pfadauswahl. Nach dem Netzwechsel braucht das Gerät einen internen Resolver oder eine Forwarding-Regel, die die Kindzone erreicht. Das öffentliche leere Ziel findet diesen Pfad nicht und erteilt keinen Zugriff.

Fünftens muss die Kindautorität antworten und gegebenenfalls validieren. Sechstens muss die Anwendung das Ergebnis nutzen und den Dienst erreichen. Eine vorhandene Zonengrenze ist deshalb kein Gesundheitsnachweis des privaten Systems.

DS verbindet Identitäten, keine Leitungen

Kennt der Betreiber des Elternbereichs die Signaturschlüssel der Kindzone, erlaubt der Entwurf DS neben dem leeren NS-Ziel. Ein Resolver kann dann später in der privaten Sicht eine DNSSEC-Vertrauenskette fortsetzen.

Das setzt eine gemeinsame kryptografische Identität voraus. Verwenden verschiedene private Sichten unterschiedliche Schlüssel oder sind manche unsigniert, kann ein einziger öffentlicher DS sie nicht vertreten. Revision 00 rät in diesem Fall von der sicheren Delegation ab.

Selbst der richtige DS wählt keinen internen Resolver, öffnet kein Unternehmensnetz und beweist keinen Anwendungserfolg. Er prüft Daten, die über einen bereits vorhandenen Pfad eintreffen; er erzeugt den Pfad nicht.

Arbeitsdokument und Betrieb sind verschiedene Nachweise

Revision 00 ist ein aktiver Standards-Track Internet-Draft der DNSOP-Arbeitsgruppe vom 23. September 2026. Sie ist weder RFC noch endgültiger IETF-Konsens. Das Beispiel INTERNAL im Root ist ausdrücklich illustrativ und keine Betriebsanweisung an die IANA.

Der Text berichtet von Experimenten ohne Hinweis auf breite Betriebsprobleme, nennt aber inkompatible Softwareannahmen und potenziell schädlichen Root-Traffic als Risiken. Das begründet weitere Tests, nicht ein allgemeines Kompatibilitätsurteil.

Auch ACME DNS-01 begrenzt den Anwendungsfall. Wer vorübergehend öffentliche TXT-Einträge unterhalb der nominell privaten Zone veröffentlicht, kann nicht unverändert behaupten, dort existiere kein öffentlicher DNS-Pfad. Das minimale Signal muss zur realen Ausnahme passen.

Quellen