Zusammenfassung

  • APNICs Ergebnis von rund 70 Prozent gilt für Tests, die das RFC-8509-Sentinelsignal klar ausgesendet haben; Verisigns rund 90 Prozent beziehen sich auf Resolver, die nach RFC 8145 meldeten. Es sind keine zwei Schätzungen derselben Population.
  • Die Root-Zone begann am 11. Oktober 2026 mit KSK-2024 zu signieren. Die öffentlichen Angaben bestätigen den Wechsel und dass keine weitreichende Störung beobachtet wurde; sie zählen aber weder alle Resolver noch einzelne Menschen oder lokale Ausfälle.

Ein Prozentsatz braucht seinen Nenner

Die verlockendste Deutung der Wechselzahlen ist zugleich die am wenigsten belastbare: Wenn etwa 70 Prozent der gemessenen Gruppe dem neuen Schlüssel vertrauten, könnten die übrigen 30 Prozent der Nutzer gefährdet gewesen sein. Diese Schlussfolgerung wechselt den Nenner ohne Beleg. APNIC Labs hat nicht behauptet, alle Resolver oder Menschen gezählt zu haben. Das Ergebnis beschreibt Tests, die eine bestimmte Messfähigkeit erkennen ließen.

Laut APNIC erzeugt das werbebasierte Testsystem ungefähr 16 Millionen Tests täglich. Rund sechs Millionen tägliche Ergebnisse weisen auf einen DNSSEC-validierenden Resolver hin; etwa 1,8 Millionen zeigen das RFC-8509-Sentinelsignal eindeutig. Der Wert von ungefähr 70 Prozent wird innerhalb der Tests berechnet, die dieses Signal offenbar unterstützen und KSK-2024 als Vertrauensanker melden. Ein Test ist eine Beobachtung, keine nachgewiesene Einzelperson. Wiederholte Ereignisse können von denselben Menschen, Netzen oder Resolvern stammen. Die veröffentlichte Methode macht daraus keine bevölkerungsgewichtete Vollerhebung.

Das bleibt nützliche Evidenz. In der messbaren Teilgruppe, die auf diesen Test antworten kann, war der neue Vertrauensanker zum Beobachtungszeitpunkt nicht universell vorhanden. Das kann Muster sichtbar machen und weitere Prüfungen lenken. Der Wert bleibt nur erhalten, wenn die Bedingung beim Prozentwert stehen bleibt.

Verisign beobachtete ein anderes Signal

Die von APNIC zusammengefasste Zahl von rund 90 Prozent stammt aus Verisigns RFC-8145-Meldungen. Ein kompatibler Resolver kann dem Root-Server-System signalisieren, welche Schlüsselkennungen er als Vertrauensanker kennt. Dieser Beobachtungspunkt unterscheidet sich von einer nutzerseitigen RFC-8509-Sentinelanfrage. Die Gruppe umfasst Resolver, die den Meldemechanismus unterstützen und beobachtbare Meldungen erzeugen; sie umfasst definitionsgemäß nicht jeden rekursiven Resolver.

Ein meldender Resolver steht außerdem nicht für einen Menschen. Er kann einen Haushalt, ein Unternehmen, einen Zugangsanbieter oder viele nachgelagerte Netze bedienen. Der verfügbare Bericht nennt keine Nutzerzahl pro Resolver, mit der sich Beobachtungen nach Personen gewichten ließen. Der Abstand zwischen 70 und 90 Prozent belegt daher weder einen Widerspruch noch einen Trend in gleichartigen Stichproben oder einen globalen Zuwachs um zehn Punkte. Protokolle, Einschlussbedingungen, Erhebungszeiträume und Netzpfade unterscheiden sich.

Eine kleine RIPE-Atlas-Messung ist eine dritte Gegenprüfung, aber kein Schiedsrichter zwischen den Prozentwerten. Am 5. Oktober umfassten Probes in 2.900 autonomen Systemen 1.230 Verhaltensweisen, die mit einem geladenen neuen Schlüssel vereinbar waren, und 47, die mit einem nicht geladenen Schlüssel vereinbar waren. Die Stichprobe war begrenzt und nicht nach Nutzern gewichtet. Auch APNICs Tabelle zu Netzen mit niedrigen Akzeptanzraten setzt eine Mindestzahl unterstützender Sentinel-Tests, damit die Ergebnisse besser einzuordnen sind. Dieser Schwellenwert beweist keinen netzweiten Ausfall.

Die Root-Signatur zeigt nicht den lokalen Vertrauenszustand

IANA führt KSK-2024 mit der Schlüsselkennung 38696 als aktiv und seit dem 11. Oktober zum Signieren der Root-Zone eingesetzt. KSK-2017 mit Kennung 20326 befindet sich weiterhin in der Nachveröffentlichungsphase und ist noch ein gültiger Vertrauensanker. Die Widerrufung ist für den 11. Januar 2027, die Entfernung für den 22. März geplant. Das sind getrennte Betriebszustände: Der neue Schlüssel kann signieren, während ein Validator den alten weiterhin als gültigen Vertrauensanker führt.

ICANNs Statusseite sagt, der neue Schlüssel habe am 11. Oktober um 14:00 UTC mit dem Signieren begonnen. In der geprüften Aktualisierung wurden keine Hinweise auf eine weitreichende Betriebsstörung beobachtet; die Überwachung sollte fortgesetzt werden. Das beschreibt das beobachtete Betriebsbild, beweist aber nicht, dass jeder lokale Validator den Schlüssel angenommen hat. Ebenso wenig belegt es, dass es keinen einzelnen Ausfall gab. Umgekehrt beweist ein Test ohne Anzeige des neuen Schlüssels allein keinen fehlgeschlagenen DNS-Aufruf.

Der Ausfallmechanismus ist bedingt. Ein Resolver, der DNSSEC validiert und keinen nutzbaren Vertrauenspfad zur Root besitzt, kann signierte Daten zurückweisen. Ein Resolver ohne DNSSEC-Validierung fällt nicht über diesen spezifischen Mechanismus aus. Auch bei einem Validator hängt das Ergebnis vom lokalen Vertrauensanker, der Konfiguration und dem Abfragepfad ab. Die Root-Signatur beantwortet, welcher Schlüssel die Zone signiert hat; sie verrät nicht den Zustand jedes nachgelagerten Validators.

Was die Messungen tragen

Die Evidenz trägt drei begrenzte Aussagen. Erstens fand der Wechsel wie geplant statt. Zweitens zeigten mehrere Instrumente eine beträchtliche Übernahme, doch jedes beschreibt seine eigene beobachtbare Teilgruppe. Drittens meldete die hier geprüfte Nachwechsel-Aktualisierung keine weitreichende Störung. Nicht belegt sind die Aussagen, 30 Prozent der Nutzer seien gefährdet gewesen, zehn Prozent aller Resolver hätten den Schlüssel verpasst oder die Bereitschaft habe 100 Prozent erreicht.

Es fehlt keine weitere griffige Prozentzahl. Benötigt wird eine belastbare Zuordnung von den Beobachtungen zur Zahl und Verteilung betroffener validierender Resolver und anschließend zu den Nutzern und Diensten dahinter. Dafür braucht es explizite Abdeckung, Deduplizierung, Zeitfenster, Gewichtung und eine Messung des Ergebnisses nach dem Wechsel. Bis dahin muss jede Rate ihren Nenner behalten; der beobachtete Schlüsselstatus ist vom abgeleiteten Nutzereffekt zu trennen.

Quellen