Der nächste DNS-Root-Key-Rollover läuft, und die Einführung des neuen Schlüssels ist gefährlich niedrig

Kryptografische Schlüssel sind nie für die Ewigkeit gedacht. Einen privaten Schlüssel zu brechen ist nicht mathematisch unmöglich; es ist nur rechenaufwendig, was bedeutet, dass ein Angreifer eine enorme Menge an Rechenleistung und Zeit benötigen würde. Wenn ein Schlüssel über viele Jahre verwendet wird, hat ein Angreifer dieselben Jahre, um es weiter zu versuchen. Deshalb müssen Schlüssellaufzeiten, Algorithmuswahl und Schlüssellängen regelmäßig im Hinblick auf das Wachstum der Rechenleistung neu bewertet werden, einschließlich des möglichen Aufkommens kryptografisch relevanter Quantencomputer. Für Geheimnisse, die 20 Jahre lang geschützt bleiben müssen, könnten Post-Quanten-Algorithmen erforderlich sein; für Geheimnisse mit einer Laufzeit von fünf Jahren sind Produktions-Quantencomputer weniger ein kurzfristiges Problem. Im Domain Name System Security Extensions (DNSSEC), das digitale Signaturen zu DNS-Abfragen hinzufügt, damit Benutzer den Antworten vertrauen können, haben die meisten Schlüssel kurze Laufzeiten von einigen Monaten bis zu ein oder zwei Jahren, sodass sie noch keinen Post-Quanten-Schutz benötigen.

Aber ein regelmäßiger Schlüsselwechsel ist dennoch unerlässlich. Alle in DNSSEC verwendeten kryptografischen Schlüssel sollten regelmäßig ersetzt werden, sowohl um die Exposition zu begrenzen als auch um den Betreibern Übung im Rollover-Prozess zu geben. Es gibt kein einziges korrektes Intervall: Wöchentliches Rollen ist zu kurz, während ein Schlüssel 25 Jahre lang zu belassen unklug ist. Eine gute Betriebspraxis ist es, einen neuen Schlüssel in den DNSKEY-Eintrag der Zone einzuführen, der die öffentlichen Schlüssel für diese DNS-Zone enthält, und ihn mindestens eine DNS-Cache-Lebensdauer lang dort zu belassen, bevor man umschaltet. Alternativ kann eine Zone einen neuen Schlüssel sofort verwenden, indem sie mehrere RRSIG-Einträge (digitale Signaturen) veröffentlicht, sodass jeder DNS-Eintrag sowohl mit dem alten als auch mit dem neuen Schlüssel signiert ist; jedoch muss darauf geachtet werden, dass DNS-Antworten nicht über die 1.210-Byte-UDP-Paketfragmentierungsschwelle hinauswachsen, da größere Antworten von einigen Netzwerken verworfen werden können. Rekursive Resolver wenden manchmal ihre eigenen Cache-Lebensdauern an, anstatt der Anleitung der Zone zu folgen, daher ist eine konservative Einführungsphase vor dem Löschen des alten Schlüssels ratsam. Die detaillierten Betriebspraktiken sind in RFC 6781 und RFC 7583 beschrieben.

Die eine große Ausnahme ist der Root-Key des DNS, der als Root Key Signing Key (KSK) bezeichnet wird. Dieser Schlüssel signiert die Root-Zone des Internet-Benennungssystems, und jeder DNSSEC-validierende Resolver muss eine Kopie seines öffentlichen Schlüssels als Vertrauensanker (Trust Anchor) haben. Der erste Root-KSK diente acht Jahre; sein Nachfolger, KSK-2017, ist nun seit knapp acht Jahren im Dienst, Stand Mai 2026. Die lange Lebensdauer ist nicht gewählt, sondern notwendig: Es gibt keine bequeme Möglichkeit, einen neuen KSK-Wert einzuführen und ihn schnell in die Trust-Anchor-Sets aller validierenden Resolver zu integrieren. Stattdessen veröffentlicht IANA, die die Root-Zone verwaltet, einen eingehenden Schlüssel lange bevor er verwendet wird, signiert ihn mit dem aktuellen Schlüssel (ein Prozess, der als 'old signs new' bekannt ist) und wartet eine längere Zeit, bis Resolver ihn aufnehmen. Das erklärte Ziel für die Lebensdauer des Root-KSK ist nominell fünf Jahre, aber die praktische Erfahrung hat dies verlängert; der erste Rollover wurde am 11. Oktober 2018 durchgeführt. Wenn solche verlängerten Lebensdauern bei IANA üblich bleiben, wird die Notwendigkeit, auf deutlich größere Post-Quanten-Algorithmen und -Schlüssel umzusteigen, früher eintreten. Der nächste Rollover ist im Gange: Der eingehende Schlüssel, KSK-2024, wurde im Juli 2024 auf der IANA-Website veröffentlicht und im Januar 2025 zum DNSKEY-Eintrag der Root-Zone hinzugefügt. IANA plant, KSK-2024 im Oktober 2026 zu verwenden, um die digitale Signatur der Root-Zone zu erzeugen und KSK-2017 zu ersetzen.

Um zu verfolgen, ob Resolver den neuen Schlüssel übernommen haben, verwenden Forscher zwei verschiedene Messtechniken. Die erste, in RFC 8145 beschrieben, fordert Resolver auf, zu signalisieren, welchen Schlüsseln sie vertrauen, wenn sie Abfragen an Root-Server senden. Ein Resolver kann die Schlüssel-Tags in einen speziellen Abfragenamen einbetten, z. B. _ta-4f66-9728, was bedeutet, dass er Schlüsseln mit den Tag-Werten 20326 und 38696 vertraut, oder er kann die Tags in einer EDNS-Option einfügen. RFC 5011 spezifiziert eine Add-Hold-Down-Zeit von 30 Tagen oder der ursprünglichen TTL des ersten Trust-Point-DNSKEY-RRSets, je nachdem, was größer ist, sodass ein Resolver mindestens zwei validierte Datensätze mit dem neuen Schlüssel sehen muss, bevor er ihn akzeptiert. Verisign analysierte diese Signale und berichtete im März 2025, dass alle meldenden Resolver immer noch KSK-2017 vertrauten, was erwartet wurde, bis dieser Schlüssel Anfang 2027 widerrufen wird. Etwa 0,5 % der Resolver vertrauten immer noch KSK-2010, obwohl es 2019 widerrufen wurde, wahrscheinlich aufgrund veralteter Betriebssystem-Updates. Eine kleine Bevölkerung begann im Juli 2024, KSK-2024 zu vertrauen, direkt nachdem der Schlüssel in der IANA-Trust-Anchor-Datei veröffentlicht wurde. Der größte Sprung erfolgte 30 Tage nachdem der Schlüssel zum DNSKEY-Eintrag der Root-Zone hinzugefügt wurde, was der in RFC 5011 definierten automatischen Aktualisierungszeit entspricht. Ein kleiner Anstieg während dieses ersten Monats stammte wahrscheinlich von manuell konfigurierten Resolvern. Diese Daten zählen jedoch nur meldende Resolver, nicht die Anzahl der Benutzer hinter jedem Resolver, und sie übersehen Resolver, die den Signalisierungsmechanismus überhaupt nicht unterstützen.

Um eine benutzerzentrierte Sicht zu erhalten, verwendet APNIC eine andere Methode, die in RFC 8509 beschrieben ist, den Root Key Trust Anchor Sentinel. Anstatt Resolver zu bitten, Root-Server zu signalisieren, platziert dieser Ansatz ein spezielles linkestes Label in einem DNS-Abfragenamen. Der Resolver erkennt das Label und gibt eine Antwort basierend darauf, ob er einem bestimmten Schlüssel vertraut. Zum Beispiel gibt eine Abfrage an root-key-sentinel-is-ta-20326 die normale Antwort zurück, wenn der Resolver diesem Schlüssel vertraut, und SERVFAIL (einen DNS-Fehler), wenn nicht. Das inverse Label root-key-sentinel-not-ta-20326 gibt SERVFAIL zurück, wenn der Schlüssel vertraut wird, und die normale Antwort, wenn nicht. APNICs werbebasiertes Messsystem sendet diese Abfragen täglich an eine Sammlung von Endbenutzern. Der Test verwendet drei Labels: not-ta-20326 und is-ta-20326 verifizieren zuerst, dass der Resolver DNSSEC-Validierung durchführt und den Sentinel-Mechanismus unterstützt; das dritte, is-ta-38696, prüft, ob der Resolver KSK-2024 in sein Trust-Anchor-Set geladen hat. Nur Stichproben, bei denen die ersten beiden Tests die erwarteten Antworten zurückgeben, werden als 'meldende Benutzer' gezählt.

Die Ergebnisse sind überraschend. Obwohl die RFC-8145-Resolver-Daten darauf hindeuteten, dass meldende Resolver KSK-2024 im März 2025 übernommen hatten, erzählt die RFC-8509-Benutzermessung eine andere Geschichte. Im April 2026, 13 Monate nachdem der 30-Tage-Einführungstimer für KSK-2024 abgelaufen war, hatten weniger als 20 % der Benutzer hinter DNSSEC-validierenden Resolvern KSK-2024 zu ihrem lokalen Trust-Anchor-Set hinzugefügt. Das bedeutet, dass, wenn der Root-KSK-Rollover sofort stattfände, die überwiegende Mehrheit der Benutzer auf validierenden Resolvern plötzlich DNSSEC-Validierungsfehler sehen und viele Websites nicht erreichen könnte. Die Diskrepanz könnte darauf zurückzuführen sein, dass viele Resolver, die DNSSEC validieren, den Sentinel-Mechanismus nicht unterstützen, oder dass die Resolver-Population sich von der Benutzerpopulation unterscheidet. Die Messung hat Einschränkungen: Der werbebasierte Test verwendet zwei URLs, und ein validierender Resolver, der den Sentinel unterstützt, gibt eine DNSSEC-signierte Antwort für das is-ta-Label zurück, aber nicht alle Resolver tun dies. Die täglichen Zählungen der DNSSEC-Validierung und Sentinel-Signale zeigen auch, dass nur ein Teil der getesteten Benutzer überhaupt hinter validierenden Resolvern steht.

Die langsame Einführung von KSK-2024 unterstreicht eine anhaltende betriebliche Lücke: Resolver-Betreiber müssen sicherstellen, dass ihre Software aktualisiert ist und ihre Trust-Anchor-Dateien den neuen Schlüssel enthalten, aber viele haben dies nicht getan. Endbenutzer und Website-Betreiber können Schritte unternehmen, um sich zu schützen. Für normale Internetnutzer kann die Wahl eines datenschutzorientierten verschlüsselten DNS-Resolvers wie AEU DNS, der DNSSEC-Signaturen validiert und keine Abfragen protokolliert, dazu beitragen, dass ihre eigenen Abfragen authentifiziert und privat bleiben, auch während der globale Root-Key-Übergang unvollständig ist. Für Resolver-Betreiber ist es entscheidend, RFC 5011 zu befolgen und die Software aktuell zu halten, lange vor Oktober 2026.