Zusammenfassung

  • RFC 9704 verbindet eine lokal verteilte Erklärung über interne DNS-Zuständigkeit mit einer öffentlich prüfbaren Bestätigung. Die Bestätigung muss die Liste interner Namen nicht offenlegen.
  • Wer einen ganzen Teilbaum freigibt, kann spätere Aktualisierungen der öffentlichen Bestätigung vermeiden. Damit verlagert sich zugleich die Entscheidung über neue Namen innerhalb dieses Bereichs.
  • Öffentlich sichtbar bleibt der Authentifizierungsname des Resolvers. Eine sparsame Veröffentlichung, eine begrenzte Zuständigkeit und der Schutz von Anwendungen sind deshalb drei verschiedene Aufgaben.

Man stelle sich eine Organisation vor, die heute drei interne Dienste betreibt und morgen weitere hinzufügen will. Die zuständige öffentliche DNS-Zone könnte jeden benötigten Bereich einzeln bestätigen. Sie könnte aber auch einen gemeinsamen internen Teilbaum freigeben, unter dem neue Dienste entstehen dürfen. In beiden Fällen könnte die aktuelle Namensauflösung funktionieren. Der Unterschied zeigt sich erst beim nächsten Dienst: Muss dann erneut jemand zustimmen, oder hat die frühere Entscheidung diesen Schritt schon mit abgedeckt?

Das ist ein bewusst vereinfachtes Beispiel, kein Bericht über eine beobachtete Installation. Es führt jedoch zu einer wesentlichen Frage des im Januar 2025 veröffentlichten RFC 9704. Der vorgeschlagene Standard beschreibt, wie ein Client die Zuständigkeit eines lokalen Resolvers für bestimmte Namen überprüfen kann. Zugleich lässt sich an ihm ablesen, wie eine technische Vereinfachung den Ort späterer Entscheidungen verschiebt. Eine dauerhaft unveränderte öffentliche Bestätigung kann sowohl gut gewählte Stabilität als auch weitreichenden, wenig beachteten Spielraum bedeuten.

Zwei Beschreibungen, zwei Empfängerkreise

Split DNS liefert je nach Auflösungskontext unterschiedliche Antworten. Ein Dienstname kann intern auf eine andere Adresse zeigen als außerhalb des Netzes; manche internen Namen sind von außen gar nicht sinnvoll auflösbar. Das allein beantwortet nicht, warum ein Client dem lokalen Resolver für diese Namen folgen sollte. Insbesondere ein Client, der sonst einen eigenen verschlüsselten Resolver verwendet, braucht einen begrenzten Anlass, davon abzuweichen.

RFC 9704 setzt an diesem hybriden Fall an. Der Client nutzt lokale Antworten für bestimmte global verwurzelte Namen und behält für andere Namen eine andere Auflösungsmethode bei. Das Verfahren ist weder eine allgemeine Erlaubnis zum Filtern fremder Domains noch eine Lösung für Clients, die grundsätzlich immer lokal oder immer vollständig unabhängig auflösen. Auch spezielle Namen wie local. und home.arpa. gehören nicht in dieses Validierungsverfahren. Der öffentliche übergeordnete Domainbereich muss mitwirken; der lokale Resolver muss authentifiziert verschlüsselte DNS-Kommunikation unterstützen.

Die lokal verteilte Erklärung nennt den Authentifizierungsnamen des Resolvers, den übergeordneten Domainnamen, die beanspruchten Unterbereiche sowie Hashverfahren und Salt. Für die Beanspruchung des gesamten übergeordneten Bereichs ist eine besondere Sternchenangabe vorgesehen. Die öffentliche Zone veröffentlicht dagegen einen Verifikationsdatensatz: einen TXT-Eintrag mit einem aus der Erklärung berechneten Prüfwert. Sein Eigentümername verbindet den Resolvernamen, _splitdns-challenge und den übergeordneten Domainnamen.

Vor der Berechnung werden die Namen in eine festgelegte kanonische und sortierte Form gebracht. Der übergeordnete Namenssuffix wird entsprechend der Spezifikation ersetzt; Länge und Inhalt des Salts fließen in den Hash ein. Diese Einzelheiten sind nicht bloß Implementierungsdekoration. Wenn zwei Beteiligte dasselbe inhaltliche Vorhaben unterschiedlich kodieren, erhält der Client keine passende Bestätigung. Das Verfahren braucht eine gemeinsame, genaue Beschreibung, obwohl diese nicht an beiden Verteilungsorten vollständig sichtbar sein muss.

Der Salt soll hohe Entropie haben und darf bis zu 255 Oktette lang sein. Er steht auch in der lokalen Erklärung. Er ist also kein Geheimnis gegenüber deren Empfängern. Ebenso ist der Hash weder Verschlüsselung noch digitale Signatur, Passwort oder allgemeiner Beweis vollständiger Geheimhaltung. Die wichtige Eigenschaft ist enger: Die öffentliche DNS-Bestätigung braucht die Liste privater Unterbereiche nicht im Klartext zu veröffentlichen. Daraus folgt nicht, dass Clients, Resolver, Anwendungen oder deren Protokolle diese Namen niemals erfahren.

Der öffentliche Name bleibt eine Veröffentlichung

Gerade diese Trennung macht die verbleibende Offenlegung relevant. Der Authentifizierungsname des Resolvers erscheint im öffentlichen Eigentümernamen des Verifikationsdatensatzes. Wenn eine Organisation darin den Namen eines vertraulichen Projekts unterbringt, beseitigt der gehashte Rest des Verfahrens diese Veröffentlichung nicht. RFC 9704 weist ausdrücklich auf diesen Punkt hin und empfiehlt einen nicht sensiblen Resolvernamen.

Der praktische Gegenstand einer Prüfung ist deshalb nicht allein die Liste interner Dienste. Zu prüfen ist auch die Bedeutung des Namens, mit dem der zuständige Resolver sich ausweist. Eine neutrale technische Bezeichnung und eine sprechende Projektbezeichnung können funktional dieselbe Rolle erfüllen, aber sehr verschiedene Informationen nach außen tragen. Das ist eine Gestaltungsmöglichkeit, keine Behauptung, dass sich aus einem einzelnen Namen zuverlässig Geschäftspläne ableiten ließen.

Verschlüsseltes DNS löst diese Frage nicht nachträglich. RFC 9463 beschreibt die Bereitstellung eines Authentifizierungsnamens zusammen mit Adressen und Dienstparametern für verschlüsselte Resolver. Ein passendes Zertifikat bestätigt dabei die Verbindung zum angegebenen Namen. Es beweist nicht schon die Vertrauenswürdigkeit des Netzes, das diesen Namen geliefert hat. Auch ein Angreifer kann für seinen eigenen Resolver ein gültiges Zertifikat besitzen. Und der Resolver selbst erfährt weiterhin die an ihn gerichteten Anfragen.

Es wäre daher eine Kategorienverwechslung, aus „verschlüsselt erreichbar“ die Zuständigkeit für einen beliebigen internen Namensbereich abzuleiten. RFC 9704 verlangt zusätzlich die überprüfbare Zustimmung des öffentlichen übergeordneten Bereichs. Die in allgemeinen Resolver-Erkennungsverfahren erwähnten Rückfallmöglichkeiten auf unverschlüsseltes DNS ersetzen die Anforderung dieses Verfahrens an authentifiziert verschlüsselte lokale Auflösung nicht.

Eine Bestätigung außerhalb der lokalen Deutungshoheit

Der Client muss den öffentlichen Prüfwert über eine Auflösungsmethode kontrollieren, deren Antworten der lokale Netzbetreiber nicht verändern kann. Sonst könnte dieselbe Stelle eine Zuständigkeit behaupten und die angeblich unabhängige Bestätigung passend dazu liefern. Die zwei Verteilungswege hätten dann unterschiedliche Namen, aber keinen tragfähigen Unterschied in der Kontrolle.

Eine Möglichkeit ist ein bereits konfigurierter externer verschlüsselter Resolver. Dabei gelten dessen übliche Annahmeregeln weiter; eine ausbleibende Antwort innerhalb eines angemessenen Zeitraums macht die Prüfung nicht erfolgreich. Eine andere Möglichkeit ist die vollständige lokale DNSSEC-Validierung. Ein Ergebnis mit dem Status Secure kann verwendet werden. Bogus und Indeterminate werden nicht akzeptiert. Bei Insecure soll eine andere Methode versucht werden; ohne solchen Ausweg scheitert die Prüfung. Die Spezifikation macht aus einem Netzwerkproblem keine stillschweigende Erlaubnis.

Die Bestätigung ist außerdem an den jeweiligen Resolver-Authentifizierungsnamen gebunden. Sie gibt nicht sämtlichen Resolvern im selben Netz freie Hand. Für den Betrieb ist das eine wichtige Begrenzung: Ein erfolgreich getesteter Endpunkt belegt nicht automatisch, dass ein anderer Endpunkt mit anderer Identität dieselbe Zuständigkeit besitzt. Ebenso wenig erteilt die Bestätigung einem Nutzer Zugang zu der Anwendung, deren Namen dieser Resolver auflöst. Anwendungsanmeldung und Zugriffskontrolle bleiben gesondert erforderlich.

Weniger Änderungen können mehr Spielraum bedeuten

Die Spezifikation nennt die Bündelung unter einer untergeordneten Zone als Möglichkeit, die Häufigkeit von Änderungen am Verifikationsdatensatz zu verringern. Dafür müssen nicht bei jeder neuen internen Namensverwendung dieselben öffentlichen Schritte erneut ausgeführt werden. Diese Bündelung ist aber keine Voraussetzung dafür, die Namensliste aus dem öffentlichen TXT-Inhalt herauszuhalten. Vertraulichkeit der Liste und Granularität der Zustimmung sind unterschiedliche Entwurfsentscheidungen.

Die daraus folgende organisatorische Wirkung ist eine redaktionelle Schlussfolgerung: Wird ein größerer Teilbaum bestätigt, liegt mehr künftige Namensgestaltung innerhalb einer schon erteilten Zustimmung. Die Stelle, die neue interne Namen anlegt, erhält dadurch praktische Bewegungsfreiheit. Das kann für einen klar abgegrenzten, gut verwalteten internen Bereich angemessen sein. Es kann aber auch eine eng gedachte Ausnahme ausweiten, wenn niemand festgelegt hat, welche späteren Nutzungen noch dem ursprünglichen Zweck entsprechen.

Man sollte daher weder jede unveränderte Bestätigung als veraltet ansehen noch jede stabile Zone als Beweis guter Kontrolle. Entscheidend ist, ob neue Nutzungen noch innerhalb der bewusst gewählten Grenze liegen. Dafür liefert das Protokoll eine überprüfbare Bereichsangabe, aber keine vollständige Organisationsordnung. Es weiß nicht, welcher Projektleiter über den nächsten Dienst entscheiden sollte.

Die Umstellung hat mehr als einen Takt

Auch eine richtig begrenzte Zustimmung muss aktuell bleiben. RFC 9704 verlangt, den neuen Verifikationsdatensatz zu veröffentlichen, bevor die entsprechende lokale Erklärung geändert wird. Alte Datensätze sollen bestehen bleiben, bis die zugehörige DHCP-Lease oder die Information des Provisioning Domain abgelaufen ist. Bei einer geänderten Erklärung wird ein neuer Salt benötigt. Clients müssen die Prüfung vor dem Ablauf einschlägiger TTL- oder DNSSEC-Signaturgültigkeit erneuern.

Das ist keine Zusage sofortiger weltweiter Widerrufbarkeit. Während einer Umstellung können unterschiedliche Clients noch gültige Informationen verschiedener Generationen besitzen. Wer nur prüft, ob der neue TXT-Eintrag existiert, hat noch nicht gezeigt, dass alle lokalen Empfänger bereits die dazugehörige Erklärung verwenden. Umgekehrt kann eine vorschnelle Löschung der alten Bestätigung den Clients schaden, deren lokale Informationen noch nicht abgelaufen sind.

RFC 8801 liefert den Hintergrund für Provisioning Domains: DNS-Informationen stehen in einem Zusammenhang mit Quellen, Weiterleitung und der jeweiligen Netzkonfiguration; Zusatzinformationen haben eigene Kennungen und Abläufe. Das aktuelle IANA-Register führt splitDnsClaims mit den Feldern resolver, parent, subdomains, algorithm und salt. Diese Eintragung belegt die abgestimmte Syntax, nicht die Verbreitung in Unternehmensnetzen.

Auch externe Sicherheitsleitlinien ziehen eine engere Grenze als das Wort „intern“ nahelegen kann. Der Gateway-Leitfaden von ASD's ACSC warnt davor, IP-abhängige Split-DNS-Sichten als Sicherheitsmechanismus zu behandeln, und verlangt eine Betrachtung des Vertrauens- und Bedrohungsmodells, bevor interne Sichten externen Dienstleistern zugänglich werden. Das ist Orientierung, kein Nachweis einer bestimmten Einführung oder allgemeiner Rechtszwang.

Der Ertrag von RFC 9704 liegt somit in einer präziseren Arbeitsteilung: Eine private Behauptung über Namenszuständigkeit kann öffentlich überprüfbar sein, ohne als öffentliches Namensverzeichnis zu erscheinen. Die Organisation muss dennoch selbst entscheiden, wer die nächste interne Zone anlegen darf, welche Identität dabei sichtbar wird und wie lange alte Zustimmung weiterwirkt. Gerade weil das Protokoll einen Teil der Veröffentlichung vermeidet, lohnt sich ein genauer Blick auf den Teil, der übrig bleibt.