Zusammenfassung

  • draft-ietf-dnsop-ns-revalidation-14 lässt Resolver den autoritativen NS-Satz am Child-Apex bevorzugen, verlangt aber die rechtzeitige Rückfrage beim Parent. Sonst könnte ein ehemaliges Child seine entzogene Autorität durch eigene Antworten fortlaufend verlängern.
  • Ein belastbarer Nachweis verbindet Parent-Referral, NS- und DS-Überlappung, die kürzeste der drei stützenden TTLs, die Ungültigerklärung nachgelagerter Cache-Daten und eine neue Auflösung. Eine erfolgreiche Antwort ersetzt diese Kette nicht.

Die alte Infrastruktur war nicht ausgefallen

Die Delegation war administrativ umgestellt. Die neue DNS-Plattform war bereit. Dennoch schickte ein rekursiver Resolver Anfragen an die alten Server. Sie hielten weiterhin Zonendaten, antworteten schnell und setzten das Autoritativ-Bit.

Wer nur Verfügbarkeit maß, sah keinen Fehler. Wer nur den Parent prüfte, sah die neue Delegation. Wer den warmen Cache benutzte, erhielt die alte Wirklichkeit. Keine dieser Beobachtungen war zwingend erfunden; sie beschrieben lediglich verschiedene Ebenen.

Revision 14 von draft-ietf-dnsop-ns-revalidation vom 2. September 2026 macht daraus eine Resolverpflicht. Das Dokument ist ein aktiver DNSOP-Arbeitsgruppenentwurf mit beabsichtigtem Proposed-Standard-Status, wartet auf die Freigabe der Arbeitsgruppenvorsitzenden und steht bei der IESG als I-D Exists. Es ist kein RFC und kein Beleg für die Konfiguration eines bestimmten produktiven Resolvers.

Sein Kern ist dennoch eindeutig: Das Child kann beweisen, welche Daten es autoritativ ausliefert. Nur die aktuelle Parent-Kette kann beweisen, dass diese Autorität noch delegiert ist.

Zwei NS-Sätze ohne gemeinsame Transaktion

An einer klassischen Zonengrenze veröffentlicht der Parent den Delegations-NS-Satz, während das Child am eigenen Apex einen autoritativen NS-Satz führt. RFC 1034 verlangt organisatorische Konsistenz, bietet aber keine atomare Synchronisierung zwischen beiden Zonen.

Nach RFC 2181 besitzt der Child-Satz höhere Glaubwürdigkeit als die nicht autoritativen Referral-Daten des Parents. Das ist sinnvoll: Der Child-Betreiber kennt seine Server und kann mit kürzerer TTL schneller wechseln, selbst wenn der Parent nur eine lange feste Delegations-TTL zulässt.

Der Entwurf empfiehlt daher, beim Überschreiten einer neu entdeckten Zonengrenze den Apex-NS-Satz ausdrücklich abzufragen und im Cache zu bevorzugen. A- und AAAA-Adressen aus Glue oder Additional Data sollen, soweit möglich, ebenfalls neu und autoritativ ermittelt werden. Bei einer sicheren Delegation lässt sich die NS-Abfrage parallel zur DNSKEY-Abfrage senden.

Die Aufwertung beantwortet jedoch nur, welche Infrastruktur das Child selbst nennt. Sie beantwortet nicht, ob der Parent dieses Child weiterhin auswählt. Dürfte das Child beides bestätigen, könnte ein abgelöster Betreiber den Nachweis seiner eigenen Berechtigung unbegrenzt auffrischen.

Drei Zeitgrenzen statt eines Cache-Timers

Die Revalidierung muss spätestens nach der kürzesten TTL des delegierenden Parent-NS-Satzes, des vorhandenen Parent-DS-Satzes und des Child-Apex-NS-Satzes stattfinden.

Jede Zeitgrenze gehört zu einer anderen Beziehung. Die Parent-NS-TTL begrenzt die Delegationsroute. Die DS-TTL begrenzt die Beziehung zum delegierten Signierer. Die Child-NS-TTL begrenzt die Aktualität der vom Child beschriebenen Servergruppe. Die kürzeste Frist verhindert, dass eine lange TTL die Macht einer anderen Ebene verlängert.

Ein Resolver sollte zugleich eine vernünftige Mindest-TTL setzen, damit eine Zone mit extrem kurzen Werten keine rechenintensive Dauerrevalidierung erzwingt. Diese Untergrenze ist eine lokale DoS-Abwehr. Sie beweist nicht, dass die Delegation während der Verlängerung unverändert blieb.

Ein auditierbarer Datensatz muss deshalb die drei Rohwerte, die lokale Untergrenze, den Empfangszeitpunkt und die tatsächlich verwendete Frist speichern. Eine einzige Anzeige „Cache gültig bis“ verschleiert, welche Autoritätsbeziehung abgelaufen ist.

Überlappung bewahrt nur begrenzte Kontinuität

Bei der Rückfrage muss der Parent weiterhin ein Referral zum selben Revalidierungspunkt liefern. Der neue Parent-NS-Satz muss mindestens einen Servernamen mit dem zuvor gespeicherten Satz teilen. Waren vorher und nachher DS-Sätze vorhanden, müssen sie mindestens einen delegierten Signierer gemeinsam haben.

Fehlt das Referral, verweist die Antwort auf eine andere Zonengrenze oder sind NS beziehungsweise DS vollständig neu, hat sich Hierarchie oder Autorität geändert. Auch der Übergang zwischen leerem und nicht leerem DS-Satz zählt als Änderung.

Das Überlappungskriterium erlaubt gestaffelte Migration. Ein Server oder Signierer kann während des Austauschs der übrigen Elemente bleiben. Die Schnittmenge bescheinigt aber keine vollständige Gleichheit der Konfiguration und schon gar nicht identische Adressen, Schlüssel, Inhalte oder Anwendungsergebnisse.

Sie ist eine Sicherheitsentscheidung des Caches, keine Entscheidung über Eigentum oder Vertrag. Ein bekannter Name bildet eine Brücke; er ist nicht die ganze Autoritätskette.

Mit dem oberen Beleg fallen die unteren Ergebnisse

Erkennt der Resolver eine veränderte Hierarchie oder Autorität, darf er Cache-Daten am Revalidierungspunkt und darunter nicht mehr benutzen. Direkte Löschung, Generationenwechsel oder verzögerte Bereinigung sind möglich; nach außen muss sich der Cache so verhalten, als seien die Daten entfernt.

Das betrifft nicht nur NS. Unter der alten Delegation können Hostadressen, Mail-Routing, Service Discovery, negative Antworten und tiefere Delegationen liegen. Sie weiterzuverwenden hieße, Schlussfolgerungen ohne aktuelle stützende Autorität zu behalten.

Darum ist eine Prüfung von der Root-Zone abwärts effizienter. Eine Änderung weiter oben kann sämtliche tieferen Prüfungen überflüssig machen. RFC 8020 zeigt, wie eine NXDOMAIN-Aussage Namen unterhalb eines Punktes betrifft. Bei der Revalidierung gilt die andere Richtung der Abhängigkeit: Ändert sich der obere Beleg, verlieren tiefe Cache-Einträge ihre bisherige Grundlage, obwohl ihre Bytes noch vorhanden sind.

Speicherzustand ist kein Benutzungsrecht.

Strikte Prüfung kann Verfügbarkeit bewusst opfern

Im strikten Modus kann der Resolver die auslösende Antwort zurückhalten, bis Name und Adresse des antwortenden Servers autoritativ erworben wurden. Mit signierten und validierten Infrastrukturdaten sinkt das Risiko von Umleitung und Mitlesen.

Ohne Rückfall auf niedriger eingestufte Daten gibt es jedoch keine Fehlertoleranz. Ein defekter Child-NS-Satz oder ein Server, der ausdrückliche Apex-NS-Abfragen falsch behandelt, führt zum harten Ausfall. Revision 14 empfiehlt deshalb, die strikte Aufwertung auf Root und direkt von ihr delegierte Zonen zu beschränken.

Der opportunistische Modus kann die auslösende Antwort vor Abschluss der Prüfung liefern und auf Parent-Referral-Daten zurückfallen. Beantwortet das Child die NS-Abfrage fehlerhaft, soll der Resolver das Verfahren für diese Zone aufgeben. Die Verfügbarkeit steigt, der Schutz ist aber nicht gleichwertig.

Ein einzelnes Merkmal „Revalidierung aktiv“ ist damit irreführend. Betreiber müssen festhalten, ob eine Antwort auf den Beleg wartete, vorher ausgeliefert wurde, einen Fallback nutzte oder in einem Hard Failure endete, und wann die Cache-Generation tatsächlich wechselte.

DNSSEC signiert nicht jede Infrastrukturangabe

Referral-NS-Sätze, Glue sowie zusätzliche A- und AAAA-Adressen sind gewöhnlich nicht DNSSEC-signiert. Manipuliert ein Angreifer eine ungeschützte Adresse, kann er einen eigenen Server als autoritativ erscheinen lassen und anschließend weitere ungeschützte Referral-Daten unterhalb beeinflussen.

RFC 5452 erschwert gefälschte Antworten durch stärkere Transaktionszuordnung und Entropie. Revalidierung behandelt eine andere Frage: Bleiben Glaubwürdigkeit und Parent-Unterstützung der verfolgten Infrastruktur nach der Transaktion bestehen?

Auch eine gültige DNSSEC-Signatur ist ein begrenzter Beleg. Sie beweist nicht, dass der Resolver rechtzeitig zum Parent zurückkehrte, das Ergebnis anwandte, alle Nachfahren ungültig machte oder die Anwendung den beabsichtigten Dienst erreichte.

Ein Fehlercode erklärt, aber bewirkt nichts

Der Entwurf beantragt einen Extended-DNS-Error-Code für einen Referral-NS-RRset-Mismatch. RFC 8914 ermöglicht eine präzisere Diagnose. Der Code kann erklären, warum der Resolver einen Pfad ablehnte. Er aktualisiert weder Parent noch Child, synchronisiert keine fremden Caches und bestätigt keine Wiederherstellung.

Als Beleg muss der EDE mit der genauen Parent-Antwort, den verglichenen Sätzen, Resolverversion, Modus, TTLs, Ungültigerklärung und nachfolgenden Auflösung verbunden bleiben. Allein ist er ein Etikett.

RFC 9471 grenzt die Notwendigkeit von Glue in Referrals ab. Eine für Erreichbarkeit nötige Adresse ist trotzdem kein Nachweis aktueller Delegationsmacht; Erreichbarkeit ist auch kein Serviceergebnis.

Implementierungsangaben sind keine Bestandsaufnahme

Der Anhang von Revision 14 nennt opportunistische Revalidierung in Unbound über harden-referral-path, standardmäßig deaktiviert, sowie die Implementierung von Abschnitt 7 seit Version 1.4.17. Knot Resolver revalidiere seit Version 1.5.1 die Priming-Antwort der Root-Zone. Für den strikten Modus seien außerhalb von Prototypen und Werkzeugen der Autoren keine Implementierungen bekannt.

Das belegt eine Geschichte laufenden Codes, nicht die aktive Konfiguration einer Instanz, heutige Distributionsvorgaben, Verbreitung, Erfolgsquote oder Interoperabilität. Dokumentierte Fähigkeit und beobachtetes Verhalten bleiben getrennte Tatsachen.

Der notwendige Delegationsbeleg

Ein belastbarer Datensatz enthält Resolver-Build und wirksame Konfiguration, strikten oder opportunistischen Modus, ursprüngliches Parent-Referral mit NS, DS, Glue und Zeit, Child-Apex-NS, neu ermittelte Adressen, alle drei TTLs und lokale Untergrenze, die Kette von der Root-Zone, frische Parent-Antwort, NS- und DS-Schnittmenge, Leer/Nichtleer-Wechsel des DS, ungültig gemachte Cache-Generation und Reichweite, Fallback, Fehler oder EDE, neu gewählten Server und eine unabhängige Servicebeobachtung.

DNS wird dadurch nicht synchron. Der Beleg verhindert etwas Wichtigeres: Ein alter Server darf weiter antworten, ohne dass seine fortgesetzte Sprache automatisch als fortgesetzte Autorität gilt.

Quellen