要約

  • 10月16日に提出された意見は、DNSSECの委任署名者（DS）自動化に関するICANNの評価を、IETFが公開したRFC 10026と整合させるよう求めている。
  • 6月の報告書は一節でレジストリ更新ロック中の自動化停止を求める一方、別の節ではレジストリ側の処理を続けられるとしている。必須要件HR-4が明記するのはレジストラ側のロックだけだ。
  • ICANNは意見を検討し、評価を更新する可能性がある。募集は11月23日に締め切られ、意見報告書は12月7日までに提出予定。最終判断や契約文案はまだ出ていない。

焦点はDNSSEC自動化の是非ではない。親ゾーンのDSレコードを変更するとき、登録状態のロックがどの主体を拘束するのか、という点だ。Quynh Nguyenが10月16日に提出した意見書は、ICANNによるDNSSEC DS自動化の安全性・安定性評価に対し、この点を明確にするよう求めた。

Nguyenは、評価が主要な安全上・安定上の論点を扱っていると認めつつ、serverUpdateProhibitedの扱いは一貫させるべきだと述べる。本人は個人の立場で提出したとしており、ICANNの判断でもコミュニティの合意でもない。ただし、ICANNがレジストリ運用者向けに検討しているFast-Track RSEPの技術的な土台にこの評価が使われるため、条文の読み違いは将来の運用要件に関わる。

Interisle Consulting Groupの評価報告書は2026年6月23日付だ。第4.4節は、serverUpdateProhibitedが設定されている間はDSの自動保守を停止すべきだという見解を採用する。同節は、当時のIETF草案がレジストリ主導の自動化について逆の立場を示していたことも説明している。このEPPステータスが拒否を求めるのはレジストラからの更新要求であり、レジストリ自身が変更することまで禁じてはいない、という整理だ。

その草案は7月にBest Current Practice 246としてRFC 10026になった。第6.1(2)項は、レジストリがDS保守を行う場合、serverUpdateProhibitedだけを理由に自動化を停止してはならないとする。第6.2.1節も、レジストラからのEPP更新は拒否される一方、レジストリ自身の自動化は妨げられないと説明する。レジストリが変更通知を送ることで、レジストラが変化を把握できる。

評価報告書の内部にも食い違いがある。第4.7節はclientUpdateProhibitedとserverUpdateProhibitedの双方が存在しても処理は進められると述べ、第6.1節も、レジストラがレジストリ主導の自動化から除外できるなら、通常保守を停止する必要はないとする。一方、HR-4が明示的に禁じるのはclientUpdateProhibitedだけを理由とした停止だ。Nguyenは、RFC 10026に沿ってルールを一本化するよう求めている。

もう一つの基準は8月31日に公表されたSSACのSAC126v2だ。SSACは、RFC 10026の確定を受けて助言を改訂し、同規格が旧版の第4.4節の問いを解決したと説明した。SAC126の第1版は退役した。6月付のICANN評価は、正式版RFCと最新のSSAC助言が出る前に作られている。

意見書はほかにも、権威ネームサーバーを恒久的に到達不能と判断する条件と再試行間隔、不整合な応答で遅れる鍵更新の扱い、DS削除が下流サービスに及ぼす影響、成功・拒否それぞれの通知と監査記録を明確にするよう提案している。いずれも一人の提出者の提案であり、採択済み要件ではない。

ICANNの公開意見募集ページは、意見概要を公表し、評価の更新と追補を検討するとしている。締切は2026年11月23日、報告書の提出期限は12月7日だ。Fast-Trackの契約修正案は別の手続きで意見募集される予定である。評価報告書も今回の意見も、導入を承認したり、後続の契約条件を確定したりするものではない。

出典