Zusammenfassung

  • draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02 lässt viele DNS-RRsets einen ML-DSA-signierten Merkle-Ladder teilen und ersetzt wiederholte Vollsignaturen durch einzelne Authentisierungspfade.
  • Die Antwort kann kryptographisch gültig sein, ohne zu belegen, dass der Signierer seine Node-Set-Historie für Update, Transfer, Failover und Recovery erhalten hat.

Revision 02 erschien am 28. September 2026. Sie änderte den beabsichtigten Status auf Standards Track und ergänzte einen vorgeschlagenen IANA-Bereich für MTL Types. Das Dokument bleibt ein Individual Internet-Draft, kein von DNSOP übernommener Entwurf, kein IETF-Konsens und kein RFC. Die Algorithmusnummer steht weiter auf TBD. LDNS, NSD, Unbound und eine C-Bibliothek werden als Testimplementierungen genannt; der Draft warnt ausdrücklich, dass die Angaben unbestätigt sind und keine IETF-Empfehlung darstellen.

Der Größendruck ist real. NISTs ML-DSA bietet postquantenfeste digitale Signaturen, doch eine Vollsignatur ist für heutige DNSSEC-Profile groß. Eine Wiederholung pro RRset vergrößert Zone, Cache und Antwort. Merkle Tree Ladders verteilen die teure Operation auf mehrere Nachrichten.

Der DNSKEY trägt den öffentlichen ML-DSA-Schlüssel. Der Signierer wählt pro Nachricht einen Randomizer, berechnet einen Leaf Hash und vergibt fortlaufende Indizes ab null. Die Blätter wachsen in einem Node Set mit 32-Oktett-SID. Rungs authentisieren den jeweiligen Bestand. ML-DSA signiert Flags, SID, Rung-Anzahl und Rung-Daten des Ladders.

Ein vollständiger RRSIG enthält außerdem Leaf Index, Randomizer, Sibling Hashes und den signierten Ladder. Der Resolver prüft dessen Signatur, berechnet das Blatt aus dem RRset neu und folgt dem Authentication Path zu einem passenden Rung. Danach bleibt die gewöhnliche DNSSEC-Vertrauenskette. Eine schwere Signatur kann so viele RRsets erfassen.

Die Ersparnis basiert auf geordnetem Zustand. Der SID benennt die Serie, der Index die Position, der Randomizer beeinflusst das Blatt, und die Rungs ändern sich mit jedem Anhang. Für eine ältere Nachricht kann ein neuer Pfad relativ zum aktuellen Ladder nötig werden. Kompression macht die Historie nicht entbehrlich; sie macht sie gemeinsam.

Der Draft verbietet dieselbe SID für verschiedene MTL-Instanzen und nennt KSK- und ZSK-Node-Sets als Beispiel. Ein korrekt verwahrter privater Schlüssel reicht daher nicht. Der Betreiber muss auch Rolle, Serie, nächsten Index und akzeptierte Ladder-Generation kennen.

Ein Cluster kann aus Offline-KSK, Online-ZSK, Hidden Primary, mehreren Signierern und einem Disaster-Recovery-Standort bestehen. Startet ein Standby aus einem alten Snapshot, könnte es einen Index neu verwenden, einen alten Ladder fördern oder eine neue SID beginnen. Jede Variante braucht Regeln. Revision 02 spezifiziert sie nicht.

Der Umfang ist offen ausgewiesen. Das Dokument konzentriert sich auf Code Points, DNSKEY/RRSIG und Kryptographie. Zone Signing, Composition, Updates, Transfer, Nameserver-Verarbeitung, Resolver-Verarbeitung und Caching bleiben späteren Texten vorbehalten. Daraus folgt nicht, dass Recovery unmöglich wäre. Es folgt, dass sie noch nicht interoperabel beschrieben ist.

Batch Signing zeigt den Nutzen und die Kosten. Mehrere RRsets werden angehängt, bevor ein neuer Ladder signiert wird. Das senkt durchschnittliche ML-DSA-Operationen und HSM-Last, verzögert aber die verfügbare Signatur für neue Daten. Der Betreiber darf die Batch-Größe wählen; ein Produktionsdienst braucht trotzdem maximale Wartezeit, Promotion-Regel und Schutz gegen Generation-Drift.

Online Signing kann laut Draft für jede dynamische Antwort ein neues Node Set erzeugen. Damit verkürzt sich geteilter Zustand, aber die Amortisierung kann auf dieselbe Query begrenzt bleiben. Ein Feature-Häkchen sagt deshalb nichts über CPU, HSM, Latenz oder Wiederanlauf.

Revision 01 entfernte die EDNS(0)-Option der ersten Fassung und machte den vollständigen MTL-Type zur einzigen Antwortart pro RRset. Revision 02 sagt, dass solche Antworten DNS over UDP stets überschreiten. Sie erwartet mehr TCP und empfiehlt TCP von Beginn an, wenn Clients Truncation plus Retry vermeiden wollen.

TCP löst Transport, nicht Kohärenz. Eine erfolgreiche Verbindung beweist keine gleiche Ladder-Generation auf allen Autoritativen. Ein gültiger Merkle-Pfad beweist keine Algorithmusunterstützung. Er ersetzt weder DS/DNSKEY-Kette noch Trust Anchor. Und DNSSEC-Validität ist kein Nachweis des Anwendungserfolgs.

Der bereits veröffentlichte SigTag-Artikel besitzt eine andere Grenze: Client-Aussage über gecachte Ladders, Full/Condensed-Auswahl, Privacy und Fallback. Diese Analyse setzt früher an. Bevor ein Resolver einen Ladder wiederverwenden kann, muss der Signierbetrieb ihn konsistent erzeugen, erhalten, übertragen und wiederherstellen.

Running-Code-Primacy wertet Testcode weder ab noch über. Repositories belegen Experimentierbarkeit. Ein Standards-Track-Ziel und beantragte Nummern belegen Absicht. Adoption verlangt unabhängige Tests von Update, Transfer, KSK/ZSK-Trennung, Rollback, Failover und TCP-Kapazität mit überprüfbarer Validierung.

Ein Ladder-Receipt sollte Schlüsselrolle, SID, Indexbereich, Rungs, SOA Serial, Signierer, Softwarestand, Erzeugungszeit und Vorgänger festhalten. Im Recovery-Test wird bewusst ein veralteter Stand gestartet. Das System muss ihn zurückweisen, korrekt fortsetzen oder sichtbar in eine neue Serie überführen. Erst dann wird aus Testcode ein Betriebsbeleg.

Quellen