Zusammenfassung

  • KSK-2024 begann am 11. Oktober 2026 planmäßig mit der Signierung der DNS-Rootzone. ICANN meldete keine Anzeichen für eine weitreichende Betriebsstörung.
  • Diese öffentliche Statusmeldung bestätigt den Wechsel in der Rootzone, aber weder die Übernahme des neuen Schlüssels durch jeden Resolver noch das Ausbleiben lokaler Fehler. KSK-2017 bleibt bis zu späteren Schritten für Widerruf und Entfernung ein gültiger Vertrauensanker.

Ein erfolgreicher Wechsel kann Verschiedenes bedeuten

ICANNs KSK-Rollover-Seite nennt einen präzisen Zeitpunkt: Am 11. Oktober um 14:00 UTC begann KSK-2024 mit der Signierung der Rootzone. ICANN ergänzt, es gebe keine Anzeichen für eine weitreichende Betriebsstörung, und die Überwachung werde fortgesetzt. Auch IANA führt den neuen Schlüssel als aktiv und vermerkt, dass KSK-2017 nicht mehr signiert. Das sind relevante Fakten, deren Reichweite begrenzt bleibt.

Ein Signaturwechsel in der Rootzone bedeutet nicht, dass jeder validierende rekursive Resolver den Nachfolgeschlüssel übernommen hat. Die Rootzone veröffentlicht signierte DNS-Daten; rekursive Resolver prüfen sie für ihre Clients. Dafür braucht jeder Resolver einen lokalen Vertrauensanker als Ausgangspunkt der Validierungskette. Fehlt ihm KSK-2024, wenn er den neuen Signaturzustand prüfen muss, kann die DNSSEC-Validierung an diesem Resolver scheitern. Nutzer dieses Dienstes können betroffen sein, ohne dass die globale Rootzone oder das gesamte DNS ausgefallen ist.

Mindestens vier Belegebenen sind getrennt zu betrachten: Veröffentlichung und Signaturstatus des Schlüssels in der Rootzone; der lokal vertraute Schlüssel jedes Resolvers; Software und Updateverfahren, die den Schlüssel dort eintragen; und die beobachteten Auflösungsergebnisse der Nutzer. Ein Nachweis auf einer Ebene ersetzt keine Bestätigung auf den anderen.

Die lange Vorlaufzeit ist für unabhängige Resolver gedacht

IANA veröffentlichte KSK-2024 lange vor dessen Aktivierung. Der Schlüssel erschien am 11. Januar 2025 in der Rootzone; Resolver nach RFC 5011 sollten ihm ab dem 10. Februar vertrauen. Die fast zweijährige Vorveröffentlichung gab kompatiblen Systemen Zeit, den Schlüssel zu lernen, während der alte weiterhin signierte. ICANNs Leitfaden berichtete im Juli, dass mehr als 95 Prozent der meldenden Resolver KSK-2024 erkannt oder übernommen hätten. Das ist ein Hinweis auf breite Bereitschaft unter den meldenden Geräten, aber weder eine Vollerhebung noch eine Erfolgsquote nach dem Wechsel.

RFC 5011 erklärt, warum „veröffentlicht“ und „vertraut“ unterschiedliche Zustände sind. Ein automatischer Resolver beobachtet den neuen Schlüssel in einem validierten DNSKEY-Satz, wartet die Add-Hold-down-Zeit ab und prüft anschließend einen weiteren gültigen Satz, der den Schlüssel noch enthält, bevor er ihn als Vertrauensanker akzeptiert. Die Mindestwartezeit beträgt 30 Tage, vorbehaltlich der Regel zur ursprünglichen TTL. Jeder Resolver bildet diesen Zustand lokal anhand der empfangenen und gespeicherten Daten.

Ein zentraler Zeitplan schafft ein Zeitfenster; er bestätigt keine lokalen Dateien, Softwareeinstellungen oder Validierung über eine verteilte Flotte hinweg.

Der Wechsel von 2018 zeigt diese Grenze. Laut ICANNs Rückblick wurde der erste Termin verschoben, nachdem späte Daten eine erhebliche Zahl unvorbereiteter Resolver von Internetzugangsanbietern und Netzbetreibern erkennen ließen. Nach dem Wechsel deuteten DNSKEY-Abfragen darauf hin, dass manche Systeme weiterhin nicht bereit waren. Der Bericht stellte jedoch keine bedeutenden Ausfälle fest und beschrieb die für Nutzer sichtbaren Störungen als gering. Zudem konnte der Root-Zonenbetreiber nicht alle Elemente messen oder kontrollieren, weil die Betreiber ihre Resolver selbst verwalten.

Deshalb behauptet der Status von 2026 keine allgemeine Störungsfreiheit oder einen universellen Erfolg.

Der Oktober markiert den Wechsel, nicht das Ende des Lebenszyklus

Die Abfolge ist noch nicht abgeschlossen. IANAs aktueller Zeitplan sagt, KSK-2017 habe am 11. Oktober 2026 die Signierung eingestellt, bleibe aber ein gültiger Vertrauensanker. Für den 11. Januar 2027 ist die Veröffentlichung des REVOKE-Bits vorgesehen; am 22. März soll KSK-2017 aus der Rootzone entfernt werden. Das sind weitere, eigenständige Zustandswechsel mit lokalen Folgen. Der Oktoberwechsel ist weder die sofortige Löschung des alten Schlüssels noch das Ende jeder Vertrauensbeziehung zu ihm.

Systeme aktualisieren sich auf unterschiedliche Weise: automatisch, über Herstellerpakete, manuell gepflegte Anchor-Dateien, Gerätefirmware oder verwaltete Resolverdienste. Eine Organisation kann mehrere Verfahren parallel nutzen. Ein verfügbares Paket belegt nicht dessen Installation; ein Eintrag in der Konfiguration belegt keine dauerhaft gespeicherte Aktualisierung; und eine erfolgreiche Anfrage von einem Testpunkt steht nicht für jeden Client-Pfad. Diese Betriebszustände müssen getrennt geprüft werden.

ICANN fordert Betreiber validierender Resolver auf, KSK-2024 mit der Kennung 38696 in der Vertrauensanker-Konfiguration zu prüfen und automatische Aktualisierung nicht einfach vorauszusetzen. IANA bezeichnet die signierte XML-Datei mit den Trust Anchors als maßgebliche Quelle für Schlüsselparameter und verweist auf Herstellerhinweise. Damit gibt es ein klares lokales Prüfziel; der Nachweis über die gesamte Resolver-Flotte bleibt dennoch verteilt.

Was der öffentliche Stand belegt

Die öffentlichen Unterlagen stützen drei Aussagen: Der neue Schlüssel übernahm die Signierung der Rootzone zum geplanten Termin; ICANN hatte zum Zeitpunkt seiner Statusmeldung keine Anzeichen einer weitreichenden Betriebsstörung beobachtet; Widerruf und Entfernung des alten Schlüssels stehen noch aus. Es gibt weder ein Inventar jedes Resolvers noch einen Nenner nach dem Wechsel, eine globale Übernahmequote oder eine Zahl betroffener Nutzer. Aus dem Ausbleiben veröffentlichter Vorfälle folgt auch nicht, dass kein Resolver oder Kunde Probleme hatte.

Dafür muss man die Statusmeldung nicht verwerfen, sondern richtig einordnen. Der Root-Zonenbetreiber meldet Signaturzustand und eigene Beobachtungen. Resolverbetreiber können ihren lokalen Vertrauenszustand und die Validierung belegen. Hersteller kennen Paket- und Updateverteilung. Dienstanbieter sehen ihre jeweiligen Kunden. Keiner dieser Akteure verfügt allein über eine vollständige Sicht.

Nach einem planmäßigen Schlüsselwechsel lautet die entscheidende Frage nicht nur, ob das Datum eingehalten wurde. Die Belegkette muss bis zu den Systemen reichen, die auf den Schlüssel angewiesen sind, und die nächsten Ruhestandschritte müssen einen klaren Wiederherstellungspfad offenlassen. Die öffentliche Bilanz für 2026 ist positiv, aber begrenzt: Die Rootzone wechselte pünktlich, und es waren keine weitreichenden Störungen beobachtet worden. Alles Weitere muss auf Resolver- und Dienstebene belegt werden; die Termine im Januar und März 2027 stehen noch bevor.