Zusammenfassung

  • APNICs Oktoberbericht stellt eine Auswertung von Resolver-Signalen nach RFC 8145 aus dem Juli neben neue RFC-8509-Tests auf Endgeräten. Die rund 90 und 70 Prozent beschreiben unterschiedliche Beobachtungswege und lassen sich weder voneinander abziehen noch mitteln.
  • Die Netzwerktabelle ist eine Prüfliste, keine Bereitschaftsnote für einen Anbieter und keine Schätzung betroffener Kunden. Betreiber müssen ihre eigenen validierenden Resolver testen.

Analyse

Ein Prozentwert braucht seinen Beobachtungsweg

Zwei Tage vor dem geplanten Wechsel des DNSSEC-Wurzelschlüssels wirkt eine Bereitschaftsquote wie die entscheidende Antwort. Wenn die meisten Resolver den Nachfolgeschlüssel haben, sollte der Wechsel sicher sein; wenn nicht, sollte ihn jemand stoppen. Das Problem steckt im Wort „die meisten“. Ein Resolver-Signal, ein Test über den Anschluss eines Endgeräts und die Menschen, die auf dieses Netz angewiesen sind, sind keine austauschbaren Einheiten.

APNICs Bericht vom 9. Oktober, am Vortag verfasst, stellt zwei Beobachtungen zu KSK-2024 vor. Die erste nutzt RFC 8145: Validierende Resolver können die Schlüsselkennungen, denen sie vertrauen, in Anfragen signalisieren, die Betreiber autoritativer Server sehen. Die zweite verwendet den Root Key Trust Anchor Sentinel aus RFC 8509. Ein Test wird von einem Endgerät aus gesendet; die Antwort lässt Rückschlüsse auf den Vertrauenszustand des Resolvers zu. Es geht um denselben Schlüssel und denselben Termin, aber nicht um denselben Messgegenstand.

In der Beschreibung von RFC 8145 bleibt ein wichtiger Unterschied stehen. APNIC deutet seine Juli-Grafik so, dass etwa 90 Prozent der meldenden Resolver KSK-2024 hinzugefügt hätten. Verisigns Update vom 28. Juli sagt, die Akzeptanz unter den signalgebenden Quellen habe nach rund 500 Tagen 95 Prozent überschritten. APNIC verweist für die Grafik auf Verisign, doch die öffentlichen Texte nennen keinen gemeinsamen exakten Stichtag und keine einheitliche Messdefinition, mit denen sich die Angaben abgleichen ließen. Möglicherweise beziehen sie sich auf verschiedene Ausschnitte oder Zusammenfassungen; aus dem Text lässt sich das nicht entscheiden.

Das ist eine Dokumentationslücke, kein Beleg für ein fehlgeschlagenes Messverfahren.

Die neueren 70 Prozent sind noch weniger direkt vergleichbar. APNIC zufolge führte ihre werbebasierte Messplattform durchschnittlich rund 16 Millionen Endgerätetests pro Tag aus. Bei etwa 6 Millionen lag das getestete Endgerät hinter einem DNSSEC-validierenden rekursiven Resolver; rund 1,8 Millionen lieferten ein klares Signal für RFC-8509-Unterstützung. Von den Tests, die den Sentinel offenbar unterstützten, meldeten rund 70 Prozent, dass KSK-2024 geladen sei. Der Nenner ist diese getestete Teilmenge mit klarem Signal, nicht alle 16 Millionen Tests, alle validierenden Resolver oder sämtliche Internetnutzer.

Zwei Verfahren, zwei Fragen

RFC 8145 erlaubt einem validierenden Resolver, die Kennungen der Schlüssel in seiner Vertrauenskette zu melden. Die Norm sieht zwei optionale Wege vor: eine EDNS-Option und eine spezielle Anfrage. Bei der Wurzelzone können Betreiber der autoritativen Infrastruktur diese Signale beobachten. Die Daten zeigen, wie sich der gemeldete Schlüsselzustand bei den signalgebenden Quellen verändert.

Sie sagen nicht, wie viele Haushalte, Unternehmen oder Dienste hinter jedem Resolver stehen. Manche rekursiven Resolver versorgen Millionen Nutzer, andere nur eine Organisation oder ein Gerät. Weiterleitende Resolver können ebenfalls beeinflussen, was ein Betreiber der Wurzelserver sieht. Ein Anteil gemeldeter Signale beantwortet also eine Frage zu diesen Signalen, nicht zur Exposition der Nutzer.

RFC 8509 nimmt einen anderen Weg. Der Test sendet speziell geformte DNS-Anfragen; ein unterstützender validierender Resolver reagiert abhängig davon, ob er einem bestimmten Wurzelschlüssel vertraut. APNIC nutzt dafür eine werbebasierte Messplattform mit Endgeräten. Die Beobachtung liegt näher am Auflösungspfad eines getesteten Endgeräts, hängt aber weiterhin von der Unterstützung des Resolvers und der Klassifizierbarkeit der Antwort ab. Sie identifiziert weder alle Resolver hinter dem Gerät noch alle Nutzer, die denselben Resolver verwenden.

Der RIPE-Atlas-Test vom 5. Oktober fügt eine dritte Perspektive hinzu, aber keine vollständige Gegenprobe. Sonden in 2.900 autonomen Systemen zeigten 1.230 Verhaltensweisen, die mit einem geladenen neuen Schlüssel übereinstimmten, und 47, die mit einem nicht geladenen Schlüssel übereinstimmten. Das sind Ergebnisse von Sonden in diesen Netzen. Sie bedeuten weder, dass alle 2.900 Systeme vollständig geprüft wurden, noch zeigen sie die Zahl der Kunden, die von einem Ergebnis abhängen.

Teilweise Messungen bleiben nützlich, wenn klar ist, welche Frage sie beantworten. RFC 8145 zeigt, was signalgebende Resolver an die Wurzel melden; RFC 8509 testet das Verhalten unterstützender Resolverpfade hinter Endgeräten; RIPE Atlas ergänzt anders platzierte Messpunkte. Keines dieser Verfahren liefert allein einen vollständigen, nach Nutzerzahl gewichteten Nenner für das ganze Internet.

Eine Prüfliste ist kein Urteil

Der praktischste Teil von APNICs Bericht ist nicht die globale Quote. Tabelle 3 führt die 50 Netze mit der niedrigsten beobachteten Akzeptanz von KSK-2024 in der vorangegangenen Woche auf. Netze mit weniger als 1.000 Tests, die Sentinel-Unterstützung zeigten, wurden ausgeschlossen. Das macht die Zeilen aussagekräftiger als eine Einzelbeobachtung, aber nicht zu einem Bereitschaftsaudit.

Die Liste enthält Netze aus dem asiatisch-pazifischen Raum, darunter National Telecom in Thailand und Teletalk in Bangladesch. APNIC nennt 48,4 Prozent für National Telecom bei 1.355 Sentinel-unterstützenden Tests und 48,2 Prozent für Teletalk bei 2.046. Diese Werte weisen auf Testkohorten hin, bei denen eine nähere Prüfung sinnvoll sein kann. Sie beweisen nicht, dass alle Resolver der Anbieter denselben Vertrauenszustand haben, dass jede Antwort für eine andere Person steht oder dass derselbe Anteil der Kunden den Zugang verlieren wird.

APNIC empfiehlt den gelisteten Netzen, ihren eigenen Auflösungspfad zu testen, etwa mit der von Cloudflare betriebenen Prüfseite, und die DNS-Einstellungen zu überprüfen. So sollte die Tabelle verwendet werden: als Spur für den Betreiber, nicht als externes Urteil. Ein Anbieter kann mehrere rekursive Dienste betreiben, Teile des Verkehrs weiterleiten oder sich auf vom Hersteller gepflegte Schlüssel verlassen. Die öffentliche Tabelle kann diese Konfigurationen nicht beurteilen.

Der Zeitplan hat drei getrennte Übergänge

Der aktuelle Zeitplan der IANA besagt, dass KSK-2024 am 11. Januar 2025 in der Wurzelzone veröffentlicht wurde. Resolver, die RFC 5011 folgen, sollten einen Monat später beginnen, ihr zu vertrauen. Am 11. Oktober 2026 soll KSK-2024 mit der Signierung der Wurzelzone beginnen, während KSK-2017 nicht mehr signiert. Die Revokation des alten Schlüssels ist für den 11. Januar 2027 geplant, seine Entfernung für den 22. März.

Das sind unterschiedliche Zustände. „Der neue Schlüssel signiert“ bedeutet nicht „der alte Schlüssel ist widerrufen“, und der Widerruf bedeutet nicht, dass er bereits aus der Zone entfernt wurde. Die RFC-5011-Haltefrist gibt einem Resolver Zeit, einen Nachfolgeschlüssel zu beobachten und zu validieren, bevor er ihm automatisch vertraut. Die Existenz des Protokolls beweist jedoch nicht, dass eine konkrete Installation automatische Updates aktiviert, einen beschreibbaren Zustand erhält oder die nötigen Beobachtungen empfangen hat.

Auch die Zuständigkeiten sind verschieden. Die IANA veröffentlicht die Vertrauensanker und den Zeitplan; ICANN/PTI betreibt den Root-KSK-Prozess; Verisign übernimmt unter anderem die Wartung der Wurzelzone und betreibt einen Beobachtungspunkt an einem Root-Server; APNIC veröffentlicht eigene Messanalysen. Für die rekursiven Resolver, die Kunden verwenden, bleibt der jeweilige Netzbetreiber verantwortlich. APNIC liefert Hinweise, kontrolliert aber nicht den Wurzelschlüssel und entscheidet nicht über den weltweiten Wechsel.

Für Betreiber ist die sofortige Prüfung lokal: sicherstellen, dass der eingesetzte Resolver dem richtigen Nachfolgeschlüssel vertraut, testen, ob automatische Updates oder der freigegebene manuelle Weg wirklich funktionieren, und die von Produktionsnutzern verwendeten DNS-Pfade prüfen. Die IANA veröffentlicht die Vertrauensankerdateien; Hersteller dokumentieren ihre jeweiligen Verfahren. Eine öffentliche Messung kann auf mögliche Prüfstellen hinweisen, aber diese Prüfung nicht für ein Unternehmen durchführen.

Die am 9. Oktober verfügbaren Belege stützen eine begrenzte Schlussfolgerung. Der Nachfolgeschlüssel ist seit mehr als einem Jahr veröffentlicht, ein großer Teil der beobachteten Signale und Testpfade meldet ihn als geladen, und APNIC hat Netze für gezielte Nachfragen identifiziert. Die Angaben von 90 Prozent, mehr als 95 Prozent und 70 Prozent ergeben keine einheitliche Bereitschaftskennzahl. Am 11. Oktober lautet die operative Frage, ob ein bestimmter validierender Pfad die neu signierte Wurzel akzeptiert – nicht, welcher dieser Werte die Schlagzeile bestimmt.

Quellen

APNICs Messbericht vom 9. Oktober; Zeitplan für Vertrauensanker und Schlüsselwechsel der IANA; RFC 8145; RFC 8509; RFC 5011; Verisigns Update vom 28. Juli; ICANN-FAQ für Betreiber 2026; Cloudflares KSK-2024-Resolvertest.