DNS-Root-Schlüsselwechsel rückt näher: Messungen zeigen Lücken bei der Vorbereitung

Ein für den 11. Oktober 2026 geplanter DNS-Root-Schlüsselwechsel rückt näher. Die von Geoff Huston von APNIC veröffentlichten Messungen zeigen dabei einen uneinheitlichen Vorbereitungsstand. DNS, das Domain Name System, übersetzt Websitenamen in Netzwerkadressen. Sein Root-Schlüssel hilft Systemen dabei, die Echtheit von DNS-Informationen zu überprüfen. Damit handelt es sich um eine Sicherheitswartung, die bei einem fehlerhaften Übergang Folgen für das alltägliche Surfen haben kann.

In seinem am 9. Oktober veröffentlichten und am 8. Oktober verfassten APNIC-Artikel berichtet Huston, dass rund 70 % der Tests, die auf die Unterstützung eines bestimmten Prüfmechanismus hindeuteten, den neuen Schlüssel als vertrauenswürdig auswiesen. Eine separate Messung des Root-Server-Betreibers Verisign zeigte, dass rund 90 % der meldenden Resolver ihn hinzugefügt hatten. Keine der beiden Zahlen ist eine Schätzung dafür, wie viele Internetnutzer den Dienst nicht mehr nutzen können werden. Die Methoden erfassen unterschiedliche Gruppen und unterliegen wichtigen Einschränkungen.

Warum der Root-Schlüssel eine besondere Behandlung erfordert

DNS Security Extensions (DNSSEC) nutzen digitale Signaturen, also mathematische Echtheitsnachweise, um DNS-Antworten zu überprüfen. Ein rekursiver Resolver ist der Dienst, der diese Antworten im Auftrag eines Nutzers ermittelt. Kann ein validierender Resolver das erforderliche Vertrauen nicht herstellen, kann eine Abfrage fehlschlagen, statt eine Antwort zurückzugeben, deren Echtheit er nicht bestätigen kann.

Normalerweise sind DNS-Schlüssel in eine Hierarchie eingebunden. Ein Zone-Signing Key (ZSK), der Einträge innerhalb eines verwalteten DNS-Bereichs namens Zone signiert, wird über den Key-Signing Key (KSK) dieser Zone authentifiziert. Der KSK einer untergeordneten Zone ist über einen signierten Delegation-Signer-Eintrag (DS) mit ihrer übergeordneten Zone verknüpft. Dieser Eintrag enthält einen Hash, einen mathematischen Fingerabdruck des öffentlichen Schlüssels. So lässt sich Vertrauen von einer Ebene zur nächsten weitergeben.

Der Root-KSK hat keine übergeordnete Instanz. Stattdessen signiert der bereits als vertrauenswürdig eingestufte Schlüssel einen Satz von Schlüsseleinträgen, der seinen Nachfolger enthält. Resolver müssen anschließend genügend Zeit haben, den neuen Schlüssel zu beobachten und als Vertrauensanker zu akzeptieren, also als lokal gespeicherten Ausgangspunkt für die Echtheitsprüfung.

Das automatische Aktualisierungsverfahren ist in RFC 5011 festgelegt. Seine Wartezeit beträgt mindestens 30 Tage oder länger, wenn die ursprüngliche Time to Live (TTL) dies erfordert. Die TTL ist die Gültigkeitsdauer, die dem ersten relevanten Satz von Schlüsseleinträgen zugeordnet ist. Ein Resolver muss mindestens zwei authentifizierte DNSKEY-Ressourceneintragssätze, also Sammlungen veröffentlichter DNS-Schlüssel, sehen, die den neuen Schlüssel enthalten, bevor er ihn akzeptiert. Werden die vorgeschriebenen Wartezeiten eingehalten, soll der Übergang automatisch erfolgen.

Bei diesem Wechsel wird das Schlüsselpaar ausgetauscht, nicht der kryptografische Algorithmus. Der neue KSK-2024 wurde im Juli 2024 auf der Website der Internet Assigned Numbers Authority (IANA) veröffentlicht und im Januar 2025 den DNSKEY-Einträgen der Root-Zone hinzugefügt. IANA plant, ihn ab dem 11. Oktober 2026 zur Signierung des DNSKEY-Eintragssatzes der Root-Zone einzusetzen.

Zwei Wege zur Prüfung des Vorbereitungsstands

RFC 8145 beschreibt, wie Resolver den Root-Servern ihre vertrauenswürdigen Schlüssel signalisieren können. Ein Key Tag ist eine kurze numerische Kennung für einen Schlüssel. Resolver können diese Kennungen im Abfragenamen unterbringen: `_ta-4f66-9728` zeigt Vertrauen in die Schlüssel mit den Kennungen 20326 und 38696 an. Alternativ können sie die Werte in einer edns-key-tag-Option übermitteln, einem zusätzlichen Feld innerhalb einer DNS-Abfrage.

Root-Server-Betreiber können diese Signale in ihren Abfrageprotokollen untersuchen. Die Stichprobe von Verisign vom Juli 2026 zeigte, dass rund 90 % der meldenden Resolver KSK-2024 hinzugefügt hatten. Ein Resolver kann jedoch Millionen Menschen bedienen oder nur eine einzige Person, wie der Resolver auf Hustons Laptop. Die Anzahl der Resolver verrät daher nicht, wie viele Nutzer hinter Systemen stehen, die noch nicht bereit sind.

RFC 8509 verfolgt einen anderen Ansatz. Der darin beschriebene Root Key Trust Anchor Sentinel-Mechanismus sendet ein Signal an die Person zurück, die die Abfrage stellt. Ein Resolver, der den Mechanismus unterstützt, erkennt ein spezielles Präfix im angefragten Namen und passt seine Antwort an die Schlüssel an, denen er vertraut.

Bei `root-key-sentinel-is-ta-` führt ein vertrauenswürdiger Schlüssel zur ursprünglichen Antwort; ein nicht vertrauenswürdiger Schlüssel führt zu SERVFAIL, einer DNS-Fehlerantwort. Bei `root-key-sentinel-not-ta-` sind diese Ergebnisse umgekehrt. Das DNS-Team von Cloudflare betreibt eine Webseite, über die Nutzer diese Tests für ihre eigene DNS-Konfiguration ausführen können.

APNIC nutzt werbebasierte Messungen, um bei Internetnutzern drei Testabfragen auszuführen. Die ersten beiden prüfen die Unterstützung des Mechanismus anhand von KSK-2017 mit der Kennung 20326. Ein Resolver, der den Mechanismus unterstützt und diesem Schlüssel vertraut, sollte beim is-ta-Test NOERROR, eine erfolgreiche DNS-Antwort, und beim not-ta-Test SERVFAIL zurückgeben. Ein Resolver ohne diese Unterstützung liefert dagegen bei beiden Tests eine authentifizierte Antwort. Die dritte Abfrage prüft, ob KSK-2024 mit der Kennung 38696 als vertrauenswürdig gilt.

Statt einzelne Resolver zu identifizieren, möchte APNIC Nutzer erfassen, deren DNS-Anfragen ausschließlich über validierende Resolver laufen, die dem Ersatzschlüssel noch nicht vertrauen. Nur Stichproben mit den erwarteten Antworten auf die ersten Tests werden als meldende Nutzer gezählt.

Was die Tests von APNIC ergaben

Huston berichtet, dass ein kleiner Test am 5. Oktober mit RIPE Atlas-Sonden, also Geräten zur Messung der Internetkonnektivität, 2.900 verschiedene autonome Systeme abdeckte. Dabei handelt es sich um unabhängig verwaltete Netzwerke. Bei 1.230 Sonden entsprach das Verhalten einer Unterstützung des Sentinel-Mechanismus und einer Akzeptanz des neuen Schlüssels. Weitere 47 verhielten sich so, als sei dieser noch nicht geladen worden.

Die umfangreicheren werbebasierten Tests von APNIC liefen zwischen Mai und Juli 2026 und wurden Anfang Oktober wieder aufgenommen. Im Durchschnitt fanden rund 16 Millionen Tests täglich statt. Rund 6 Millionen tägliche Tests schienen über DNSSEC-validierende Resolver zu laufen, und etwa 1,8 Millionen lieferten ein eindeutiges Signal für die Unterstützung des Sentinel-Mechanismus. Innerhalb der Stichproben, die diesen Mechanismus offenbar unterstützten, meldeten rund 70 % Vertrauen in KSK-2024. Diese Filter sind wichtig: Das Ergebnis lässt sich nicht einfach auf jeden Resolver oder Internetnutzer übertragen.

Die Durchschnittswerte verdecken zudem erhebliche Unterschiede zwischen den Netzwerken. Huston beschreibt eine Tabelle der 50 Netzwerke mit den niedrigsten Akzeptanzraten, beschränkt auf Netzwerke mit mindestens 1.000 Tests, die eine Unterstützung des Sentinel-Mechanismus zeigten. Der bereitgestellte Auszug endet, bevor die vollständige Tabelle sichtbar ist. Zu den aufgeführten Akzeptanzraten gehören 16,40 % für Allo Comms in den Vereinigten Staaten, 12,70 % für Vodafone Libertel in den Niederlanden, 8,20 % für Vodafone-CZ in Tschechien, 6,20 % für Superloop in Australien und 2,50 % für Reliance Jio in Indien. Dies sind gemessene Signale zum Vorbereitungsstand, keine bestätigten Ausfallraten und kein Beleg dafür, dass jeder Kunde in diesen Netzwerken betroffen ist.

Für Unternehmen und Websitebetreiber ist praktisch entscheidend, ob der DNS-Dienst, auf den sie angewiesen sind, den neuen Vertrauensanker akzeptiert hat. Den Anbieter oder das IT-Team um eine Überprüfung der Bereitschaft zu bitten, ist sinnvoller, als einen zusammengefassten Prozentwert als Prognose für einen bestimmten Anschluss zu betrachten.

AEU DNS bietet privates, verschlüsseltes DNS für Leser, die ihre Abfragen während der Übertragung schützen möchten. Verschlüsselung ist jedoch von der Vorbereitung der DNSSEC-Vertrauensanker zu unterscheiden und stellt für sich allein nicht sicher, dass ein System für diesen Schlüsselwechsel bereit ist. Die hier berichteten Erkenntnisse betreffen die Vorbereitung vor dem geplanten Wechsel, nicht einen danach beobachteten Ausfall.