Summary

  • draft-hdong-dnsop-ml-dsa-mtl-dnssec-sigtag-ext-00 lets a DNS client identify signed Merkle Tree Ladders it believes it already holds, allowing a server to send only a condensed signature when one matches.
  • A SigTag is a 32-octet hash-derived identifier, not proof that the client retained the ladder, associated it with the right signer, validated it or will obtain a secure DNSSEC result.
  • The operational design is incomplete without a full-signature recovery path, signer-scoped cache evidence, privacy controls and separate records for DNSSEC validation and application outcome.

The missing bytes did not disappear

Post-quantum DNSSEC has a transport problem before it has an adoption story. In the base ML-DSA-MTL design, an RRSIG contains a condensed Merkle authentication path and a signed ladder carrying the underlying ML-DSA signature. One ladder can cover many RRsets, reducing repeated cryptographic work, but a full response still has to transport the large ladder. The base draft says a full response exceeds DNS over UDP.

SigTag moves those bytes out of the current response when the client claims to have them already. The tag is SHAKE128(SIGNED_LADDER, 256). A resolver places up to eight 32-octet tags in an EDNS(0) option. For each MTL RRSIG, the server compares the advertised set with the ladder it would otherwise send. No match requires a full signature. A valid match permits a condensed signature whose MTL-Type is 0x02.

That is a precise optimization, not compression by declaration. The omitted signed ladder must still exist in the resolver’s cache, and its signature must still have been or be capable of being validated under the applicable DNSKEY. The condensed authentication path must still place the RRset under a compatible rung. Ordinary DNSSEC chain validation still applies. SigTag changes where the verifier gets one proof object; it does not repeal the proof.

Three states that look like one tag

The query says only that the client believes a tag is relevant. It does not prove possession. A resolver may have evicted the ladder after constructing a query, stored it under the wrong context, retained corrupt bytes, or associated an SID with the wrong signer. The base draft explicitly warns that another signer can use the same SID and therefore cached ladders must be tied to the signer’s name.

The server has a different state. Even with a tag match, it may no longer possess the referenced ladder; revision 00 then requires a full signature. The wire response has a third state: the authentication path and MTL-Type must correspond to the ladder the client will actually use. A matching identifier is not a receipt that all three states agree.

The empty option makes this separation visible. A client with no known tags can send SigTag with zero-length data to announce capability. A supporting server echoes an empty option. That exchange can enable deduplication inside one response: the first RRSIG carries the shared ladder and later RRSIGs carry condensed proofs. But the echo is not evidence of successful validation, and response option data must be ignored.

Fallback is part of the protocol claim

Revision 00 allows three recovery paths when validation fails: resend with an empty SigTag option, resend without SigTag and expect full signatures, or ask a different DNS server. These are not edge-case decorations. They determine whether a stale or mismatched cache entry becomes a recoverable optimization miss or a resolution outage.

Transport policy remains local. A client worried about retries can start over TCP. Another may try UDP, observe truncation and move to TCP. A full MTL response being too large for UDP does not prove that a particular condensed response fits, arrives or validates. Operators need traces that separate bytes saved, truncation, transport switch, retry, validation and final resolver status.

The tag also carries history

A non-empty SigTag tells an authoritative server something about a ladder the client has previously received. The draft notes that this can expose query history or permit tracking if an authority gives different clients unique ladders. Sending only an empty option preserves same-response deduplication while withholding known-tag state. Flushing the related cache after an address or interface change is another suggested mitigation.

Neither is a privacy guarantee. A stable tag can join other observable features; aggressive flushing can erase the state needed for the bandwidth saving. The party bearing that trade-off should control it. An authoritative operator should not silently turn resolver cache identifiers into durable client labels, and a resolver vendor should not bury disclosure policy inside an opaque optimization toggle.

A draft and a deployment are different receipts

Revision 00 was posted on 28 September 2026. Its EDNS option code and new MTL-Type registration are still TBD. It lists test implementations in LDNS, NSD and Unbound, but the implementation-status text says those reports were supplied by contributors, were not independently verified and imply no IETF endorsement.

That distinction matters. IANA can eventually make a number interoperably meaningful; it cannot show that a resolver kept the right ladder. A repository can contain code; it cannot show production failure rates. A successful test can demonstrate one path; it cannot authorize every operator’s privacy, retry or trust-anchor policy.

Sources