Der Wechsel des DNSSEC-Wurzelschlüssels ist erfolgt: Was Betreiber prüfen sollten

Der Schritt im Oktober 2026 war keine Übergabe des Betriebs der DNS-Root-Zone. Es handelte sich um einen Rollover des Key Signing Key (KSK), der DNSSEC zugrunde liegt: Seit dem 11. Oktober signiert der neue KSK-2024, gekennzeichnet durch den Key Tag 38696, den DNSKEY-Satz der Root Zone. ICANN und IANA hatten den Austausch als Teil eines 2024 begonnenen, schrittweisen Übergangs geplant. Gewechselt hat ein kryptografischer Schlüssel, nicht die Betriebsverantwortung.

Diese Unterscheidung ist wichtig. Die Root Zone bleibt der oberste Bezugspunkt in der DNS-Hierarchie; ihr Betrieb ging durch diesen Wechsel nicht an eine neue Organisation über. Geändert wurde der kryptografische Schlüssel, den validierende Resolver als Vertrauensanker verwenden, um die Root Zone und über sie die DNSSEC-Kette zu überprüfen.

Der Zeitplan von ICANN sah vor, dass der neue Schlüssel am 11. Oktober 2026 mit der Signierung beginnt. Die Ausmusterung des alten Schlüssels war für eine spätere Phase vorgesehen, voraussichtlich im Januar 2027. Am 9. November 2026 ist das Hauptereignis also bereits erfolgt, der Wartungszyklus des Schlüssels aber noch nicht abgeschlossen. Praktisch relevant ist das vor allem für Systeme, die DNSSEC mit veralteten oder manuell gepflegten Einstellungen validieren.

Das DNS ordnet Domainnamen hierarchisch. An der Spitze steht die Root Zone, die Verweise auf Top-Level-Domains wie .com, .org oder länderspezifische Endungen sowie auf die dafür zuständigen Server veröffentlicht. Ein Root-Server speichert nicht die IP-Adresse jeder Website: Er weist den Resolver auf die nächste Stufe der Suche hin.

Findet ein rekursiver Resolver keine Antwort in seinem Cache, kann er eine der Root-Identitäten abfragen. Die Antwort verweist ihn auf den Server der betreffenden TLD; anschließend fragt der Resolver bei den autoritativen Servern der Domain weiter. Ist die Information bereits im Cache, kann die Anfrage ohne Kontakt zur Root Zone beantwortet werden. Die Root Zone ist daher nicht bei jedem Aufruf einer Webseite beteiligt.

Wichtig ist außerdem die Unterscheidung zwischen den 13 benannten Root-Identitäten von A bis M und den physischen Rechnern, die sie bereitstellen. Das System ist über zahlreiche Instanzen und unabhängige Betreiber verteilt; ICANN beschreibt 13 Identitäten, die von 12 Betreibern verwaltet werden, sowie mehr als 1.500 einzelne Server. Redundanz und Anycast-Routing ermöglichen die Beantwortung von Anfragen an verschiedenen Standorten. Sie machen aber nicht jede Instanz zu einem eigenen Betreiber und beseitigen auch nicht die Koordination der Root Zone.

DNSSEC ergänzt kryptografische Signaturen, damit ein validierender Resolver die Authentizität und Integrität von DNS-Daten prüfen kann. Der Root-KSK validiert den DNSKEY-Satz der Root Zone; weitere Schlüssel in dieser Zone werden in der Kette verwendet, mit der Verweise auf Top-Level-Domains überprüft werden. Der neue Schlüssel verändert weder die Domainstruktur noch die Einträge von Websites: Er erneuert den kryptografischen Ausgangspunkt dieser Prüfung.

KSK-2024 wurde am 11. Januar 2025 in der Root Zone veröffentlicht, sodass Resolver mit automatischen Trust-Anchor-Aktualisierungen genügend Zeit hatten, den Schlüssel zu übernehmen. Am 11. Oktober 2026 begann er, die Root Zone zu signieren. Der vorherige Schlüssel KSK-2017 ist nicht mit dem neuen zu verwechseln: Der Beginn der Signierung und die endgültige Entfernung eines Schlüssels sind getrennte Schritte.

Der Austausch bedeutet keine Umstellung auf einen anderen kryptografischen Algorithmus. ICANN und Cloudflare beschreiben KSK-2017 und KSK-2024 als Schlüssel, die RSA/SHA-256 verwenden. Der aktuelle Rollover erprobt und erneuert daher die Verteilung des Vertrauens; er bedeutet nicht, dass die Root Zone auf Post-Quanten-Kryptografie umgestellt wurde. Ein Algorithmuswechsel würde zusätzliche Kompatibilität der Resolver erfordern und wäre ein eigener Prozess.

Die meisten Menschen müssen weder am Smartphone noch am Computer oder Router etwas ändern. Wer Resolver des Internetanbieters oder eines öffentlichen DNS-Dienstes nutzt, ist darauf angewiesen, dass deren Betreiber Software und Vertrauensanker aktuell halten. Ein Wechsel des DNS-Servers ist nicht nötig, nur weil der KSK erneuert wurde.

Die Arbeit betrifft vor allem Betreiber rekursiver Resolver mit DNSSEC-Validierung, insbesondere wenn sie manuelle Vertrauensanker pflegen, alte Software einsetzen oder Geräte verwalten, die lange offline waren. Vertraut ein Resolver KSK-2024 nicht, kann er die Validierung korrekt signierter Antworten ablehnen. Für Nutzer dieses Resolvers kann sich das dadurch äußern, dass manche Namen nicht aufgelöst werden, obwohl die Websites und ihre Server funktionieren.

Eine SERVFAIL-Antwort beweist für sich genommen nicht, dass der neue Schlüssel fehlt; auch andere Konfigurations- oder Validierungsprobleme können sie verursachen. Entscheidend ist der Vertrauensstatus, den der Resolver tatsächlich verwendet, nicht allein das Auftauchen des Schlüssels in einer DNS-Antwort. ICANN nennt für KSK-2024 den Key Tag 38696. Betreiber sollten ihn mit den Verfahren und Trust-Anchor-Dateien ihrer Software abgleichen und den alten Schlüssel nicht außerhalb des offiziellen Zeitplans manuell entfernen.

Die Erneuerung des KSK betrifft die kryptografische DNSSEC-Validierung. Die Antwortzeit einer Anfrage hängt unter anderem vom Standort des Resolvers, den Internet-Routen und davon ab, ob die Antwort im Cache liegt. Aus dem Rollover allein lässt sich keine allgemeine Verbesserung der Latenz ableiten.

DNSSEC soll dabei helfen, nicht authentische oder veränderte DNS-Antworten zu erkennen. Der Schlüsselwechsel erneuert den kryptografischen Ausgangspunkt für die Validierung der Root Zone.

Der Ablauf stimmt die Veröffentlichung eines neuen Schlüssels, seine Übernahme durch Resolver und die Ausmusterung des alten Schlüssels aufeinander ab. Der erste Root-KSK-Rollover fand 2018 statt; der aktuelle Übergang ist der zweite. Validierende Systeme benötigen gültige Vertrauensanker, um die Root Zone zu überprüfen. Diese Mechanismen ergänzen einander; sie sind nicht austauschbar.

Wer einen Resolver mit DNSSEC-Validierung betreibt, sollte prüfen, ob die Konfiguration KSK-2024 (Key Tag 38696) vertraut und die Aktualisierung der Vertrauensanker funktioniert. Maßgeblich sind die Dokumentation der installierten Softwareversion und der dauerhaft gespeicherte Dienststatus: Dass der Schlüssel in der öffentlichen Zone vorhanden ist, bedeutet nicht automatisch, dass die Software ihn als Vertrauensanker übernommen hat.

Bei Geräten, die Resolver von Drittanbietern verwenden, ist es sinnvoll, bei anhaltenden Auflösungsfehlern den Dienststatus oder Hinweise des Anbieters zu prüfen. Ändern Sie keine Domain-Einträge und deaktivieren Sie DNSSEC nicht als erste Reaktion auf SERVFAIL, ohne zuvor den Ort des Validierungsfehlers einzugrenzen. Die Ursache kann beim Resolver, in einer bestimmten Zone oder an einer anderen Stelle der Kette liegen.

Der nächste Schritt im ICANN-Zeitplan ist die für Januar 2027 vorgesehene Ausmusterung von KSK-2017. Bis dahin sollten Betreiber und Anbieter den offiziellen Anweisungen folgen und die üblichen Sicherheitsupdates einspielen. Für Endnutzer ist die Botschaft einfacher: Die Verbindung muss nicht neu konfiguriert werden; der Rollover muss in der Infrastruktur umgesetzt werden, die DNS-Anfragen validiert.