要約

  • ICANNの評価によれば、RSEP上の重大なセキュリティ・安定性問題がないと判断できるのは、7つの必須要件を満たし、7つの設計上の選択を文書化した場合に限られる。さらに4項目が推奨されている。
  • これは方式全体への評価であって、個別レジストリへの承認ではない。意見募集、評価書への追補、各レジストリの申請、標準契約文言を扱う別の手続きが残る。

条件付きの肯定判断

今回のDNSSEC自動化評価で最も重要なのは、結論に条件が付いている点だ。Interisleの評価書は、7つの必須要件に従い、7つの設計上の選択を文書に示すなら、CDS/CDNSKEYによる自動化はRegistry Services Evaluation Policy（RSEP）が定める重大なセキュリティまたは安定性の問題を生じさせないと判断した。この結論は方式レベルでの肯定的な予備判断を支える。すべてのレジストリが審査済みである、どの実装も安全である、あるいは今日からサービスを有効化できる、という認定ではない。

「DNSSECの自動化」は一つの技術機能のように聞こえる。しかし、RSEPが問うのは、提案されたレジストリサービスが、範囲を意図的に限定した安全性・安定性の基準と契約手続きに適合するかどうかだ。報告書が評価するのは、明示された条件のもとでの方式群である。個々の運営者には、独自の申請、設定、契約上の手順が残る。

ICANNのパブリックコメント手続きは2026年10月12日に始まった。評価書が問題を適切に特定しているか、緩和策が十分で、均衡が取れ、実行可能かについて意見を求めている。提出期限は11月23日、取りまとめ報告書の期限は12月7日だ。ICANNは意見を検討し、必要に応じて評価を更新し、コメントへの見解をまとめた追補を公開するとしている。標準契約の修正文案は後日、別の手続きで意見募集される予定だ。

これらは別々の判断段階である。今の意見募集は、根拠とリスク対策を検証するものだ。DNSSECの有用性を問う投票でも、契約修正そのものでもない。公表された日程からは、制度設計がまだ進行中だと分かる。

標準化からレジストリサービスの審査へ

この取り組みの起点は2025年9月14日のICANN理事会だ。理事会はSSACのSAC126勧告を受け入れ、ICANN組織が安全性または安定性の問題を見いださないことを条件に、DS自動化のFast Track RSEPを設けるよう指示した。理事会決議が示したのは条件付きの制度上の指示であり、RSEP審査の自動免除ではない。

技術面の根拠は公開標準にある。RFC 7344、8078、9615は信頼関係の維持、削除、ブートストラップを扱い、RFC 9975は整合性を明確化する。RFC 10026は運用上の推奨事項を示す。評価書はこれらを、第三者DNS事業者を利用する場合の一連の方式として扱う。子ゾーンがCDSまたはCDNSKEYレコードを公開し、親側のレジストリまたはスポンサー登録事業者が取り込み、検証したうえで、対応するDSレコードを公開する仕組みだ。

焦点はレコードを導入すべきかではない。レジストリサービスの変更がRSEPの安全性・安定性審査を通過するには、何が満たされなければならないかだ。同ポリシーの安全性は、レジストリデータの不正な開示や改変、および一定の不正アクセスなどに結び付けて定義される。安定性は、権威ある標準への適合と、DNS応答の処理量、応答時間、一貫性や整合性を扱う。この限定は審査を具体化する一方、統治、競争、サービス品質、登録者の選択に関するあらゆる論点を解決するものではない。

報告書は規範上の重みに応じて項目を整理した。7つの必須要件は肯定判断の前提となる。7つの開示要件は運営者の選択を見えるようにする。4つの推奨事項は導入を強化するが、現行の標準環境では肯定判断に必須ではない。計18項目のチェックリストは、各項目を満たす証拠と例外の扱いが申請者と審査者の間で明確なら、技術審査の重複を減らしうる。

評価書は、結論が方式固有であり運営者固有ではないと明記している。各レジストリは申請時にチェック項目へ回答する必要がある。記載が欠けたり具体性を欠いたりすれば、追加協議やRegistry Services Technical Evaluation Panelへの付託につながる可能性がある。つまり技術評価の後にも、個別サービスとその制御策を審査する段階が残る。

評価書が解消していない点

残る三つの懸念は、結論に条件が付く理由を示している。複数の署名者がいる環境では、単純な実装だと一方の更新が別の事業者の鍵を排除しかねない。引用されたRFCは共通の報告手段を定めておらず、登録者や子側DNS事業者がイベントを一貫した方法で把握できるとは限らない。またRFC 9615のブートストラップは、権威ネームサーバーのホスト名がDNSSEC署名済みゾーンにあることを前提とし、適用範囲を狭める。

報告書は方式が利用不能だと言っているのではない。導入時の選択や適用範囲の制約を運営者が扱うべきだと指摘している。登録事業者自身がDNSも運営する場合は内部連携の問題として評価対象外であり、プッシュ方式や帯域外APIも対象に含まれない。DS自動化の全方式を網羅した審査ではない。

再利用できる技術的根拠と個別の認可を分けることには実務上の利点がある。共通の技術評価が受け入れられれば、各レジストリがゼロから分析を始めずに済む。しかし、現時点で公開記録が示しているのは、最終的な修正条項、承認済み申請、導入日、申請数、コスト、採用状況、事故の減少、利用者への効果ではない。Fast Trackがすでに費用を下げ、普及を速めたと述べれば、根拠を先取りすることになる。

追うべき順序は明確だ。まず公開コメントへの追補が論点にどう答えるか。続いて標準修正文案が18項目をどう取り込むか。その後、各レジストリのRSEP申請と予備判断がどう行われるか。これらを経て初めて、レジストリ、登録事業者、登録者は手続きが実務上予測可能かを評価できる。問われているのは、限定された技術判断を、包括的な許可と取り違えずに、明確で検証可能な条件へ移せるかどうかだ。