DNS-Root-Schlüsselwechsel setzt Vertrauen in KSK-2024 voraus
DNS, das Domain Name System, das Websitenamen in Netzwerkadressen übersetzt, steht am 11. Oktober 2026 vor einer wichtigen Aktualisierung seiner Vertrauensgrundlage: Die Root wird auf einen Ersatz-Signaturschlüssel umgestellt. In ihrem Bericht vom 6. Oktober fordern Sebastiaan Neuteboom und James Godlewski von Cloudflare die Betreiber auf, sicherzustellen, dass ihre DNS-Prüfsysteme KSK-2024 mit dem Key-Tag 38696 vertrauen. Der bisherige kryptografische Algorithmus bleibt bei der Umstellung erhalten. Die Annahme des Ersatzschlüssels ist jedoch unerlässlich, damit die Namensauflösung weiterhin korrekt funktioniert.
Betroffen sind DNSSEC-validierende Resolver. Ein Resolver löst Namen im Auftrag von Nutzern und Anwendungen auf; mithilfe der DNS Security Extensions (DNSSEC) kann er digitale Signaturen prüfen, um die Echtheit von DNS-Informationen festzustellen. Diese Prüfung hängt von einer Vertrauenskette ab, die bis zur Root reicht, der obersten Ebene der DNS-Hierarchie. Ein Root-Schlüsselsignaturschlüssel (KSK) signiert den DNSKEY-Satz der Root, also die veröffentlichte Sammlung ihrer DNS-Prüfschlüssel. Ein Vertrauensanker ist die Schlüsselinformation, die ein Resolver als Ausgangspunkt für diese Prüfungen akzeptiert. Ohne den passenden vertrauenswürdigen Schlüssel kann die Prüfung fehlschlagen, selbst wenn der angefragte Dienst einwandfrei funktioniert.
Die Umstellung am 11. Oktober ändert, welcher KSK diese Root-Schlüsselsammlung signiert. Damit ist die Außerbetriebnahme des bisherigen Schlüssels noch nicht abgeschlossen. Dem Bericht zufolge plant die Internet Corporation for Assigned Names and Numbers (ICANN), KSK-2017 im Jahr 2027 zu widerrufen, ihn aus der Root-Zone – den DNS-Einträgen auf der obersten Hierarchieebene – zu entfernen und seinen privaten Schlüssel zu löschen. Ein privater Schlüssel ist das geheime Schlüsselmaterial, mit dem Signaturen erstellt werden. Die Beendigung der Signierfunktion eines Schlüssels und der Entzug des Vertrauens in ihn sind getrennte Vorgänge. Deshalb reicht der Übergang über den Oktober hinaus.
Für Nutzer verweist der Bericht auf den Bereitschaftstest für Resolver. Er verwendet einen Trust Anchor Sentinel, eine spezielle DNS-Abfrage, die erkennen lassen kann, ob ein Resolver einen bestimmten Root-Schlüssel akzeptiert hat. Der Test prüft außerdem, ob ein regulär signierter Name erfolgreich aufgelöst wird, ob ein Name mit absichtlich ungültigen DNSSEC-Informationen abgelehnt wird und ob der Resolver eine Sentinel-Abfrage zum aktuellen Root-Schlüssel beantwortet. Diese Kontrollprüfungen helfen dabei, ein aussagekräftiges Ergebnis zur Umstellungsbereitschaft von einem Fehler bei der Namensauflösung oder einem Resolver zu unterscheiden, der das Testverfahren nicht unterstützt.
Eine wichtige Einschränkung ist, dass ein nicht eindeutiges Testergebnis nicht belegt, dass der neue Schlüssel fehlt. Lässt sich die Sentinel-Unterstützung nicht bestätigen, kann der Test diese Frage nicht beantworten. Außerdem prüft er den vom Browser verwendeten Resolver. Dessen Auswahl kann durch Secure DNS, eine Browseroption für verschlüsselte DNS-Abfragen, oder durch ein virtuelles privates Netzwerk (VPN) beeinflusst werden, das den Datenverkehr über eine andere Netzwerkverbindung leitet. Cloudflare stellt dem seine Befehlszeilenbeispiele mit dig gegenüber, einem Werkzeug für DNS-Abfragen, die ausdrücklich den Resolver 1.1.1.1 abfragen. Beide Methoden erfassen nur den Resolver-Pfad, über den diese konkreten Anfragen beantwortet werden, nicht sämtliche DNS-Systeme, die eine Organisation möglicherweise nutzt.
KSK-2017 und KSK-2024 verwenden beide RSA/SHA-256, dieselbe Kombination kryptografischer Verfahren zum Erstellen und Prüfen von Signaturen. Es handelt sich um einen Austausch des Schlüsselpaars, nicht um einen Algorithmuswechsel. Cloudflare erinnert daran, 2018 geschrieben zu haben, dass ein erfolgreicher Schlüsselwechsel die Diskussion über einen Algorithmuswechsel eröffnen könnte; acht Jahre später verwendet die Root weiterhin RSA. Dennoch begrenzt der Schlüsselaustausch die Nutzungsdauer eines einzelnen privaten Schlüssels und dient als Übung für die Verteilung neuer Vertrauensanker, Resolver-Aktualisierungen und die Außerbetriebnahme alter Schlüssel. Der Bericht weist darauf hin, dass der erste Schlüsselwechsel gezeigt hat, wie diese betrieblichen Schritte scheitern können, selbst wenn die Kryptografie korrekt funktioniert.
Die Internet Assigned Numbers Authority (IANA) sieht idealerweise einen Abstand von drei Jahren zwischen Schlüsselwechseln vor. Dabei wägt sie regelmäßige betriebliche Übung gegen den Aufwand und das Risiko häufiger Änderungen ab. Der Zeitraum seit 2018 ist länger ausgefallen. ICANN führt diese Verzögerung auf pandemiebedingte Störungen und die Modernisierung der Hardware zurück, die private Signaturschlüssel schützt. Da der Algorithmus unverändert bleibt, können Betreiber die Aktualisierung der Vertrauensanker für sich genommen testen. Ein Algorithmuswechsel bringt eine weitere Anforderung mit sich: Die Resolver-Software muss auch die neue Art von Signatur prüfen können.
Unabhängig davon hat ICANN für die Zukunft einen Wechsel des Root-Algorithmus zu ECDSA P-256 vorgeschlagen, einem digitalen Signaturverfahren auf Basis elliptischer Kurven, das kleinere Schlüssel und Signaturen als RSA erzeugt. Dieser Wechsel ist nicht Teil des Schlüsselaustauschs im Oktober, und es handelt sich dabei nicht um Post-Quanten-Kryptografie, also Kryptografie, die Angriffen mit Quantencomputern widerstehen soll. Laut Cloudflare validiert 1.1.1.1 inzwischen ML-DSA-44-Signaturen, die auf diese Widerstandsfähigkeit ausgelegt sind. Die Unterstützung durch einen Resolver allein kann jedoch nicht die gesamte DNSSEC-Kette quantensicher machen: Signierte Domains, ihre übergeordneten Zonen und die Root müssten dafür allesamt geeignete kryptografische Verfahren einführen.
Auf Root-Ebene würde dieser künftige Übergang einen Post-Quanten-KSK und eine weitere Einführung erfordern, damit die Resolver ihm vertrauen. Mit dem aktuellen Austausch wird daher ein dafür relevanter betrieblicher Prozess geübt, ohne dass er selbst Schutz gegen Quantencomputer bietet. Cloudflare fordert DNS-Anbieter und Resolver-Entwickler dazu auf, RFC 8509, die Spezifikation für Trust Anchor Sentinels, zu implementieren. So können Nutzer die Bereitschaft vor einem Schlüsselwechsel prüfen, statt sich auf eine nicht überprüfbare Annahme verlassen zu müssen.
Für Leser, die überprüfen möchten, wer ihre Namensauflösung übernimmt, bietet AEU DNS private, sichere DNS-Dienste an. Diese Dienstbeschreibung allein belegt allerdings nicht, dass der Dienst für diesen konkreten Schlüsselwechsel bereit ist. Die unmittelbare Aufgabe für alle Betreiber eines DNSSEC-validierenden Resolvers ist konkreter: Sie müssen prüfen, ob er KSK-2024 mit dem Key-Tag 38696 vertraut, und andernfalls den Empfehlungen von ICANN sowie den Anweisungen des Anbieters der Resolver-Software folgen. Nutzer mit einem nicht eindeutigen Testergebnis sollten ihren DNS-Anbieter nach der Sentinel-Unterstützung und der Umstellungsbereitschaft fragen, statt die Ungewissheit entweder als bestätigten Fehler oder als Entwarnung zu interpretieren.