Zusammenfassung

  • Forscher der University of Twente und von SIDN Labs maßen bei Falcon-512 eine mediane komprimierte Signatur von 655 Byte gegenüber 666 Byte im festen aufgefüllten Format. Bei der Wiederholung realer .nl-Anfragen verschob diese Ersparnis kaum vollständige DNSSEC-Antworten unter die untersuchten Größengrenzen.
  • Antworten auf nicht vorhandene Namen enthielten mehrere signierte Beweise und lagen im untersuchten Datensatz durchweg über 1.232 und 1.500 Byte. Ein Standard lässt sich schlecht am Gewicht eines Bauteils entscheiden, wenn die ganze Sendung am Tor hängen bleibt.

Elf Byte Rabatt am falschen Schalter

Eine Spedition senkt das Gewicht eines Aufklebers um elf Gramm. Der Schrank, auf dem er klebt, passt weiterhin nicht durch die Tür. Bei Post-Quantum-DNSSEC ist die Versuchung ähnlich: Eine kleinere Signatur lässt sich präzise messen und sauber vermarkten. Über das Netz geht jedoch die vollständige DNS-Antwort. Sie kann mehrere signierte Nachweise tragen, und genau diese Fracht entscheidet über die Größe.

Die 2025 veröffentlichte Untersuchung der University of Twente und von SIDN Labs verglich zwei Falcon-512-Signaturformate für DNSSEC. Komprimierte Signaturen sind unterschiedlich lang; aufgefüllte Signaturen haben eine feste Länge von 666 Byte. In der Testzone lag der Median der komprimierten Variante bei 655 Byte. Elf Byte weniger: ein echter Messwert, aber noch keine Aussage über die Zustellung einer DNS-Antwort.

Die Forscher nahmen die .nl-Zone vom 3. April 2025, entfernten die bisherigen DNSSEC-Daten und signierten zwei Versuchsversionen mit Falcon-512. Ein Tag aufgezeichneter Anfragen an die autoritativen Server wurde gegen zwei NSD-Testinstanzen wiederholt. In die Auswertung gingen 59.312.128 Anfragen mit übereinstimmendem NOERROR-Ergebnis und 113.348.878 mit übereinstimmendem NXDOMAIN ein. Die Anfrageverteilung stammte aus dem Betrieb; die Falcon-Antworten entstanden im Versuch. Diese Trennung schützt die Aussagekraft des Experiments vor einer bequemen, aber falschen Schlagzeile über einen produktiven .nl-Einsatz.

Bei NOERROR passten die meisten Antworten in beiden Formaten bereits unter die untersuchten Grenzen von 1.232 und 1.500 Byte. Ein kleinerer, keineswegs belangloser Teil lag darüber. Häufig musste zusätzlich ein signierter NSEC3-Nachweis zeigen, dass für eine nicht signierte Kind-Domain kein DS-Eintrag existiert. Die Signatur etwas zu kürzen entfernt diesen zusätzlichen Nachweis nicht. Entsprechend änderte sich die Zahl der Antworten, die unter der Grenze blieben, durch Kompression kaum.

NXDOMAIN räumte die Illusion noch gründlicher ab. Jede berücksichtigte Antwort auf einen nicht vorhandenen Namen überschritt beide Grenzen. Mit zwei signierten NSEC3-Einträgen maßen die Antworten 2.269 bis 2.420 Byte; mit drei Einträgen 3.075 bis 3.767 Byte. Mehrere Signaturen liefern zwar auch mehrere Gelegenheiten zum Sparen. Sie liefern aber vor allem mehrere Signaturen. Aus einer Antwort von über drei Kilobyte macht ein elf Byte schlankerer Bestandteil kein passendes Paket für 1.232 Byte.

Der Begriff „komprimiert“ verspricht außerdem keine feste Obergrenze von 655 Byte. Unter 9.912.711 Signaturen der Versuchszone fanden die Forscher eine unaufgefüllte Signatur mit 667 Byte. Das feste Format bleibt bei 666 Byte, weil der Signierer bei einem zu langen Ergebnis erneut signiert. Ein seltener Ausreißer entscheidet den Standard nicht. Er zeigt, dass Software die Verteilung einschließlich der Ränder behandeln muss. Ein Median lässt sich dagegen nicht in Code als Garantie einkompilieren.

Die Autoren halten das feste Format angesichts des geringen Transportvorteils für möglicherweise günstiger: Es ist vorhersehbar und verringert potenzielle Implementierungsfehler. Die Arbeit vermisst Nachrichtengrößen. Sie berechnet keine vollständige Bilanz aus CPU, Speicher, Hardware, Signieren und Validieren, und sie setzt keinen DNSSEC-Standard in Kraft. Ihre eng umrissene Aussage ist gerade deshalb wertvoll. Wer mit Kompression einen Transportvorteil begründet, muss ihn an vollständigen Antworten zeigen.

Auf der NIST-Seite zur Post-Quantum-Standardisierung, am 27. Oktober 2026 aktualisiert, steht Falcon als ausgewählt; FIPS 206 ist weiter in Entwicklung. Ein individueller Internet-Draft von Paul Hoffman bei ICANN nennt für DNSSEC zusätzlich Bereitstellungsgeschwindigkeit, CPU, Protokolländerungen, Hardware-Sicherheitsmodule, Kryptoanalyse und Patentlizenzen. Der Draft besitzt keine formale Stellung im IETF-Standardisierungsverfahren. Seine Liste zeigt trotzdem, wie viel mehr auf dem Tisch liegt als die Länge einer Signatur.

Laut Programm von RIPE 93 wird Ginevra Fabrizio die Arbeit am 29. Oktober vorstellen. Am 28. Oktober ist die Präsentation noch Zukunft, die veröffentlichte Studie liegt bereits vor. Für das Gespräch braucht es keine erfundene Konferenzmeinung. Es braucht Fragen nach Zonenauswahl, Anfragemix, vollständigen Antwortgrößen, TCP-Ausweichverkehr und Implementierungskosten. Der Schrank sollte vor der Abstimmung einmal durch die Tür getragen werden.

Die Messgröße schreibt die Tagesordnung

Gremien lieben vergleichbare Einzelwerte. Eine mittlere Signaturlänge lässt sich in einer Zeile unterbringen. DNS-Antworten hängen aber auch von Namenslängen, Delegationszuständen und den erforderlichen Beweisen für Nichtexistenz ab. Die Studie zeigt, dass Schwankungen der Namenslänge in derselben Größenordnung liegen wie die Schwankungen komprimierter Signaturen. Die Wirklichkeit hat ihren eigenen Haushaltsposten.

Wer laufendem Code Vorrang einräumt, verlangt hier etwas Nüchternes: die Antworten mit beobachteten Anfragen erzeugen und ihre Verteilung veröffentlichen. Wenn eine Optimierung die entscheidende Transportgrenze nicht verschiebt, soll sie auch nicht als Lösung für diese Grenze auftreten. Die Wahl des Standards hängt sonst an einem Messwert, dessen schöne Form gerade seine Schwäche ist.