要約

  • DNSOP議長は2026年9月1日、draft-huque-dnsop-multi-alg-rules-08の採択には明確な支持があると判断しつつ、仕組みの複雑さを今後の課題として明記した。
  • 草案はUNIVERSALとFORMERLY-UNIVERSALを設け、条件を満たせば署名者が広告済みアルゴリズムの一部の署名を省けるようにする。
  • 同じ分類は、アルゴリズムをローカルに無効化した検証者の判定も変えるため、説明用の札ではない。
  • Daniel Kadeは、将来の分類変更ごとに、文書採択とは別の、日付付き展開証拠レシートを付けるよう提案する。

二つの文で成立した採択

採択コールを閉じたメールは簡潔だ。文書採択への支持は明確だった。だが、提案された仕組みの複雑さに関する懸念は、ワーキンググループの今後の作業で扱うべきだと続く。後半は但し書きではなく、採択が確定しなかった範囲を示す。

コールは8月13日に始まり、31日に終わった。現在のDatatrackerは、このActive Internet-DraftをDNSOPのAdopted by a WGと表示する。一方、IESG状態はI-D Existsのままで、shepherd、担当Area Director、telechat日は載っていない。第08版はワーキンググループの変更管理に入ったが、RFCにもIETF承認済み規則にもなっていない。

採択は、問題と原案を誰が引き受けるかを決める。どの文言を残すかは、この後の仕事である。今回は議長自身が、その編集余地を記録した。

現行規則が全署名を要求する理由

RFC 4035は、zone apexのDNSKEY RRsetにある各アルゴリズムについて、少なくとも一つのDNSKEYで各RRsetを署名するよう求める。apex DNSKEY RRsetは、親DS RRsetに現れる各アルゴリズムでも署名される。RFC 6840は署名者側の完全性要件を言い直す一方、検証者には一つでも有効な経路があれば受け入れるよう求める。

署名者は、世界中の検証者がどのアルゴリズムを理解するかを知れない。そこで、広告した全アルゴリズムの署名を揃え、対応可能な署名が攻撃で除去された状態と正常な省略を区別する。この安全側の規則は、事業者間の結合も生む。RFC 8901のmulti-signerモデルでは、参加事業者が共通の署名アルゴリズムを使う必要がある。対応集合が交わらない二社を、そのまま移行区間に並べることはできない。

第08版は、この制約を緩めようとする。恒常的multi-signer、異なるアルゴリズムを使うプロバイダー間の移管、KSKとZSKの別々の変更、trust anchorの先行公開、そして一社だけによる新アルゴリズム試行が用途として並ぶ。DNSOPは問題を作業対象にした。解法の細部までは採択していない。

IANAの一語が応答を変える

草案は、IANAレジストリにValidation support status列を追加し、UNIVERSAL、FORMERLY-UNIVERSAL、空欄の三状態を置く。初期値ではアルゴリズム8と13だけがUNIVERSALになる。現行のIANA DNSSECアルゴリズムレジストリにこの列はない。8と13については、DNSSEC検証の実装要件がMUSTと記録されている。

提案上、DSまたはtrust anchorの集合にUNIVERSALが一つ以上あり、FORMERLY-UNIVERSALがなければ、署名者は一つのUNIVERSALアルゴリズムで署名すればよい。他の広告済みアルゴリズムの署名は任意になる。条件を外れれば全アルゴリズム署名へ戻る。

検証者にも分岐がある。広告されたUNIVERSALまたはFORMERLY-UNIVERSALを検証者が非対応とすると、別の広告済みアルゴリズムに対応できても、そのzoneをunsignedとして扱う。それ以外は有効な経路を受け入れる。ローカル方針でアルゴリズムを無効化した後も、過去にUNIVERSALだったかという記憶が要る。

つまり分類は人気度ではない。署名者が何を省略でき、検証者がInsecureとBogusのどちらを返すかに関わる実行入力である。古い分類は、古い文書として残るだけでなく、稼働中の到達性判断に残る。

RFC 9904は、既存の実装要件と利用推奨をIANAレジストリへ移し、相互運用のために実装するものと、運用者が選んで使うものを分けた。推奨は時間とともに変わり、廃止は通常段階的に行う。新しい分類は別の役割を持つ。同じ表に載るからといって、既存列の根拠を自動的に借りられるわけではない。

反対意見も作業対象に入った

公開スレッドには、議長が複雑性を残した理由が見える。Mark Andrewsは草案に反対し、世界の全検証者に関する前提を批判した。Paul Hoffmanは旧来の全署名要件を緩める目的には賛成したが、現在の二つの分類には反対した。Paul Woutersは採択を支持し、大幅な単純化を望んだ。

いずれも個人の意見であり、この記事が票として数え直せるものではない。重要なのは、制度的な結論が消さなかった論点を特定できることだ。DNSOPが引き取ったのは、反論を終えた設計ではなく、反論を材料に変えられる設計である。

草案も限界を認める。普遍的な対応状況はプロトコルだけでは判定できない。非対応の検証者人口が無視できると判断できる時にだけ、コミュニティがアルゴリズムをUNIVERSALへ進めるべきだとする。この「無視できる」には、観測範囲と時点が必要だ。

分類変更には別のレシートを

将来のStandards Actionで状態を変えるたび、短い展開証拠レシートを公開すべきだ。アルゴリズム番号、レジストリ版、測定日、観測した検証者群、既知の除外、旧実装、非対応人口を無視可能とした基準を結び付ける。

さらに、代表的なmulti-signerと移管状態におけるSecure、Insecure、Bogusの予想、ローカル優先方針との衝突、発効期間、署名者依存、緊急切替とロールバックの責任者を示す。個々のresolver名や企業のfleet情報は保護できる。世界規模の結論がどこまでを見たかは保護対象ではない。

Heng Luの最小共通層という考え方を当てれば、共通分類が持てるのは、独立運用者の相互運用に不可欠な事実だけだ。複数の利用可能アルゴリズムから何を優先するかは、後の標準決定が明示的に境界を変えない限り、ローカルに残すべきである。

DNSOPは、扱う問題を決めた。UNIVERSALという強い言葉の意味と証拠は、まだ決めていない。採択レシートと分類レシートを分けることで、この未決状態を正確に保てる。

出典