Am Sonntag, dem 11. Oktober 2026, tauscht ICANN den obersten Schlüssel im DNSSEC-System aus. Der bisherige Root-KSK mit dem Key Tag 20326 geht in Rente, sein Nachfolger KSK-2024 trägt den Key Tag 38696.

Ich rechne nicht damit, dass bei den meisten von euch an diesem Tag irgendetwas passiert. Ganz entspannt sehe ich das Thema trotzdem nicht. Wenn irgendwo im Netz ein Resolver DNSSEC selbst prüft und den neuen Schlüssel nicht kennt, liefert er innerhalb von zwei Tagen nach dem Wechsel keine Antworten mehr. Und dann geht nichts mehr, was einen Namen auflösen muss.

Deshalb hier der Versuch, das Thema einmal sauber aufzudröseln: was technisch passiert, warum es Firmen und Verwaltungen etwas angeht und was ich bis zum Stichtag prüfen würde.

Wie DNSSEC der Root-Zone vertraut

Normales DNS glaubt jede Antwort, die plausibel aussieht. DNSSEC hängt an die Einträge digitale Signaturen, und jede Zone bestätigt den Schlüssel der Zone darunter. Wer www.example.de prüft, läuft die Kette über example.de und .de bis nach oben zur Root.

Dort oben muss man irgendwem einfach glauben. Dieser Jemand ist der Root-KSK. Ein validierender Resolver hat ihn fest in der Konfiguration stehen, als sogenannten Trust Anchor. Wer mit Zertifikaten arbeitet, kennt das Prinzip vom Stammzertifikat im Windows-Zertifikatsspeicher: Fehlt es, bricht alles darunter zusammen.

In der Root-Zone arbeiten zwei Schlüssel. Der Zone Signing Key (ZSK) signiert die eigentlichen Einträge und wechselt alle drei Monate, ohne dass es jemand merkt. Der Key Signing Key (KSK) signiert nur die Schlüssel, also auch den ZSK. Er bleibt jahrelang im Einsatz, und genau der wird jetzt getauscht.

Warum überhaupt gewechselt wird

Ein Schlüssel, der nie getauscht wird, ist ein Risiko. Nicht unbedingt, weil er morgen geknackt wird, sondern weil beim Wechsel alle Abläufe verlernt sind und die Software nie damit getestet wurde.

Den ersten Rollover gab es im Oktober 2018. Damals ging bei einigen Betreibern etwas schief, und ICANN hat daraus einen festen Dreijahresrhythmus gemacht, der sich wegen der Pandemie verschoben hat. 2026 ist der erste Durchlauf nach diesem Plan.

KSK-2024 steht seit Januar 2025 in der Root-Zone. Resolver, die ihre Trust Anchors nach RFC 5011 selbst aktualisieren, hatten also rund 21 Monate Zeit. Das ist deutlich großzügiger als 2018. Gerade deshalb fürchte ich, dass viele das Thema längst abgehakt haben, ohne es je geprüft zu haben.

Was am Stichtag passiert

Ab dem 11. Oktober signiert KSK-2024 den Schlüsselsatz der Root. Resolver, die ihn schon kennen, merken davon nichts.

Ein Resolver, der nur den alten Schlüssel kennt, fällt nicht sofort aus. Die DNSKEY-Einträge der Root haben eine TTL von 48 Stunden. Solange die alten, bereits geprüften Schlüssel im Cache liegen, läuft alles normal. Erst wenn der Cache abläuft und der Resolver nachlädt, kann er die neue Signatur nicht mehr prüfen. Ab dann gibt es auf validierte Anfragen nur noch SERVFAIL.

Den genauen Zeitpunkt kann niemand vorhersagen. Er liegt irgendwo zwischen Sonntag und Dienstag. Meine Wette: In den meisten Häusern fällt es am Montag gegen halb acht auf.

Wie sich ein Ausfall anfühlt

Das Unangenehme ist, dass nichts auf DNSSEC hindeutet. Webseiten laden halb, Bilder fehlen, Outlook holt keine Mails mehr ab. Irgendein Fachverfahren meldet, der Lizenzserver sei nicht erreichbar. Automatisierte Jobs sterben meist zuerst, und zwar still.

Richtig verwirrend wird es, wenn Clients mehrere Resolver eingetragen haben und nur einer davon vorbereitet ist. Dann klappt die Auflösung mal und mal nicht, und zwei Kollegen im selben Büro erleben völlig verschiedene Dinge. Da sucht man erst einmal beim Proxy, beim Provider oder am Switch, bevor man an einen Schlüsselwechsel in der Root-Zone denkt.

Und noch ein Punkt, den man leicht vergisst: Wenn der eigene Resolver ausfällt, kommt meist auch keine Mail mehr an. Wer einen warnen will, muss anrufen.

Warum das Admins in Firmen und Verwaltungen angeht

Windows-Clients validieren DNSSEC nicht selbst, und große öffentliche Resolver sind vorbereitet. Für die allermeisten Arbeitsplätze ist das Thema damit erledigt.

Die Probleme sehe ich woanders, nämlich bei Systemen, an die seit Jahren niemand gedacht hat. Der Unbound auf der Firewall, den ein Dienstleister 2019 eingerichtet hat. Das Pi-hole mit dem Trust Anchor, der fest in der Konfigurationsdatei steht. Ein BIND auf einem Linux-Server, der seit dem letzten Rollover keine Updates mehr gesehen hat. Appliances und Fachverfahren mit eigenem Resolver, Container mit fest eingetragenem DNS. Und hin und wieder ein Windows-DNS-Server, auf dem jemand vor Jahren die Root-Trust-Anchors importiert hat, weil es in einem Härtungsleitfaden stand.

Wenn ihr aus dem Stand sagen könnt, welche Systeme bei euch rekursiv auflösen und ob sie dabei validieren, seid ihr weiter als die meisten. Alle anderen sollten das jetzt klären.

Schritt 1: Wer löst bei euch eigentlich auf?

Ich würde mit einer schlichten Liste anfangen. Darauf gehören alle Systeme, die DNS-Anfragen selbst auflösen oder prüfen, statt sie nur weiterzureichen. Das sind meistens die Domänencontroller, dazu Firewalls oder UTMs mit DNS-Funktion, eventuell ein Linux-Resolver wie Unbound, BIND, Knot Resolver oder PowerDNS Recursor. Filterdienste wie Pi-hole oder AdGuard Home gehören ebenso dazu wie Router mit eigenem DNS-Dienst. Appliances, VMs und Container mit eigener Resolver-Konfiguration nicht vergessen.

Zu jedem System gehört die Frage, wohin es weiterleitet. Ein Windows-DNS-Server, der an den Provider oder ein kommunales Rechenzentrum forwardet und selbst nicht validiert, ist nicht betroffen. Dann liegt der Ball beim Upstream.

Schritt 2: Validiert der Resolver überhaupt?

Das lässt sich in zehn Sekunden testen. Die Domain dnssec-failed.org ist absichtlich kaputt signiert.

dig @<IP-des-Resolvers> dnssec-failed.org A

Unter Windows geht es mit PowerShell:

Resolve-DnsName dnssec-failed.org -Server <IP-des-Resolvers>

Gibt es SERVFAIL oder einen Fehler, validiert der Resolver, und ihr macht mit Schritt 3 weiter. Gibt es eine ganz normale IP-Adresse zurück, validiert er nicht und ist selbst aus dem Schneider. Dann bleibt nur die Frage nach dem Upstream.

Schritt 3: Kennt der Resolver KSK-2024?

Eine Falle vorweg: dig . DNSKEY zeigt den neuen Schlüssel bei jedem Resolver an, weil er in der Root-Zone steht. Ob der Resolver ihm auch vertraut, sieht man daran nicht. Es zählt allein die lokale Trust-Anchor-Konfiguration. ICANN schreibt ausdrücklich, man solle sich nicht darauf verlassen, dass die automatische Aktualisierung geklappt hat. Dem kann ich mich nur anschließen.

Windows Server DNS

Windows-DNS validiert nur, wenn für die Root-Zone Trust Anchors eingetragen sind, und ab Werk sind keine eingetragen.

Get-DnsServerTrustAnchor -Name .

Bleibt die Ausgabe leer, hat der Server keine Root-Anchors und ist nicht betroffen. Stehen dort Einträge, muss einer mit dem Key Tag 38696 dabei sein. Ob die automatische Aktualisierung nach RFC 5011 läuft, zeigt dieser Befehl:

Get-DnsServerTrustPoint -Name .

Fehlt KSK-2024, holt dieser Befehl die aktuellen Anchors direkt von IANA:

Add-DnsServerTrustAnchor -Root

Bei AD-integriertem DNS prüfe ich das auf jedem DNS-Server einzeln, der Anchors trägt.

Unbound, auch in pfSense und OPNsense

Unbound arbeitet meist mit einer Trust-Anchor-Datei, die sich selbst aktualisiert.

unbound-control list_auto_trust_anchors
grep 38696 /var/lib/unbound/root.key

Der Pfad hängt von der Distribution ab, im Zweifel steht er unter auto-trust-anchor-file in der unbound.conf. Fehlt der Schlüssel, hilft das hier:

unbound-anchor -a /var/lib/unbound/root.key
systemctl restart unbound

Aufpassen muss, wer trust-anchor-file statt auto-trust-anchor-file verwendet. Da aktualisiert sich nichts von allein.

BIND

rndc managed-keys status

In der Ausgabe muss keyid: 38696 stehen. Mit dnssec-validation auto; nutzt BIND die mitgelieferte bind.keys und hält sie per RFC 5011 aktuell. Wer statische trust-anchors oder gar noch trusted-keys in der Konfiguration hat, muss selbst nachtragen. Kennt eure BIND-Version KSK-2024 noch nicht, ist sie ohnehin zu alt.

dnsmasq und Pi-hole

Hier sehe ich das größte Risiko, weil dnsmasq RFC 5011 schlicht nicht beherrscht. Der Trust Anchor steht fest in der Konfiguration.

grep -r trust-anchor /etc/dnsmasq.conf /etc/dnsmasq.d/

Dort sollten zwei Zeilen stehen, eine für 20326 und eine für 38696. Die für KSK-2024 lautet:

trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

Bitte den Hash nicht blind aus einem Blogartikel übernehmen, auch nicht aus diesem. Er gehört gegen die offizielle Datei bei IANA geprüft: https://data.iana.org/root-anchors/root-anchors.xml. Bei Pi-hole reicht meist ein Update, sofern DNSSEC dort überhaupt eingeschaltet ist.

Knot Resolver, PowerDNS Recursor und systemd-resolved

Diese Resolver bringen den Trust Anchor mit der Software mit. Eine aktuelle Version aus der Distribution genügt. systemd-resolved validiert in den meisten Distributionen gar nicht. resolvectl status zeigt, ob DNSSEC=yes gesetzt ist.

Firewalls, UTMs und Appliances

Bei Sophos, Fortinet, Securepoint, Lancom und Co. würde ich prüfen, ob die DNS-Funktion validiert und wie alt die Firmware ist. Wenn ihr das in der Oberfläche nicht findet, fragt beim Hersteller nach. Ein Gerät, das seit drei Jahren kein Update gesehen hat, ist für mich hier der Hauptverdächtige.

Schritt 4: Beim Upstream nachfragen

In vielen Verwaltungen und kleineren Firmen validieren die eigenen DNS-Server gar nicht, sondern leiten an den Provider oder ein Rechenzentrum weiter. Fällt dort die Validierung aus, habt ihr dasselbe Problem, könnt aber nichts dagegen tun.

Ich würde deshalb eine kurze Mail schicken: Validiert ihr DNSSEC, und ist KSK-2024 bei euch als Trust Anchor hinterlegt? Wie gut solche Anfragen beantwortet werden, ist erfahrungsgemäß sehr unterschiedlich. Den Test aus Schritt 2 könnt ihr aber auf jeden Fall selbst gegen den Upstream laufen lassen.

Schritt 5: Anwendungen mit eigenem DNS

ICANN erwähnt eigens Anwendungen, die am Resolver des Betriebssystems vorbeiarbeiten. Dazu zählen Container mit fest eingetragenem DNS-Server, Software mit DNS-over-HTTPS und Appliances, die ihren eigenen Resolver mitbringen.

Ehrlich gesagt habe ich keine gute Methode, so etwas vorab vollständig zu finden. Mein Ansatz: Wenn nach dem 11. Oktober eine einzelne Anwendung spinnt, während der Rest läuft, frage ich als Erstes, woher sie ihre DNS-Antworten bezieht.

Notfallplan für Montag, den 12. Oktober

Selbst wenn alles geprüft ist, würde ich für die Tage nach dem Wechsel einen Plan B bereithalten. ICANN empfiehlt für den Ernstfall eine einfache Reihenfolge. Zuerst die DNSSEC-Validierung vorübergehend abschalten oder einen Negative Trust Anchor für die Root setzen (RFC 7646), damit die Auflösung sofort wieder läuft. Danach KSK-2024 nachtragen, die Validierung wieder einschalten und mit dnssec-failed.org gegenprüfen.

Zum kurzfristigen Abschalten:

Resolver	Validierung vorübergehend aus
Unbound	in module-config nur "iterator" eintragen, Dienst neu starten
BIND	dnssec-validation no; setzen, dann rndc reconfig
dnsmasq	Option dnssec auskommentieren, Dienst neu starten
Windows DNS	fehlerhafte Trust Anchors entfernen oder mit Add-DnsServerTrustAnchor -Root erneuern

Das ist eine Krücke für ein paar Stunden. Ohne Validierung seid ihr gegen manipulierte DNS-Antworten wieder genauso ungeschützt wie vor DNSSEC.

Für Sonntag bis Dienstag würde ich außerdem das Monitoring auf SERVFAIL-Raten schärfen und die Telefonnummern von Provider, Rechenzentrum und Firewall-Hersteller auf einen Zettel schreiben. Einen echten Zettel, denn im Ernstfall funktioniert das Intranet vielleicht auch nicht. Den Servicedesk würde ich vorab informieren, damit er bei merkwürdigen Internetstörungen am Montag gleich an den Rollover denkt.

Checkliste

• [ ] Alle rekursiven und validierenden Resolver im Netz erfasst
• [ ] Mit dnssec-failed.org geprüft, welche davon validieren
• [ ] Bei allen validierenden Resolvern Key Tag 38696 im Trust Anchor bestätigt
• [ ] Statische Trust-Anchor-Konfigurationen (dnsmasq, BIND, Unbound ohne Auto-Update) nachgezogen
• [ ] Firmware von Firewalls, UTMs und Appliances geprüft
• [ ] Upstream-Provider bzw. Rechenzentrum angefragt
• [ ] Container und Anwendungen mit eigenem DNS berücksichtigt
• [ ] Notfallvorgehen dokumentiert, Kontakte griffbereit
• [ ] Monitoring und Servicedesk für den 11. bis 13. Oktober vorbereitet

2029 wird es schwieriger

Diesmal bleibt es bei RSA/SHA-256 mit 2048 Bit, nur der Schlüssel ändert sich. Für den nächsten Rollover, den ICANN um 2029 erwartet, soll auch der Algorithmus auf ECDSA wechseln. Dann reicht ein neuer Trust Anchor nicht mehr, die Resolver-Software muss den Algorithmus auch beherrschen. Ich würde die Liste aus Schritt 1 deshalb nicht nach dem 12. Oktober wegwerfen, sondern in die Dokumentation übernehmen.

Mein persönliches Fazit: Die Wahrscheinlichkeit, dass euch der Rollover trifft, ist gering. Aber die Prüfung dauert eine Stunde, und ein Montag ohne DNS dauert deutlich länger.

Quellen

• ICANN, Root Zone KSK Rollover: https://www.icann.org/resources/pages/ksk-rollover-en
• ICANN, What to Expect During the Root KSK Rollover (Stand 27. Juli 2026): https://www.icann.org/en/system/files/files/ksk-rollover-expect-27jul26-en.pdf
• IANA, Root Zone Trust Anchors: https://www.iana.org/dnssec/files
• RFC 5011 (Automated Updates of DNSSEC Trust Anchors) und RFC 7646 (Negative Trust Anchors)