Zusammenfassung

  • Delegationsdaten liegen beim Parent und beim Child. Beide NS-Kopien können unterschiedliche TTLs tragen; eine kürzere Child-TTL löscht keinen bereits mit der Parent-TTL gefüllten Cache.
  • RFC 9199 berichtet von ungefähr 90 Prozent child-zentrierten und 10 Prozent parent-zentrierten Resolvern in der untersuchten Stichprobe. Auch Adress-Caches verhalten sich je nach Bailiwick unterschiedlich.
  • Die alte Infrastruktur muss mindestens bis zum Maximum aus Parent- und Child-TTL betriebsbereit bleiben. Für den Rückbau zählen zusätzlich letzter möglicher Cache-Fill, A/AAAA-Laufzeiten und die letzte Beobachtung des alten Pfads je Resolverklasse.

Die zweite Uhr gehört einem anderen Betreiber

Eine DNS-Delegation ist kein einzelner Datensatz an einer einzigen Stelle. Der Parent veröffentlicht NS-Einträge, die zum Child führen. Das Child liefert anschließend seine eigene NS-Sicht. Die Namen sollen übereinstimmen; ihre Cache-Laufzeiten müssen es nicht.

Für den Zonenbetreiber ist vor allem die Child-TTL sichtbar und veränderbar. Die de-facto-TTL beim Parent liegt häufig außerhalb seiner Kontrolle. RFC 9199 nennt das Beispiel von TLD-NS-Einträgen in der Root-Zone mit zwei Tagen Laufzeit, obwohl eine TLD in ihrer eigenen Zone einen wesentlich kürzeren Wert ausgeben kann.

Giovane Moura, Wes Hardaker, John Heidemann und Marco Davids untersuchten, welche Laufzeit reale Resolver bei solchen Abweichungen nutzen. RFC 9199 fasst zusammen: Etwa 90 Prozent wirkten child-zentriert, rund 10 Prozent parent-zentriert. Das ist kein ewiges Marktverhältnis. Es zeigt aber, dass ein Minderheitenpfad eine reguläre Betriebsbedingung ist.

Wer den alten Server nach der kurzen Child-TTL abstellt, kann deshalb einen Teil der Nutzer verlieren. Deren Resolver hält noch eine gültige Parent-Delegation, findet am Ziel aber keinen Dienst mehr. Im Mittel bleibt die Migration erfolgreich; der Fehler erscheint nur bei bestimmten Netzen, Providern und Füllzeitpunkten.

Eine neue TTL erreicht keinen alten Cache

Die TTL ist keine Fernsteuerung. Sie wird einem Datensatz beim Eintritt in den Cache mitgegeben. DNS bietet dem autoritativen Betreiber keinen Befehl, alle schon gespeicherten Kopien zurückzurufen oder ihre Restlaufzeit zu verkürzen. Der niedrigere Wert wirkt bei künftigen Füllungen, nicht rückwirkend.

Vor einer geplanten Änderung die TTL zu senken, bleibt sinnvoll. Allerdings muss zuerst der kleine Wert auf jeder relevanten Veröffentlichungsfläche wirksam werden. Danach muss die letzte mögliche Füllung unter dem alten langen Wert auslaufen. Erst dann folgt der Wechsel. Eine Stunde beim Child ersetzt nicht 48 Stunden beim Parent.

RFC 9199 formuliert daher eine Mindestregel: Die alte Infrastruktur bleibt mindestens bis zum größeren Wert von Parent- und Child-TTL eingeschaltet und funktionsfähig. Das Maximum ist eine Planungsuntergrenze, kein automatischer Freigabeschein. Der tatsächliche Parent-Updatezeitpunkt, der letzte Old-Value-Fill und eigenständige Adress-Caches gehören ebenfalls in den Nachweis.

Lange TTLs haben gute Gründe. Sie beschleunigen Antworten aus dem Cache, senken autoritative Last und Kosten und überbrücken kurze Ausfälle. Kurze TTLs erleichtern Umzüge, Lastverteilung und manche Umleitungen. Unsicher wird nicht die Abwägung, sondern die Annahme, die Entscheidung des Child gelte zugleich für Parent und Resolver.

NS und Adresse haben getrennte Verfallsdaten

Ein NS-Eintrag liefert einen Namen. Um ihn anzusprechen, braucht der Resolver zusätzlich eine A- oder AAAA-Adresse. Deren Herkunft entscheidet über eine weitere Cache-Grenze.

Liegt der Nameserver im Bailiwick des Child, kann der Parent Glue mitliefern, damit keine zirkuläre Auflösung entsteht. Nach den in RFC 9199 beschriebenen Messungen fragten die meisten Resolver die in-bailiwick-Adresse neu ab, sobald NS auslief und Glue wieder gebraucht wurde — selbst wenn die ursprüngliche Adress-TTL länger aussah.

Bei einem out-of-bailiwick-Namen wird die Adresse gewöhnlich auf einem unabhängigen Auflösungspfad ermittelt und separat gecacht. Das Ende der NS-TTL beendet deshalb nicht zwingend die alte A/AAAA-Laufzeit. Ein neuer NS-Name und ein tatsächlich neuer Zielendpunkt sind zwei verschiedene Beobachtungen.

Das Migrationsprotokoll muss alte und neue NS-RRsets bei Parent und Child, alle Adressen, NS-/A-/AAAA-TTLs, Bailiwick-Klasse, Wirksamkeitszeit und letzten möglichen Fill jedes alten Werts enthalten. Eine einzige Angabe „TTL 3600“ entfernt genau die Verzweigung, die über den sicheren Rückbau entscheidet.

RFC 2181 ordnet die Glaubwürdigkeit von DNS-Daten nach ihrer Herkunft. Daraus entsteht kein globales Überschreibungsrecht des Child. Der Parent ist für seine Zone und die Delegation autoritativ, das Child für seine Zonendaten. Der Resolver behält Quelle, Kontext und Restlaufzeit nach seinen Regeln.

Ein Rückbau braucht den letzten alten Beleg

Der Nachweis beginnt vor dem Umschalten. Beide RRset-Versionen, Adressen, TTLs und Veröffentlichungszeiten werden eingefroren. Daraus folgt der letzte mögliche Füllzeitpunkt unter jeder alten Laufzeit. Beide Endpunkte bleiben während dieses Fensters gesund; ein nur eingeschalteter, aber nicht antwortender Altserver ist kein Sicherheitsnetz.

Messungen müssen unterschiedliche Resolverfamilien und Netze erfassen. Pro Beobachtung gehören Implementierung oder Anbieter, Version soweit bekannt, Zeitpunkt, Antwortquelle, Rest-TTL und erreichter autoritativer Endpunkt in das Protokoll. Die erste neue Antwort beweist nur, dass der neue Pfad existiert. Die letzte alte Antwort pro Klasse markiert die relevante Auslaufkante.

Auch ein leerer Altserver-Graph ist nur ein Indiz. Vielleicht gab es im Messfenster keinen passenden Nutzer oder die Abdeckung war unvollständig. Ein großer öffentlicher Resolver steht nicht für alle Implementierungen. Unbekannte Parent-Zustände, Cache-Regeln und eine mögliche Serve-Stale-Policy bleiben ausdrücklich offen.

Nach der Abschaltung folgt eine eigene Abnahme: Delegation beziehen, Adresse auflösen und einen autoritativen Endpunkt aus den vereinbarten Resolverklassen erreichen. Die neue Veröffentlichung war die Anweisung. Beobachtete Nichtnutzung des alten Pfads ist die Quittung.

Gemeinsame Autorenschaft, verteilte Verfügungsmacht

RFC 9199 nennt Moura, Hardaker, Heidemann und Davids als Autoren. Das Dokument ist Informational im Independent Stream, weder IETF-Konsens noch Internet Standard. Hardakers gespeichertes IETF-Profil stellt den Beitrag in den Kontext von DNS-Forschung, langjähriger IETF-Arbeit und Mithilfe beim B-root-Betrieb. Es macht ihn nicht zum Alleinautor oder Entscheider über Resolver.

Heng Lus Agency-Prinzip trennt die Rollen: Der Parent-Betreiber kontrolliert seine Delegation, das Child seine Kopie, Resolverentwickler und -betreiber das Cache- und Bailiwick-Verhalten, das Infrastrukturteam die Abschaltung. Kein Akteur kann den Zustand der anderen versprechen.

Die frühen DNS-Spezifikationen schaffen einen interoperablen Mindestkern und lassen spätere Entscheidungen lokal. Diese Offenheit braucht Working-Code-Belege. Resolver-Traces, autoritative Logs und zeitlich gefasste Veröffentlichungen zeigen, welcher Zweig in einer konkreten Migration tatsächlich lief.

Ein gemeinsames Ledger koordiniert, ohne allgemeine Macht zu erhalten. Es hält Parent-Uhr, Child-Uhr, Adressuhren und Abschaltakt in derselben prüfbaren Zeile. Der Altserver bleibt nicht aus Scheu vor Veränderung, sondern weil ein gültiger Cache noch Anspruch auf ein erreichbares Ziel hat.

Quellen