要約

  • ICANNはDNSSECのDSレコード自動化に関する安全・安定性評価について、リスクの特定と対策の十分性、相応性、実装可能性を意見募集している。
  • 評価の肯定的な結論は、七つの必須要件と七項目の運用開示に条件づけられている。すべての実装に対する包括承認ではない。

DNSSECの迅速審査でまず整理すべきなのは、登録ロックが自動処理に与える効力だ。 ICANNの意見募集ページが期限と審議範囲を示している。

6月23日付の評価書は、子ゾーンのDNS運用者がCDSまたはCDNSKEYを公開し、親側（通常はレジストリーかレジストラー）が検証して親ゾーンのDSを更新する方式を対象とする。信頼チェーンの維持、初回設定、DNSSECを無効にする移行の三つを扱い、プッシュ通知、帯域外API、CSYNCは対象外だ。したがって、すべての委譲変更や特定の事業者の実装を評価した文書ではない。Interisleの41ページ報告書は、指定の要件を満たす場合に重大な安全・安定性問題はないと結論づける。

その結論に必要な必須要件は七つある。親側は提案されたDSと子ゾーンのDNSKEYが一致し、該当する鍵がDNSKEYセットに署名していることを確認する。すべての権威ネームサーバーの応答を照合し、不一致なら処理を中止する。さらに手動管理画面を残し、レジストラーが自動化をオプトアウトできるようにし、DSをすべて削除する指示を正しく扱い、登録局が変更した場合はレジストラーへ知らせる。別の七項目では、スキャン間隔、応答時間、多署名者方針、通知先、初回設定の前提などを各運用者が文書化する。推奨される四つの実務慣行は、肯定判断の必須条件とは区別されている。

この区別は、共通の最低線と各社の判断を見分けるために重要だ。RFC 9975が求めるネームサーバー間の整合性は任意ではない。一方、問い合わせ頻度や通知方法は運用者の設計に委ねられ、その選択次第で誤更新の検知や復旧にかかる時間が変わる。報告書は、成功、拒否、状態不一致のすべてを伝える標準的な通知手段が引用されたRFCにはないと指摘する。レコードが正しく更新されても、関係者がそれを把握できなければ、運用上の見通しは残らない。

時点の差もコメントで確かめられる。評価書の日付は6月23日だが、IETFのRFC 10026は7月にBest Current Practiceとして公刊された。現在の意見募集ページはRFC 10026を参考資料に挙げている一方、6月付の評価本文には当時の草案という時間軸が残る。RFC 10026は受入確認、結果通知、登録ロック、複数主体による更新を扱う。6月の評価が直ちに無効になるわけではないが、7項目の必須要件と七つの開示事項が完成版のBCPにどう対応するのか、将来の申請でその対応を示すべきかは具体的な問いになった。

食い違いは報告書の登録ロック分析に現れている。報告書はSAC126の考え方を採り、serverUpdateProhibitedが設定された場合はレジストリ主導の自動処理を停止し、clientUpdateProhibitedだけなら続行するとする。一方、最終版のRFC 10026はレジストリ側のロックを異なる形で扱う。レジストリ自身は自らの状態を上書きできるため、そのロックだけを理由にレジストリ側の自動処理を止めるべきではないとする。異なる意思を示す制御は、レジストラによる自動化のオプトアウトだ。報告書の必須要件一覧にはクライアント側ロックの扱いは明記されるが、登録局側ロックの対応要件は並んでいない。ICANNの現行募集ページがRFC 10026を資料に挙げる以上、将来の申請と契約文言でどちらの規則を適用するのかを問える。

ICANN理事会は2025年9月、重大な安全・安定性問題が確認されないことを条件に、登録局向けの迅速なRSEP経路を整備するよう指示していた。レジストラーはICANNの承認なしにこのサービスを導入できるとの区別も示された。RSEPには予備判断が残り、必要なら技術評価パネルへの付託も可能だ。今回の評価は将来の登録局申請を比較しやすくする技術資料であり、特定の登録局への承認でも、新しい契約規則でもない。理事会決議とRSEP方針が、その境界を定める。

意見募集では、必須条件が現行BCPと整合するか、開示事項が待ち時間・通知・復旧を利用者に伝えるか、後続の契約文案が個別実装の確認を維持するかを検証できる。契約文案の募集は今回より後に行われるため、12月のコメント要約と次の手続きは別々に見る必要がある。共通のチェックリストが再利用可能でありながら、実装ごとの差を消さないかが、迅速審査の実効性を左右する。