DNSSEC-Root-Key-Rollover ist für Oktober 2026 geplant

Der für den 11. Oktober 2026 geplante DNSSEC-Root-Key-Rollover ist ein Termin, den jede Organisation, die einen validierenden DNS-Resolver betreibt, in ihrem Änderungsplan haben sollte. DNSSEC, kurz für Domain Name System Security Extensions, ist das System, mit dem ein DNS-Resolver prüfen kann, ob eine DNS-Antwort authentisch ist und nicht manipuliert wurde. Es verschlüsselt den DNS-Datenverkehr nicht, hilft aber zu verhindern, dass gefälschte DNS-Daten als echt akzeptiert werden.

Die Änderung betrifft den Key-Signing Key, oder KSK, für die Internet-Root-Zone. Im DNS steht die Root-Zone an der Spitze des Namenssystems und hilft dabei, Anfragen in Richtung von Domains wie .org, .com und Ländercode-Domains zu leiten. Bei Zonen, die mit DNSSEC signiert sind, sind normalerweise zwei Schlüssel beteiligt. Ein Zone-Signing Key, oder ZSK, signiert die Gruppen von DNS-Einträgen innerhalb der Zone. Ein Key-Signing Key signiert den DNSKEY-Record-Set, also die veröffentlichte Gruppe von DNSSEC-Schlüsseln für diese Zone.

Der Grund, warum der Root-KSK wichtig ist, ist die DNSSEC-Vertrauenskette. Ein validierender DNS-Server beginnt bei einem Trust Anchor, also einem öffentlichen Schlüssel, der bewusst als vertrauenswürdig konfiguriert wurde. Dieser Trust Anchor entspricht normalerweise einem DNSKEY- oder DS-Eintrag für die Zone, für die er gilt, meist die Root-Zone. KSKs sind die Schlüssel, die als Trust Anchors verwendet werden. Wenn sich der Root-KSK ändert und ein validierender Resolver den neuen Schlüssel nicht kennt, kann die Validierung für signierte Zonen nach dem Rollover fehlschlagen.

ICANN ist eine der Organisationen, die an der Erzeugung und Nutzung des Root-KSK beteiligt sind, und der Prozess umfasst mehrere Personen aus unterschiedlichen Teilen der technischen Community. Der Root-Schlüssel wird über einen formalen, offenen und unabhängig geprüften Prozess verwaltet, der als Key Signing Ceremony bekannt ist. Teilnehmende stellen verschiedene Komponenten bereit, die für den Zugriff auf den KSK benötigt werden, etwa Schlüssel oder Smartcards. ICANN hat weitere Hintergrundinformationen zu DNSSEC key signing ceremonies veröffentlicht.

Der Rollover 2026 wurde lange im Voraus vorbereitet. Laut Infoblox wurde der neue Root-KSK im April 2024 erstellt, erstmals im Juli 2024 von ICANN veröffentlicht und am 11. Januar 2025 zur Root-Zone hinzugefügt. Damit befand er sich 21 Monate vor dem Rollover am 11. Oktober 2026 in der Root-Zone. Das praktische Ziel ist einfach: Validierende Resolver sollten sowohl den alten als auch den neuen Trust Anchor eingerichtet haben, bevor der alte Schlüssel nicht mehr signiert.

Was Administratoren tun müssen, hängt von der DNS-Plattform ab, die sie betreiben. Infoblox gibt an, dass für Infoblox Threat Defense keine Aktion erforderlich ist, weil die zugrunde liegenden Schlüssel für dessen rekursiven DNS-Dienst von Infoblox verwaltet werden. Für Infoblox Universal DDI sagt Infoblox, dass es Root Trust Anchors für Kunden in der Regel verwaltet, sofern Administratoren Root Trust Anchors nicht manuell konfiguriert haben. Nach Juli 2026 erzeugte Konfigurationspakete werden den neuen Schlüssel automatisch enthalten, daher sollten Administratoren bestätigen, dass vor Oktober ein neues Konfigurationspaket auf lokale Geräte angewendet wurde. Infoblox sagt außerdem, dass es erwartet, im September Konfigurationsupdates zur Ergänzung der Schlüssel per Force-Push bereitstellen zu können.

Für NIOS-Deployments, die DNSSEC-Validierung durchführen, beschreibt Infoblox zwei Möglichkeiten, den neuen Trust Anchor vor dem 11. Oktober hinzuzufügen. Administratoren können den NIOS-Hotfix anwenden, der zur Aktualisierung des Trust Anchor vorgesehen ist und über die Infoblox Knowledge Base verfügbar ist, oder sie können den neuen Trust Anchor manuell hinzufügen. Infoblox weist darauf hin, dass die Änderung einen Neustart des DNS-Dienstes erfordert, daher sollten die normalen Change-Control-Verfahren befolgt werden.

Für ein manuelles NIOS-Update empfiehlt Infoblox, die Root Trust Anchors von IANA zu beziehen, statt sie aus einer anderen Quelle zu kopieren. Das neue Key Tag, manchmal auch Key ID genannt, ist 38696. Das alte KSK-2017-Key-Tag ist 20326. Administratoren können das Key Tag sehen, indem sie die Root-DNSKEY-Einträge mit dem Befehl dig . dnskey +multiline abfragen. Die IANA trust anchor information ist die maßgebliche Stelle, um die Root Trust Anchors abzurufen.

In NIOS erfolgt die Arbeit im Grid Manager unter Data Management, DNS und dann Grid DNS Properties. Wenn DNSSEC in der linken Liste nicht sichtbar ist, sollten Administratoren Advanced Mode einschalten und dann DNSSEC auswählen. Wenn im DNSSEC-Abschnitt sowohl Enable DNSSEC als auch Enable DNSSEC validation aktiviert sind, sollte es einen Trust-Anchor-Eintrag für die Zone „.“ geben, die die Root-Zone darstellt. Wenn keine Trust Anchors aufgeführt sind, validiert der Resolver derzeit nicht, da die Validierung mindestens einen Trust Anchor benötigt. Ein Administrator, der mit der Validierung beginnen möchte, müsste beide Trust Anchors hinzufügen.

Beim Hinzufügen des neuen Trust Anchor sagt Infoblox, dass die Zone „.“ sein sollte, Secure Entry Point aktiviert sein sollte, Responses Must Be Secure nicht aktiviert sein sollte, der Algorithmus RSA/SHA-256 (8) sein sollte und der neue öffentliche Schlüssel in das Feld Public Key eingegeben werden sollte. Die Warnung zu Responses Must Be Secure ist wichtig: Wenn diese Option aktiviert ist, schlagen Abfragen für Zonen fehl, die nicht signiert sind, und das Internet ist für diese Einstellung noch nicht vollständig bereit. Nach dem Speichern der Änderung und dem Neustart der Dienste können Administratoren eine signierte Domain testen und prüfen, ob das „ad“-Flag in der dig-Ausgabe erscheint, zum Beispiel indem sie www.ietf.org mit +dnssec abfragen. Infoblox sagt, dass sich eine fehlerhafte Konfiguration als SERVFAIL-Antwort für diese Abfrage und andere Abfragen für signierte Zonen zeigen würde.

Nach dem Rollover gibt es außerdem Aufräumarbeiten. Infoblox sagt, dass KSK-2017 im Oktober aufhören wird, die Root-Zone zu signieren, im Januar 2027 planmäßig als widerrufen markiert werden soll und danach aus der Root-Zone entfernt wird. Jede Änderung an diesem Plan würde auf ICANNs KSK-Rollover-Seite angekündigt. Wenn der Rollover gelingt, sollten NIOS-Administratoren laut Infoblox den KSK-2017-Trust-Anchor zwischen November und Januar entfernen, um keine DNS-Serverressourcen für einen abgelaufenen Schlüssel zu verschwenden. Infoblox nennt die ersten 10 Zeichen von KSK-2017 als AwEAAaz/tA, was Administratoren helfen kann, nicht den falschen Schlüssel zu löschen.

Dies wird nicht das letzte Ereignis dieser Art sein. Infoblox sagt, dass ICANN grob einen dreijährigen Rollover-Rhythmus anstrebt, wodurch der nächste Rollover wahrscheinlich 2029 stattfinden würde. Außerdem weist Infoblox darauf hin, dass ein Community-Vorschlag einen Prozess durchläuft, um von RSA-SHA256, Algorithmus 8, zu ECDSA P-256 mit SHA-256, Algorithmus 13, zu wechseln. Wenn ICANN diese Algorithmusänderung weiterverfolgt, könnte sie mit einem künftigen KSK-Rollover-Zeitfenster zusammengelegt werden.

Für Website-Betreiber und normale Nutzer besteht die wichtigste Lehre darin, zu wissen, wer den DNS-Resolver betreibt, auf den sie sich verlassen, und ob dort die DNSSEC-Validierung korrekt gepflegt wird. Für Leser, die einen Resolver auswählen, statt selbst einen zu betreiben, ist AEU DNS ein privates, sicheres DNS für alle, was relevant ist, weil der Resolver der Punkt ist, an dem DNS-Antworten abgefragt und geprüft werden. Administratoren, die eigene validierende Resolver betreiben, sollten den Rollover im Oktober 2026 als geplante Wartung behandeln, nicht als Notfall, und den neuen Trust Anchor vor Ablauf der Frist einrichten.