DNS Root KSK Rollover: Die Uhr läuft

Wer für DNS-Infrastruktur verantwortlich ist, sollte sich den 11. Oktober 2026 rot im Kalender anstreichen. An diesem Sonntag führt ICANN einen geplanten Root Zone Key Signing Key (KSK) Rollover durch – einen kryptografischen Schlüsselwechsel, der buchstäblich das Fundament der DNSSEC-Validierung im Internet darstellt.

Das Risiko wird oft unterschätzt. Ein Resolver, der nicht auf den neuen Schlüssel aktualisiert wurde, validiert nicht einfach keine DNSSEC-Signaturen mehr. Er stellt den Betrieb komplett ein. Totalausfall.

Was genau ist der Root KSK?

Man kann sich die DNS-Hierarchie als Vertrauenskette vorstellen. Ganz oben sitzt die Root Zone, geschützt vom Root KSK. Dieser kryptografische Schlüssel bildet das Fundament für alle DNSSEC-Validierungen. Sobald dein rekursiver Resolver eine DNSSEC-signierte Domain prüft, folgt er der Signaturkette bis zu diesem Wurzel-Schlüssel. Erkennt dein Resolver den aktuellen Root KSK nicht mehr, bricht die gesamte Kette ab.

ICANN als Verwalter der DNS-Root-Zone führt regelmäßig Schlüssel-Rotationen durch. Das gehört zu den bewährten Sicherheitspraktiken. Warum? Schlüsselwechsel verhindern langfristige Kompromittierungen und halten die kryptografische Infrastruktur gegen neue Bedrohungen gewappnet.

So läuft der Rollover ab

Beim KSK-Rollover wird der Signaturschlüssel ausgetauscht, der bisher die Zone Signing Keys (ZSK) der Root Zone signiert hat. Der neue KSK erzeugt frische Signaturen, und entsprechend müssen die Trust Anchors aktualisiert werden.

Das ist kein theoretisches Szenario. Solche Rollover gab es bereits. Und jedes Mal gab es Ausfälle bei veralteten Resolvern.

Das kritische Problem: Sobald ein DNSSEC-validierender Resolver auf eine Signatur trifft, die er nicht verifizieren kann, weil der Root-Schlüssel fehlt, antworten RFC 4033-konforme Implementierungen mit SERVFAIL. Im Klartext? NXDOMAIN für jede einzelne Anfrage – egal ob die Domain existiert oder nicht.

Wer muss aktiv werden?

DNSSEC-validierende Resolver stehen im Fokus. Betreibst du BIND, Unbound, Knot Resolver oder einen anderen DNSSEC-fähigen Resolver, musst du sicherstellen, dass deine Trust-Anchor-Konfiguration den neuen KSK enthält – rechtzeitig vor dem 11. Oktober.

Für die meisten Anwender passiert das automatisch. Große Betriebssysteme und DNS-Software-Distributionen erhalten Schlüssel-Updates über die normalen Update-Mechanismen.

Aber wenn du verantwortlich bist für:

• Individuelle DNS-Infrastruktur
• Eingebettete Systeme oder IoT-Geräte mit eingeschränkten Update-Möglichkeiten
• Interne Resolver mit festen Konfigurationen
• Air-Gapped-Systeme ohne regelmäßige Updates

...dann kommst du um manuelle Eingriffe nicht herum.

So prüfst du den Status deines Resolvers

Die gute Nachricht: Die Überprüfung deiner Bereitschaft ist unkompliziert. Stelle eine Abfrage an deinen Resolver für den Root DNSKEY-Eintrag:

dig @<deine-resolver-ip> DNSKEY . +multi

Achte auf die KSK-Einträge – erkennbar am Flag-Wert 257. Vergleiche diese mit dem aktuellen KSK von ICANN, der in der Root Zone DNSSEC Practice Statement Dokumentation veröffentlicht ist.

Nutzt du BIND? Dann prüfe deine trusted-keys oder dnssec-validation auto Konfiguration. Aktuelle BIND-Versionen mit dnssec-validation auto laden Root-Schlüssel automatisch über RFC 5011 Trust Anchor Maintenance.

Warum DNSSEC überhaupt wichtig ist

DNSSEC existiert, um ein grundlegendes Problem zu lösen: DNS wurde in einer Zeit des Vertrauens entwickelt, ohne kryptografische Verifikation. Wenn du nach example.com fragst – woher weißt du, dass die Antwort tatsächlich von den legitimen Servern kam und nicht unterwegs abgefangen und gefälscht wurde?

DNSSEC fügt digitale Signaturen zu DNS-Einträgen hinzu. Jede Zone signiert ihre eigenen Einträge, und übergeordnete Zonen authentifizieren die Schlüssel untergeordneter Zonen. Der Root KSK verankert diese gesamte Vertrauenskette.

Ohne DNSSEC-Validierung sind deine Anwendungen anfällig für DNS Cache Poisoning, Man-in-the-Middle-Angriffe und Traffic-Hijacking. 2024 und 2025 stieg die DNSSEC-Validierung bei großen DNS-Providern deutlich an. Das macht solche Schlüssel-Rollover zunehmend kritisch für den laufenden Betrieb.

Konkrete Schritte für die nächsten Wochen

1. Resover auditieren – Welche Resolver führen DNSSEC-Validierung durch?
2. Trust-Anchor-Konfiguration prüfen – Verweisen sie auf den aktuellen und zukünftigen KSK?
3. In Testumgebung validieren – Änderungen vor dem Stichtag gründlich prüfen
4. Nach dem Rollover überwachen – SERVFAIL-Spitzen oder Auflösungsfehler im Blick behalten
5. Dokumentation für künftige Rollover – Der nächste steht in etwa fünf Jahren an

Was passiert, wenn du nicht handelst?

Im besten Fall gibt es intermittierende Auflösungsfehler. Im schlimmsten Fall wird dein Resolver für DNSSEC-signierte Domains vollständig unbrauchbar – und das betrifft mittlerweile den Großteil des Internets.

Der Root KSK Rollover ist nicht nur ICANNs Angelegenheit. Es ist gemeinsame Verantwortung, die die DNS-Sicherheitsinfrastruktur intakt hält. Nimm dir diese Woche dreißig Minuten für ein Resolver-Audit. Deine Nutzer werden es dir danken, wenn Sonntag kommt und alles funktioniert.

Bleib sicher. Bleib validiert.

Mehr zum Thema DNSSEC-Implementierung und DNS-Best Practices findest du in den Infrastructure-Guides und Managed-DNS-Services von NameOcean – entwickelt für moderne Applikations Deployments.