Zusammenfassung

  • Revision 14 des DNSOP-Entwurfs hält eine Delegation für kontinuierlich, wenn der Parent weiterhin denselben Delegationspunkt meldet und der aktuelle NS-Satz mindestens einen Namen mit dem gecachten Satz teilt. Wurden in beiden Zuständen DS-Daten gesehen, muss außerdem mindestens ein delegierter Signierer übereinstimmen.
  • Ein vollständig neuer NS- oder DS-Satz sowie der Wechsel zwischen leerem und nicht leerem DS bedeutet Autoritätswechsel. Daten am Revalidierungspunkt und darunter dürfen nicht weiter benutzt werden; strikte und opportunistische Verfahren verteilen Ausfall und Rückfall verschieden.
  • Die Schnittmenge ist ein Cache-Kriterium, kein Nachweis des betrieblichen Mandats. Ein Delegations-Übergabebeleg sollte geplante Überlappung, Parent- und Child-Zustand, Provisionierungsbefugnis, drei TTLs, Abbauzeit und Rückfallverantwortung binden. Das ist Daniel Kades Vorschlag, keine IETF-Vorgabe.

Die klassische DNS-Delegation besitzt zwei Darstellungen. Der Parent veröffentlicht Referral-NS, nötigen Glue und bei DNSSEC den DS-Satz. Das Child veröffentlicht am eigenen Apex einen autoritativen NS-Satz. RFC 1034 verlangt Konsistenz an beiden Seiten des Zone Cut. Eine atomare Änderung beider Zonen kennt das Protokoll nicht.

Abweichungen sind deshalb auch ohne Störung möglich. Ein TLD kann lange feste TTLs benutzen, das Child einen kurzen Apex-TTL. Registrar, Registry und DNS-Betreiber arbeiten getrennte Warteschlangen ab. Minimale Antworten enthalten nicht immer den Apex-NS. Normale Anwendungen fragen ihn kaum direkt ab, sodass ein Resolver die autoritative Child-Sicht ohne Zusatzfrage nie lernen kann.

Delegation Revalidation by DNS Resolvers in Revision 14 wurde am 2. September 2026 veröffentlicht. Der Datatracker führt den Text als aktiven DNSOP-Working-Group-Entwurf für den Standards Track mit beabsichtigtem Proposed-Standard-Status; er wartet auf das Go-ahead der Chairs und läuft am 6. März 2027 ab. Er ist keine RFC und kein Einsatzbefehl.

Der optionale Algorithmus verbindet drei Aufgaben. Nach einem Referral fragt der Resolver gezielt nach dem autoritativen Apex-NS des Childs und gibt ihm gemäß RFC 2181 einen höheren Cache-Rang als der nicht autoritativen Parent-Kopie. Er beschafft nach Möglichkeit autoritative A- und AAAA-Daten der Servernamen. Schließlich kehrt er zum Parent zurück, um Entfernung, Redelegation oder vollständigen Autoritätswechsel festzustellen.

Ein Schnittpunkt ist keine Abstimmung

Der Cache merkt sich die vom Parent gesehenen NS-Namen sowie NS- und gegebenenfalls DS-TTL. Bei der Revalidierung muss der Parent erneut an denselben Punkt verweisen. Alter und neuer Parent-NS-Satz müssen mindestens einen gemeinsamen Namen enthalten.

Wenn beide Beobachtungen DS tragen, gilt eine zweite Bedingung: Mindestens ein delegierter Signierer muss gemeinsam sein. Ein verbliebener NS kann also keinen vollständig neuen Signierer-Satz überbrücken. Auch der Übergang von keinem DS zu DS oder zurück gilt als Autoritätswechsel.

Eine Mehrheit ist nicht nötig. Vier alte Server können zu einem alten und drei neuen werden. Beim Schlüsselwechsel kann ein Signierer neben dem neuen bestehen bleiben. Die Regel erlaubt gestufte Umzüge, ohne bei jedem Teilwechsel alle abhängigen Cache-Daten zu verwerfen.

Verschwindet das Referral, ändert sich der Delegationspunkt oder ist der relevante NS- beziehungsweise DS-Satz vollständig neu, müssen Daten an diesem Punkt und darunter unbenutzbar werden. Direkte Löschung und generationenweises Unzugänglichmachen sind möglich; nach außen muss der Cache so handeln, als seien die Daten entfernt.

Der Test bleibt bewusst schmal. Er erkennt nicht, ob der gemeinsame Name zum alten Anbieter, zu einem geteilten Anycast-Dienst, zum Registrar oder zu einer vergessenen Abhängigkeit gehört. Er bestätigt weder Eigentum noch menschliche Genehmigung, Betriebsqualität oder Unversehrtheit. Er entscheidet über Cache-Kontinuität.

Autoritative Child-Daten und Widerruf durch den Parent

Der Child-Apex ist für seinen NS-Satz autoritativ; die Parent-Daten sind Referral. Revision 14 empfiehlt deshalb eine ausdrückliche NS-Abfrage parallel zur auslösenden Auflösung. Nach Erfolg sollen weitere Anfragen die Child-Liste bevorzugen.

Schlägt die Abfrage fehl oder liefert NODATA, bleibt der Parent-Satz die bestplatzierte nutzbare Quelle. Opportunistische Resolver können die Nutzerantwort bereits geliefert haben, bevor diese Prüfung endet.

Doch das Child darf sein Mandat nicht endlos selbst erneuern. Der Parent kann die Delegation entfernt oder einem neuen Betreiber gegeben haben. Wer nur Child-NS auffrischt, kann einem alten Dienst nach der Redelegation treu bleiben. Die Parent-Revalidierung begrenzt dieses Ghost-Domain-Problem.

Glue-Adressen haben eine eigene Herkunft. Sie ermöglichen den ersten Kontakt, sind aber oft nicht autoritativ. Ein vollständiger, signierter und DNSSEC-sicherer Adresssatz kann autoritativ gecacht werden; sonst sind zusätzliche Fragen erforderlich. Wenn bessere Adressen unerreichbar sind, darf niedriger gerankter Glue als letzter Ausweg erhalten bleiben.

Dieser Ausweg schützt Erreichbarkeit. Er verhindert aber, dass eine einzelne NS-Aufnahme den wirklichen Resolverpfad beweist. Rang, Erreichbarkeit, Antwortreihenfolge und Fallback entscheiden mit.

Strikt und opportunistisch sind verschiedene Zusagen

Strikte Revalidierung kann die auslösende Antwort anhalten, bis Name und Adresse autoritativ beschafft sind. Das schützt stärker vor Umleitung und Beobachtung. Ohne Fallback führt ein fehlerhafter Child-NS jedoch zum harten Auflösungsfehler.

Darum empfiehlt der Entwurf strikte Glaubwürdigkeitsaufwertung nur für Root und direkt von ihr delegierte Zonen. Tiefer im Baum gibt es Zonen, die ausdrückliche Apex-NS-Fragen falsch behandeln.

Opportunistische Revalidierung bedient zuerst und lernt für später. Bei einem inkompatiblen Child gibt sie den Algorithmus für diese Zone auf und verwendet das Parent-Referral. Die Verfügbarkeit ist höher, die Schutzwirkung nicht gleich.

Eine Betriebsrichtlinie muss Tiefe, Modus, Fallback-Daten und Löschumfang nennen. Ein allgemeines Merkmal „Revalidierung aktiv“ sagt nicht, wie ein fehlerhafter Übergang ausgeht.

Drei TTLs treffen auf einen lokalen Mindestwert

Spätestens der kürzeste Wert aus Parent-NS-TTL, vorhandenem Parent-DS-TTL und Child-Apex-NS-TTL löst die Revalidierung aus. Der Parent begrenzt die Lebensdauer einer entfernten Delegation; das Child kann eine frühere Neubewertung seines Dienstsatzes verlangen.

Gleichzeitig soll ein Resolver eine vernünftige Mindest-TTL setzen, damit winzige Werte keine rechnerische Dauerlast erzwingen. Der Entwurf nennt keine allgemeine Zahl. Eine kurze veröffentlichte TTL ist daher kein weltweites Versprechen sekundengenauen Widerrufs.

Fehler müssen gemäß RFC 9520 negativ gecacht werden, statt aggressive Wiederholungen auszulösen. Zusätzliche NS- und Adressprüfungen können beträchtlichen autoritativen Verkehr erzeugen. Ein Arbeitslimit pro Anfrage gehört zur Abwehr.

Ein Mismatch-Bericht fällt kein Urteil

Unterscheiden sich Parent- und Child-NS, darf der Resolver über RFC-9567-Kanäle beide Seiten informieren. Revision 14 schlägt einen Extended-DNS-Error vor, dessen Nummer noch TBD ist.

Die Abweichung kann eine geplante Migrationsphase, Queue-Verzögerung oder TTL-Folge sein und muss keinen Ausfall verursachen. Der Bericht belegt eine Beobachtung zu einem Zeitpunkt. Er authentifiziert keine Registrar-Anweisung und erklärt nicht, ob das gemeinsame Mitglied beabsichtigt ist.

Selbst eine erfolgreiche Antwort beweist kein sauberes Mandat. Ein Restserver kann technisch einwandfrei arbeiten, obwohl niemand mehr seine fortdauernde Rolle verantwortet.

Der Übergabebeleg für das verbleibende Mitglied

Beim Wechsel von A zu B kann ein alter NS und ein alter Signierer bewusst als Brücke dienen. Für den Resolver bleibt Autorität kontinuierlich. Für die Betreiber braucht die Brücke ein Ablaufdatum.

Der Beleg trennt Altzustand, Zielzustand und genehmigte Zwischenphase. Er listet Parent-NS und Glue, Parent-DS, Child-Apex-NS und autoritative Adressen. Der gemeinsame NS und gegebenenfalls Signierer werden mit Zweck und Abbaubedingung benannt.

Danach verweist er auf den Kontrollvorgang: Registry- oder Registrar-Referenz, alter und neuer DNS-Betreiber, Freigabe des endgültigen Entfernens und Rückfallverantwortung. Er ersetzt Authentifizierung nicht und speichert keine Zugangsdaten; er macht sie auffindbar.

Die drei TTLs, der kürzeste Trigger und Annahmen über Resolver-Mindestwerte stehen getrennt. Ende der Konfigurationsannahme beim alten Anbieter, Entfernung aus dem Parent, Ende autoritativer Antworten und Ende des Verkehrs sind verschiedene Termine.

Überwachung prüft strikte und opportunistische Pfade. Ist ein vollständig neuer Satz gewollt, werden Cache-Verwerfung und Lastanstieg als geplante Wirkung behandelt. Der Abschluss verlangt Parent-Child-Konvergenz, Entfernung der Brücke, Ende unerwarteter Antworten und ein formell geschlossenes Rollback-Fenster.

Kein Resolver liest diesen Beleg; Revision 14 fordert ihn nicht. Er ergänzt die schmale Protokollfrage um die menschliche: War die gemessene Kontinuität beabsichtigt, befristet und verantwortlich beendet?

Quellen

  1. Delegations-Revalidierung durch DNS-Resolver — Revision 14
  2. Datatracker-Eintrag
  3. Dokumenthistorie
  4. Aktive DNSOP-Dokumente
  5. DNSOP-Charter
  6. RFC 1034 — Domain Names: Concepts and Facilities
  7. RFC 2181 — Klarstellungen zur DNS-Spezifikation
  8. RFC 9520 — Negatives Caching von Auflösungsfehlern
  9. RFC 9567 — DNS-Fehlerberichte
  10. Erweiterbare DNS-Delegation — Revision 11