Zusammenfassung

  • Revision 00 definiert eine EDNS(0)-Option, mit der ein Client bis zu acht bekannte SigTags meldet und so kondensierte MTL-Signaturen anfordern kann.
  • Der 32-Byte-Wert identifiziert eine signed ladder, beweist aber weder Cache-Besitz noch richtigen Signer, erfolgreiche Validierung oder ein sicheres DNSSEC-Ergebnis.
  • Vollständige Signatur-Rückholung, signerbezogene Cache-Belege und Datenschutzkontrolle gehören zur Betriebsarchitektur, nicht in eine spätere Fehlerbehandlung.

Die fehlende Ladder wird zur lokalen Abhängigkeit

Eine vollständige ML-DSA-MTL-Signatur verbindet einen kondensierten Merkle-Pfad mit einer signed ladder, die die zugrunde liegende ML-DSA-Signatur trägt. Eine Ladder kann viele RRsets abdecken und Kryptografie amortisieren. Der Basisentwurf hält jedoch fest, dass eine vollständige Antwort nicht in DNS über UDP passt.

SigTag bildet SHAKE128(SIGNED_LADDER, 256) über die serialisierte Ladder. Meldet der Client einen passenden Wert und besitzt der Server die Ladder, darf er MTL-Type 0x02 senden. Fehlt die Übereinstimmung oder hat der Server die Ladder verworfen, muss die volle Signatur zurückkommen.

Der Resolver übernimmt damit die fehlenden Bytes. Er muss die richtige Ladder laden, ihre Signatur gegen den passenden DNSKEY prüfen, den Authentication Path zum RRset verifizieren und danach die gewöhnliche DNSSEC-Kette abschließen. Ein Tag ist eine Formatentscheidung, kein Vertrauensurteil.

Signer-Bindung ist Teil des Beweises

Der Basisentwurf warnt, dass verschiedene Signer dieselbe SID verwenden können. Deshalb gehört der Signername in den Cache-Kontext. SID oder SigTag allein sind keine globale Autoritätskennung. Ein mathematisch passender Eintrag kann sonst unter dem falschen Namen gültig erscheinen.

Auch zeitlich fallen Behauptung und Besitz auseinander. Ein Eintrag kann nach dem Absenden verdrängt werden; Key Rollover kann den Kontext ändern; der Server kann seine Kopie verlieren. Der empfangene kondensierte Pfad bildet einen dritten Zustand. Ein gemeinsamer „hit“-Zähler würde drei Übergaben verschleiern.

Mit leerer Option kann ein Client Unterstützung anzeigen, ohne bekannte Tags offenzulegen. Ein unterstützender Server antwortet leer und kann innerhalb derselben Antwort deduplizieren: zuerst full, danach condensed. Dieses Echo bescheinigt keine Validierung.

Fallback verhindert, dass Optimierung zur Sperre wird

Bei ungültiger Antwort nennt Revision 00 drei Wege: erneut mit leerer Option, ohne SigTag für vollständige Signaturen oder über einen anderen DNS-Server. Mismatch und fehlender Payload sind ausdrücklich Beispiele.

Diese Wege bestimmen die Verfügbarkeit. TCP kann bestimmte Truncation-Schleifen vermeiden, ersetzt aber keinen Nachweis für Validierung oder Applikationsnutzung. Betreiber sollten Bytes, UDP/TCP, Retry, Upstream-Wechsel, DNSSEC-Status und Anwendungsergebnis getrennt führen.

Der Cache verrät auch Vergangenheit

Ein bekannter SigTag zeigt einer Authority, welche Ladder der Client zuvor gesehen hat. Der Entwurf nennt daraus ableitbare Query-Historie und Tracking durch individuell vergebene Ladders. Eine stets leere Option behält die Deduplizierung innerhalb einer Antwort; Löschen beim Adress- oder Interfacewechsel begrenzt Lebensdauer.

Beides kostet Optimierung und garantiert keine Anonymität. Der Resolver-Betreiber muss diese Abwägung kontrollieren. Weder die Authority noch ein Softwareanbieter erhält durch das Protokoll ein allgemeines Mandat zur Profilbildung.

Registrierungsantrag ist kein Betriebsbeleg

Revision 00 stammt vom 28. September 2026; EDNS-Code und MTL-Type stehen noch auf TBD. LDNS, NSD und Unbound werden als Testimplementierungen genannt. Derselbe Abschnitt erklärt, dass diese Angaben von Mitwirkenden stammen, ungeprüft sind und keine IETF-Billigung bedeuten.

Ein IANA-Wert macht Syntax gemeinsam verständlich. Quellcode zeigt Implementierbarkeit. Erst versionierte Tests, Traces, Rollover- und Fehlerverteilungen belegen laufenden Betrieb.

Quellen