Zusammenfassung

  • Eine Beobachtung vom 13. September zeigt: Das IPv6-Glue für .ps in der Root-Zone entspricht nun der aktuellen Adresse des RIPE-NCC-Nameservers. Bei .ne, .sd und .tj gilt das weiterhin nicht.
  • RIPE NCC erklärte, IANA könne die Anträge ohne Zustimmung der jeweiligen ccTLD-Kontakte nicht bearbeiten. Vier technisch verwandte Einträge sind deshalb vier getrennte Autorisierungsvorgänge.
  • Ein Ausfall ist nicht belegt. Für jede Delegation bestanden weitere IPv6- und mehrere IPv4-Glue-Pfade. Nötig ist ein datensparsamer Vorgangsbeleg, der Status und Ergebnis jeder Delegation ausweist.

Man kann eine offene Liste führen und trotzdem die falsche Vorstellung von Arbeit haben. Im August standen vier alte IPv6-Glue-Adressen darauf. Im September sind es drei. Nicht ein Viertel eines Stapels wurde erledigt; ein eigenständiger Delegationsvorgang hat ein anderes Ergebnis erreicht.

Am 15. August meldete Patrik Wallstrom in der DNS Working Group von RIPE, die Root-Zone enthalte noch alte IPv6-Glue-Werte für ne.cctld.authdns.ripe.net, ps.cctld.authdns.ripe.net, sd.cctld.authdns.ripe.net und tj.cctld.authdns.ripe.net. RIPE NCC hatte bereits im Januar das IPv6-Renumbering seines AuthDNS-Dienstes für abgeschlossen erklärt: Das bisherige /48 sei vollständig zurückgezogen, der Großteil der Bereinigung erledigt.

Die Antwort von RIPE NCC vom 20. August benannte die verbleibende Grenze. Die Organisation hatte E-Mail, Telefon und regionale Kontakte genutzt und Anträge bei IANA eröffnet. Ohne Zustimmung der Ansprechpartner der ccTLDs konnten diese jedoch nicht bearbeitet werden. Die Pflege der Delegationsdaten in der Root-Zone liegt beim jeweiligen TLD-Manager.

Diese Hürde schützt mehr, als sie verzögert. Der Betreiber eines Nameservers kennt seine neue Adresse. Er darf deswegen noch nicht allein die Delegation ändern, für die eine andere Stelle verantwortlich ist.

Ein Eintrag ist konvergiert

Die eingefrorene Messung lief am 12. September um 17:14 UTC, in Shanghai bereits am 13. September. Sie verglich Referrals von a.root-servers.net und b.root-servers.net mit den Namensantworten von 1.1.1.1 und 8.8.8.8.

Für .ps gaben beide Root-Server 2a13:27c0:30::105 als Glue zurück. Beide rekursiven Resolver lieferten dieselbe aktuelle AAAA-Adresse für ps.cctld.authdns.ripe.net. Auch die IANA-Delegationsseite von .ps zeigte diesen Wert; ihr seitenweites Aktualisierungsdatum war der 8. September.

Bei den anderen drei Delegationen blieb der Unterschied sichtbar. Für .ne lieferte die Root-Zone 2001:67c:e0::101, die aktuelle Namensantwort hingegen 2a13:27c0:30::101. Bei .sd standen 2001:67c:e0::109 und 2a13:27c0:30::109 gegenüber, bei .tj 2001:67c:e0::117 und 2a13:27c0:30::117. Die IPv4-Werte stimmten jeweils überein: 193.0.9.101, .109 und .117.

Fest steht damit nur, was die Beobachtung trägt: Aus vier Abweichungen im August waren drei geworden. Sie verrät weder, wer die Änderung für .ps beantragte oder genehmigte, noch ab wann die Root-Zone sie auslieferte. Ein Datum für die ganze IANA-Seite kennzeichnet kein bestimmtes geändertes Feld. Das unterschiedliche Ergebnis passt aber zum beschriebenen Autorisierungsweg je Delegation.

Redundanz ist ein Schutz, kein Freibrief

RIPE NCC wies darauf hin, dass jede der vier Delegationen mindestens einen weiteren funktionierenden IPv6-Glue-Eintrag und mehrere funktionierende IPv4-Glue-Einträge hatte. Resolver konnten der Delegation folgen und Namen auflösen. Ein alter Wert allein belegt daher keinen Ausfall einer ccTLD.

Diese Untersuchung schickte keine Pakete an die alten IPv6-Adressen. Sie maß weder Erreichbarkeit noch Wiederholungsverzögerung oder Nutzerauswirkung. Sie belegt keine lahme Delegation, keinen DNSSEC-Fehler, keinen Resolver-Ausfall und keinen Verlust des autoritativen Dienstes. Umgekehrt beweisen alternative Pfade nicht, dass jeder Resolver sie ohne Verzögerung nutzte.

Beide Aussagen gehören zusammen: Redundanz bewahrte Kontinuität; ein Verweis auf ein zurückgezogenes Präfix sollte dennoch korrigiert werden. Der falsche Schritt wäre, für schnellere Bereinigung die Zustimmung des TLD-Managers zu umgehen.

Ein Abschluss von 2025 ist kein Live-Status

IANAs Root-Operations-Audit für Juli 2025 führt Nameserver-Änderungsanträge zu allen vier Hostnamen auf. Sie wurden am 18. Juli 2025 als Administratively Closed markiert. Die öffentliche Tabelle nennt nicht für jeden Vorgang einen Grund. Diese Einträge sind historische Ergebnisse, keine aktuellen Zustände der später von RIPE NCC erwähnten Anträge; sie erklären auch nicht die Konvergenz von .ps.

Die öffentlichen Nachweise bleiben getrennt. Das Audit zeigt das Ende eines alten Antrags. Die Delegationsseite zeigt veröffentlichte Daten. Eine DNS-Abfrage hält eine Antwort zu einem Zeitpunkt fest. Keines dieser Dokumente verbindet Antragstellerrolle, Zustimmung des Managers, technische Prüfung, Abschlussgrund und beobachtetes Root-Ergebnis zu einem Vorgang.

Vier Delegationen brauchen vier Belege

Ein datensparsamer Beleg könnte TLD, Nameserver, alte und beantragte Adresse, Antragstellerrolle sowie eine öffentlich unbedenkliche Vorgangsnummer enthalten. Dazu gehören Autorisierungsstatus und -zeitpunkt, Ergebnis der technischen Prüfung, Implementierung, Rücknahme, Schließung oder Ablösung sowie eine Kategorie für den Grund.

Root-Zonen-Seriennummer oder Beobachtungszeit, aktuell ausgeliefertes Glue, nächster Schritt und ein Nachfolgeantrag schließen die Kette. Namen und private Korrespondenz müssen nicht veröffentlicht werden. Entscheidend ist, „wartet auf Zustimmung“ von „technisch abgelehnt“, „zurückgezogen“ oder „umgesetzt“ unterscheiden zu können.

Das Protokoll der DNS Working Group bei RIPE 91 bezeichnete das Renumbering als betriebliche Verbesserung und hielt den Plan fest, nach Abschaltung weiterhin an die alten IPv6-Adressen gesendete Anfragen zu erfassen. Solche Messungen zeigen Restnutzung. Der Vorgangsbeleg zeigt die Autorität und Entscheidung, die sie beendet.

Die sichtbare Zahl ist drei. Verantwortet werden müssen weiterhin vier einzelne Fälle.

Quellen