要約

  • draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02は、RRsetごとの大きなML-DSA署名を、共通の署名済みladderと個別のMerkle proofへ組み替える。
  • 一つの応答で検証できても、node setの履歴が更新、zone transfer、signer切替、disaster recoveryを越えて保たれたことまでは証明しない。

revision 02は2026年9月28日付である。intended statusはStandards Trackへ変わり、MTL Type用IANA registryの提案が加わった。しかし現在もindividual Internet-Draftであり、DNSOP WG adoption、IETF consensus、RFCではない。algorithm numberはTBDのままだ。LDNS、NSD、Unbound、C libraryの記載はtest implementationの存在を示すが、draft自身が未検証・非endorsementの情報だと明記している。

背景には、DNSSECが避けられないサイズ問題がある。NISTが標準化したML-DSAはpost-quantum signatureを提供する一方、現在よく使われるECDSAより大きい。すべてのRRsetへfull signatureを付ければ、zone、cache、responseが膨らむ。Merkle Tree Ladderは、重い署名を複数メッセージで共有する。

DNSKEYにはML-DSA public keyが入る。signerはメッセージごとにrandomizerを選び、leaf hashを作り、0から連続するindexを割り当てる。leafは32-octet SIDで識別される一つのnode setへ追加される。複数のrungがその時点のnode setを認証し、ML-DSAはflags、SID、rung count、rung dataから成るladderに署名する。

full RRSIGはleaf index、randomizer、sibling hashesによるpath、signed ladderを運ぶ。resolverはDNSKEYでladder signatureを検証し、RRsetからleafを再計算し、compatible rungまでpathをたどる。その後に通常のDNSSEC chain validationが残る。一つの応答だけでこの工程を実行でき、一つのfull signatureで多数のRRsetを包める。

ただし共有対象は履歴を持つ。SIDはseriesを分け、indexは追加順を示し、randomizerはleafへ入る。leafが増えるとrung構成も変わる。過去のメッセージでさえ、current ladderに合わせて新しいauthentication pathが必要になる場合がある。サイズを減らした代わりに、どのseriesのどの時点かが重要になった。

draftは同じSIDを複数のMTL instantiationに使うことを禁止し、KSK node setとZSK node setを具体例に挙げる。private keyを安全に保管するだけでは足りない。どのkey roleがどのSIDを持ち、次のindexを誰が割り当て、どのladder generationをauthoritativeとするかも守らなければならない。

たとえばstandby signerが一世代古いsnapshotから起動したとする。鍵もzoneも正しい。それでも次のindexを再利用するか、古いladderを再発行するか、新しいSIDを開始するかもしれない。どの選択が正しいかは運用設計次第だ。revision 02は、zone signing、composition、update、transfer、name server処理、resolver処理、cacheを将来の文書へ残している。

これは復旧不能という意味ではない。必要なmaterialから再構築できる実装も、stateを複製する実装も、切替時に新seriesを始める実装もあり得る。現時点で言えるのは、それらを共通のcontinuity contractとして規定していないことだけだ。古いproofのvalidityから、将来のstate continuityを推定してはいけない。

batch signingはこの差を経済に変える。複数RRsetを一度にnode setへ加えれば、ML-DSA operationとHSM loadを平均化できる。しかしbatchを待つほど新しいデータのproofは遅れる。operatorはzone特性に応じて選べるが、productionでは「何分まで待つか」と「cluster全体でどのladderを昇格させるか」を決める必要がある。

online signingも同様である。draftはquery responseごとに新node setを作る例を示す。それなら長い共有履歴は減るが、amortizationは同じquery内へ縮む。対応可否のチェックだけでは、CPU、HSM、latency、recoveryの実力を表せない。

wire側にも大きさは残る。revision 01はrevision 00のEDNS(0) optionを削除し、すべてのRRsetでfull MTL-Type responseだけを使う設計にした。revision 02は、その応答が必ずDNS over UDPを超えると記す。truncation後のTCP retryを避けたいclientには、該当zoneで最初からTCPを使うよう勧める。

TCPは必要なbytesを運ぶが、stateを一致させない。TCP responseの成功はauthoritative nodesのladder generation一致を証明しない。Merkle pathの成功はDS/DNSKEY chainをtrust anchorまで自動的に完成させない。DNSSEC validationの成功もapplication resultではない。

既刊のSigTag記事は別の境界を扱った。clientが保持していると主張するladder、serverのfull/condensed選択、privacy、fallbackである。本稿はその前段を担当する。再利用の前に、signer側がladderを一貫して生成し、保存し、移行し、復旧できなければならない。

running-code primacyで見ると、document statusやcode pointは開始条件にすぎない。test codeは大切だが、deployment evidenceではない。独立実装がupdate、transfer、KSK/ZSK分離、rollback、failover、TCP負荷を通過し、real trust anchorから検証されて初めてadoptionを語れる。

運用receiptにはkey role、SID、index range、rungs、SOA serial、signer identity、software version、生成時刻、predecessorを残すべきだ。受入試験では意図的に古いbackupを復元し、同じseriesを正しく続けるか、明示的なtransitionで新seriesへ移ることを確認する。一件のvalid responseだけでは、その試験を代替できない。

情報源