DNSSEC steht vor einem post-quantum-Verkehrsproblem

DNSSEC, das System, das digitale Signaturen verwendet, um zu überprüfen, ob DNS-Antworten authentisch sind, steht bei einer Einführung von post-quantum cryptography vor einem Transportproblem. Größere Signaturen könnten viele Antworten für die normale Übertragung über UDP zu groß machen und recursive resolver zwingen, Abfragen über TCP erneut zu versuchen.

Der Grund für die Sorge ist das mögliche Auftreten eines cryptographically relevant quantum computer oder CRQC, der leistungsfähig genug wäre, private Schlüssel aus öffentlich zugänglichen Informationen innerhalb eines praktisch relevanten Zeitraums abzuleiten. Quantum computers befinden sich noch in einem sehr frühen Entwicklungsstadium, und ihr Bau ist langsam und teuer. Der Algorithmus von Peter Shor aus dem Jahr 1994 zeigte jedoch, dass ausreichend leistungsfähige quantum computers RSA und elliptic-curve cryptography, bekannt als ECC, gefährden könnten.

Wann ein CRQC existieren wird, ist unbekannt. Das Jahr 2030 wurde erörtert, obwohl APNIC es eher als optimistische Möglichkeit denn als etablierte Prognose beschreibt. Das Thema ist bereits für Informationen relevant, die zwei Jahrzehnte lang geheim bleiben müssen. Ein Angreifer könnte verschlüsselte Daten jetzt abfangen und später entschlüsseln, eine Vorgehensweise, die als Harvest Now, Decrypt Later oder HNDL bekannt ist.

Für digitale Signaturen besteht eine verwandte Schwachstelle. Wenn ein Angreifer den privaten Schlüssel berechnet, der zu einem signing key pair gehört, könnte er dessen Besitzer imitieren. Das Risiko hängt teilweise davon ab, wie lange dieser Schlüssel verwendet wird. Eine ICANN-Veröffentlichung aus dem Jahr 2022 mit dem Titel „Observing DNSSEC Key Lifecycles“ (OCTO-035) stellte fest, dass Key-Signing Keys von top-level domains, also KSKs, im Allgemeinen ein Jahr oder länger verwendet wurden, während Zone Signing Keys, also ZSKs, im Allgemeinen einen oder mehrere Monate lang verwendet wurden.

Häufigeres Rotieren der Schlüssel könnte eine erste Maßnahme sein, etwa der monatliche Austausch eines ZSK und der jährliche oder halbjährliche Austausch eines KSK. Eine schnellere Rotation würde jedoch nicht ausreichen, wenn sich quantum computing schnell weiterentwickelt. DNS-Betreiber müssten schließlich post-quantum cryptographic algorithms, bekannt als PQC, in ihrer DNSSEC-Konfiguration einsetzen.

Die unmittelbare technische Herausforderung ist die Größe. APNIC vergleicht DNSSEC algorithm 13, ECDSA P-256 mit SHA-256, mit algorithm 18, ML-DSA-44. Der öffentliche ECDSA-Schlüssel ist 32 Byte groß, sein privater Schlüssel 32 Byte und seine Signatur 65 Byte. ML-DSA-44 verwendet einen 1.312 Byte großen öffentlichen Schlüssel, einen 2.560 Byte großen privaten Schlüssel und eine 2.420 Byte große Signatur.

Im Beispiel von APNIC erzeugte eine DNS-Abfrage für einen mit ECDSA P-256 signierten Namen eine 191 Byte große Antwort einschließlich einer 65 Byte großen Signatur, die in ein nicht fragmentiertes UDP-Paket passte. Dieselbe Abfrage mit ML-DSA-44 erzeugte eine 2.551 Byte große Antwort. Der recursive resolver gab eine gekürzte UDP-Antwort zurück, sodass der stub resolver eine TCP-Verbindung aufbauen und die Abfrage wiederholen musste. Die Transaktion wuchs von zwei UDP-Paketen auf zehn Pakete an, einschließlich der Kürzungsnachricht, des TCP-Handshakes und des Verbindungsabbaus.

IP fragmentation könnte scheinbar eine Lösung bieten, weil ein IP-Paket bis zu 65.536 Byte groß sein kann. Fragmentation ist jedoch sowohl bei IPv4 als auch bei IPv6 unzuverlässig und riskant. APNIC verweist auf den DNS Flag Day 2020, der warnte, dass fragmentierte DNS-Nachrichten möglicherweise nicht ankommen und außerdem dazu verwendet werden könnten, Teile einer Nachricht zu fälschen, ohne dass dies leicht erkannt wird.

Das ursprüngliche DNS-Design begrenzte UDP payloads auf 512 Oktette. Extension Mechanisms for DNS, kurz EDNS, erlaubten später einem Anfragenden, die größte UDP payload anzugeben, die er wieder zusammensetzen konnte. Bis etwa 2019 wurden 4.096 Oktette häufig als Ausgangspunkt empfohlen. Der DNS Flag Day 2020 empfahl stattdessen eine EDNS UDP buffer size von 1.232 Byte, um Fragmentation in nahezu allen heutigen Netzwerken zu vermeiden. Die relevanten Spezifikationen sind RFC 6891 und RFC 4035.

APNIC Labs maß die EDNS buffer sizes über sieben Tage bis zum 3. November 2026 und verwendete dabei 36 Milliarden Abfragen von 245 Millionen registrierten Endnutzern. Die meisten Abfragen verwendeten 1.410 Byte. APNIC berechnete, dass 75,2 % der Abfragen eine buffer size verwendeten, die Fragmentation innerhalb eines 1.500 Byte großen IP-Pakets wahrscheinlich vermeidet, während 24,8 % darauf hindeuteten, dass der recursive resolver eine größere, fragmentierte Antwort annehmen konnte. Die Messung bedeutet nicht, dass zwangsläufig ein Viertel der Antworten fragmentiert wird, da auch authoritative servers eigene Grenzen festlegen. Die kleinere Grenze bestimmt, ob eine Antwort vollständig oder gekürzt ist.

Große post-quantum-DNSSEC-Antworten würden normalerweise gekürzt und über TCP erneut angefordert. Das ist relevant, weil recursive resolvers häufig DNSSEC records anfordern, selbst wenn der Endkunde sie nicht sehen muss. Das DNSSEC OK- oder DO bit teilt einem Resolver mit, dass DNSSEC records wie RRSIG, DNSKEY und DS in die Antwort aufgenommen werden dürfen. Es fordert nicht selbst die DNSSEC validation an.

Ein DNSSEC-fähiger recursive resolver kann beim Abfragen eines authoritative servers DO setzen und anschließend die DNSSEC records entfernen, bevor er die Antwort an einen Client zurückgibt, der sie nicht angefordert hat. So kann der Resolver ein Ergebnis mit aktiviertem DNSSEC zwischenspeichern und eine zweite Abfrage vermeiden. Das Checking Disabled- oder CD bit teilt einem recursive resolver mit, Daten bei einer fehlgeschlagenen validation weder zu blockieren noch zu entfernen. Das Authenticated Data- oder AD bit in einer Antwort zeigt an, dass der Resolver die records mit DNSSEC überprüft hat. Ein stub resolver sollte AD nur über eine sichere, vertrauenswürdige und authentifizierte Verbindung zu diesem Resolver als vertrauenswürdig einstufen.

APNIC Labs stellte fest, dass DO in 60,2 % von 36.324.963.331 Abfragen während der Woche bis zum 3. November 2026 gesetzt war. Für A-record-Abfragen galt dasselbe Verhältnis; nach dem Entfernen doppelter Abfragen lag es bei 60,9 %. Die Messungen stammten aus einer umfangreichen Stichprobe von Endnutzern, die über Googles System zur Auslieferung von Werbung und die Plattform von APNIC Labs erreicht wurden.

Im selben Zeitraum befanden sich 40 % der Nutzer hinter recursive resolvers, die DNSSEC validation durchführten. Weitere 8,5 % befanden sich hinter Systemen, die eine validation versuchten, nach SERVFAIL jedoch über einen nicht validierenden Resolver erneut abfragten. Das deutet darauf hin, dass 48 % der Nutzer Abfragen an sicherheitsbewusste Resolver sendeten, von denen erwartet wird, dass sie DO gegenüber dem übergeordneten Server setzen. Bei den zusätzlichen 12 % schien keine DNSSEC validation stattzufinden, da keine DNSKEY-Abfragen beobachtet wurden, obwohl ihre Resolver weiterhin DO setzten.

Die praktischen Auswirkungen sind heute durch Caching und durch die Tatsache begrenzt, dass laut Daten des recursive resolvers Cloudflare 1.1.1.1 nur etwa 2 % der abgefragten Namen DNSSEC-signiert sind. Die Messungen von APNIC verwendeten absichtlich eindeutige labels, sodass Caches die Abfragen nicht abfangen konnten, bevor sie authoritative servers erreichten. Die meisten stub resolvers verlassen sich bei der validation ebenfalls auf recursive resolvers und verwenden AD als Signal.

Wenn der gesamte DNSSEC-Bereich irgendwann auf PQC umgestellt würde, könnten laut APNIC zunächst etwa 60 % der heutigen Abfragen von UDP auf TCP umgeleitet werden. Das wirft die Frage auf, ob Abfragen mit DO stattdessen direkt über TCP erfolgen sollten. Ein working Internet draft mit dem Titel „No DO for you“ schlägt vor, dass nicht validierende Resolver DO löschen und anschließend zwischenspeichern, ob eine Antwort mit gesetztem bit abgerufen wurde. Wenn ein späterer Client DNSSEC records anfordert, würde der Resolver eine neue Abfrage mit gesetztem DO durchführen.