要約

  • draft-hdong-dnsop-ml-dsa-mtl-dnssec-sigtag-ext-00 は、client が既知と考える signed ladder を最大八つの SigTag で示し、server が一致する ladder の再送を省けるようにする。
  • 32 octet の SigTag は ladder 由来の識別子であり、client が bytes を保持し、正しい signer に結び付け、検証済みであることを証明しない。
  • full signature への回復、signer 単位の cache、privacy 方針、DNSSEC validation と application outcome の分離があって初めて運用可能になる。

省略された ladder は verifier 側へ移った

基礎となる ML-DSA-MTL では、full signature は Merkle authentication path を持つ condensed signature と、基礎 ML-DSA signature を持つ signed ladder から成る。一つの ladder が複数 RRset を覆うため計算を共有できるが、full response は DNS over UDP を超えると基礎 draft は述べる。

SigTag は ladder の serialized bytes に SHAKE128(..., 256) を適用した値である。client が EDNS(0) option に既知の値を並べ、server が対応する ladder を持つ場合、該当 RRSIG を MTL-Type 0x02 の condensed 形式にできる。一致しない場合、または server がその ladder を失っている場合は full signature が必要になる。

ここで消えたのは wire 上の重複だけだ。resolver は cache から正しい signed ladder を取り出し、その署名を DNSKEY に対して検証し、authentication path が RRset を適切な rung に接続することを確かめる。その後も通常の DNSSEC chain validation が続く。tag match は response の形を選ぶ条件であって、secure 判定ではない。

cache key に signer が必要な理由

同じ SID を別の signer が使う可能性がある。基礎 draft が cached ladder を signer name と関連付けるよう注意するのはそのためだ。SID や SigTag だけを global identity のように扱うと、正しい hash が誤った authority context に置かれ得る。

さらに query は client の「持っているはずだ」という状態しか伝えない。送信後の eviction、破損、rollover 中の key context のずれは起こり得る。server 側にも別の保有状態があり、wire 上の condensed path にも整合性がある。この三つを一つの cache-hit 指標で表してはならない。

未知の tag しかない client は OPTION-DATA を空にして対応能力だけを示せる。server の空 option echo も能力表示にすぎない。同一 response 内で複数 RRSIG が同じ ladder を使うなら、最初だけ full、後続を condensed にする deduplication が可能だが、echo 自体は validation receipt ではない。

失敗から戻れることも仕様の一部

revision 00 は validation 不能時に三つの fallback を示す。空の SigTag で再問合せする、SigTag を外して full signature を求める、別の DNS server に送る、である。mismatched condensed signature や payload 欠落が具体例だ。

この経路がなければ、bandwidth optimization は availability dependency に変わる。UDP から TCP へ切り替える policy も local である。full MTL response が UDP に収まらないという事実から、condensed response の到達、検証、application 利用まで推定してはいけない。

既知の tag は閲覧履歴にもなる

non-empty SigTag は client が以前どの ladder を受けたかを authoritative server に知らせる。draft は、query history の推測や、client ごとに異なる ladder を発行する authority による tracking の可能性を挙げる。

常に空 option を送れば同一 response 内の deduplication を使いつつ既知 state を隠せる。address や interface の変更時に cache を消す案もある。しかし前者は cross-query の削減を失い、後者は識別期間を短くするにとどまる。privacy と効率の配分は、それを負担する resolver operator の明示的な選択でなければならない。

draft、code point、running result

revision 00 の日付は 2026 年 9 月 28 日で、EDNS option code と MTL-Type の登録値はまだ TBD である。LDNS、NSD、Unbound の test implementation が列挙される一方、同節は contributor 提供情報であり、未検証で、IETF endorsement ではないと明記する。

番号は意味を共有させる。repository は code の存在を示す。だが、どちらも cache binding、interoperability、failure rate、privacy、application outcome を証明しない。running-code evidence には version、trace、検証段階、retry と失敗分布が要る。

出典