要約

  • RFC 10026はclientUpdateProhibitedとserverUpdateProhibitedを、特定の主体と命令経路に作用する制御として扱う。すべてのDS変更経路が凍結したという証明ではない。
  • 鍵のロールオーバーやアルゴリズム移行では、認証され検査を通ったDS保守を継続することがDNSSECの連続性を守る。ロック、子ゾーンの意思、親の判断、公開結果は別々に立証しなければならない。
  • 「ロック中」のバッジは、変更がなかったことも、変更が正当だったことも単独では示さない。必要なのは主体別の判断記録、通知、そして独立した復旧経路である。

緑色の南京錠は強い安心感を与える。ところが障害や不正の調査で、その画像が証明できるのは、ある時点の利用者画面に何が表示されていたかにすぎない。EPPサーバーが保持していた状態も、その後に誰がどの経路から親ゾーンを動かしたかも、画面の印だけでは分からない。

2026年7月にBest Current Practice 246として公表されたRFC 10026は、DNSSEC Delegation Signer（DS）自動保守の運用勧告である。RFC EditorはSteve ShengとPeter Thomassenを著者として記録している。この文書が明確にするのは、ロックを軽視することではない。ロックの名前に、実装上は持っていない権力を与えないことである。

接頭辞は誰が制御する状態かを示している

EPPドメイン名マッピングを定めるRFC 5731では、状態名の接頭辞が権限関係を表す。clientで始まる状態はスポンサーとなるクライアント、通常はレジストラが設定・解除する。serverで始まる状態はEPPサーバー、通常はレジストリが管理する。

clientUpdateProhibitedとserverUpdateProhibitedはいずれも、当該状態を取り除く要求を除き、オブジェクト更新要求を拒否するよう求める。文面は似ている。しかしクライアントはサーバー設定状態を変更できず、サーバーはローカルポリシーに従ってクライアント設定状態を変更または上書きできる。対称な名称の下には非対称な権限がある。

クライアント更新ロックが主に守るのは、スポンサー・レジストラがEPPクライアントとして送る通常の更新経路だ。レジストラ自身は設定した状態を解除できる。レジストリも、レジストラが付けた状態によって自らの実行能力を失うわけではない。顧客ポータルの誤操作や低権限アカウントの侵害には有効でも、レジストラやレジストリの侵害に対する完全な防壁にはならない。

サーバー更新ロックはレジストラに対してより強い。レジストラからの更新要求は拒否されるべきだからだ。それでも、サーバー運営者自身がローカルに認められた処理を行う能力まで暗号学的に消したとは書かれていない。その処理が妥当かどうかは、状態名ではなく、サーバーポリシーと権限、記録から判断する。

したがって最初に必要な証票は「ロックあり」ではない。設定主体、設定時刻、拒否対象の命令クラス、なお行動可能な主体と経路を一組で残すことである。

DNSSECでは、動かないことが継続性を壊す

登録情報なら、設定後にロックして長く触らない運用が合理的な場合もある。DNSSECの信頼状態は違う。署名鍵は交換され、暗号アルゴリズムは廃止され、DNS運用事業者も交代する。子ゾーンの変更に親ゾーンのDS集合が追随しなければ、古い値を守り続けることが検証不能を招き得る。

たとえば子が新しい鍵を用意しているのに、親が通常の更新ロックを普遍的な凍結と解釈してDSを動かさないとする。旧鍵の利用が終われば、検証器には子がもう使わない鍵を指す信頼参照だけが残り得る。データは改変されなかったが、そのデータが担うべき安全機能は失われる。

RFC 7344は、子ゾーンがCDSまたはCDNSKEYを公開し、親側のDS保守を要求する仕組みを定める。RFC 9615は、まだDS経路を持たない委任に対する認証済みブートストラップを加えた。どちらも無条件の命令ではなく、真正性や整合性、安全な結果を検査するためのプロトコル証拠である。

そこでRFC 10026は、clientUpdateProhibitedのようなレジストラ更新ロックだけを理由に自動DS保守を止めてはならないと勧告する。レジストリ自身が自動化を実施するときは、serverUpdateProhibitedのようなレジストリ更新ロックだけでも止めてはならない。初回のDS導入にも、その後のロールオーバーにも同じ考え方が適用される。

これは「ロックを無視せよ」という指示ではない。通常のEPPロックが拘束しない、別の認証済み保守経路を、言葉の印象だけで閉鎖しないという指示だ。帯域外確認や複数承認を要求する独自ロック商品は、より広い境界を持ち得る。その場合は解除権、緊急例外、レジストリ内部処理への効果を個別に記述しなければならない。

経路が開いていても、要求はまだ承認されていない

自動保守を継続できることと、届いた信号をすべて採用することは別である。RFC 10026は親が変更する前に複数の受入検査を求める。

親側エージェントは、まず子の意図が曖昧でないことを確かめる。CDSとCDNSKEYが共存するなら同じ鍵を指していなければならない。委任に列挙された権威ネームサーバー全体で、関連状態が信頼できる形で整合している必要もある。次に、提案後のDS集合を計算し、少なくとも一つの有効なDNSSEC検証経路が残ることを確認する。どちらかが失敗すれば更新は中止される。

この一連の処理は、異なる五つの主張を分ける。ロックの作用範囲、子側要求の存在、要求の認証と一貫性、変更後の検証継続、親による実際の公開である。

一つが他を証明することはない。ロックはCDSを認証しない。正しいCDSも全権威サーバーの一致を保証しない。一致しても変更後の検証継続は別問題だ。受入検査に合格しても公開が終わったとは限らない。公開後も再帰リゾルバーの旧DSキャッシュは一定時間残る。

ここで、全権威サーバーを見る議論とロック範囲の議論を混同してはならない。前者は子サービスが一つの明確な要求を表現しているかを問う。後者は登録状態がどの管理主体のどの命令を拘束するかを問う。証拠は隣り合っていても代替できない。

レジストラのロックはレジストラ自身を止めない

RFC 10026の現実的な指摘は、マーケティング上の「完全保護」と相性が悪い。クライアント更新ロックを付けたレジストラは、自分でそれを外せる。レジストリはサーバーを管理している。高権限主体が侵害されたとき、直前に画面上のロックが存在した事実だけでは、その主体の行動を止められない。

だからといってロックが無価値になるわけではない。ロックは存在中の通常更新を拒否し、操作ミス、顧客アカウント悪用、不出来な自動処理を減らせる。価値を正しく保つには、脅威モデルを越えた保証を主張しないことが必要だ。

インシデント調査でも、ポータルのスクリーンショットは表示層の証拠にとどまる。サーバー側状態の読戻し、変更主体、使われた認可、受入検査、親DSの差分がそろって初めて実行経路が見える。画面と結果が違うだけで侵害と決めつけるのも、バッジがあったから安全だったと結論するのも早い。

独自のレジストリロックが電話確認、別資格情報、二者承認、待機期間を要求するなら、実際の制御は確かに強くなり得る。ただし評価すべきなのは名称ではなく、その製品の解除・上書き・緊急時の意味である。更新ロック、移転ロック、削除ロック、帯域外ロックは別々に扱わなければならない。

正しい変更ほど、関係者に見える形が要る

レジストリ・レジストラ・登録者という構造では、レジストリ側の自動化がレジストラの通常更新命令なしに正当にDSを変える場合がある。するとロックは見えたままなのに、登録者やレジストラには理由が見えないという問題が起きる。

RFC 10026は権限と可視性を分け、報告を別の経路で補う。レジストリがDS自動化を行う場合、RFC 8590のEPP Change Poll拡張または同等の手段でレジストラに知らせるべきだ。重要な更新や無効化は関係連絡先にも通知し、登録者または指定者が現在のDS構成を管理画面で確認できるようにする。

親側エージェントには構造化された判断記録も必要である。時刻、契機となったCDS/CDNSKEY、通知経路、照会した権威ネームサーバー、検証結果、採否、適用したDS集合または中止理由を残す。

この台帳があれば、「ロック中なのに正しく変わった」という表現を監査可能な順序へ変換できる。ロックは対象経路で効き続け、別の認証信号が別経路に入り、安全検査を通り、権限を持つ親運用者が処理し、レジストラへ通知され、公開状態が更新された、と段階ごとに示せるからだ。

欠落があれば結論の範囲を狭める。通知がないなら報告の失敗であって、ただちにDSの不正を証明しない。DSの変更は親での公開を示すが、要求の真正性までは示さない。画面のバッジは利用者向け表示を示すだけで、EPPサーバーの判断ではない。

復旧は失われた鍵と同じ仕組みに依存できない

自動化を唯一の入口にすると、別の故障が生じる。子がロールオーバーを認証する署名鍵を失うことがある。複数運用者の一社が協力を拒むことも、DNS事業者がCDS/CDNSKEYに対応しないこともある。

RFC 10026は、その場合に使える別のDS保守経路をレジストリとレジストラが提供するよう求める。手作業でもよいが、帯域内の証拠をもう作れない状況から制御を取り戻せなければならない。現在鍵を使って遷移を認証する仕組みは、その鍵を喪失した後には同じ方法で証明を再生できない。

手動復旧も無記録の例外にしてはならない。組織を代表して要求した者、帯域外確認、求めるDS状態、自動化の一時停止、再開条件、親からの最終読戻しを保存する。「人が直した」という説明だけでは、境界のない別経路を生む。

Shengの名前は貢献を示すが、運用権限ではない

RFC EditorはSteve ShengとPeter ThomassenをRFC 10026の著者としている。IETF DatatrackerではShengのRFCとしてRFC 7485とRFC 7710も記録される。ICANNの公式会議資料は2022年の彼をPolicy Development Support担当Senior Directorとし、現在の公開略歴は、2024年にICANNでの15年間の技術政策研究を終えたこと、Carnegie Mellon UniversityでEngineering and Public Policyの博士号を得たことを記す。

これらは、プロトコルと制度運用が交わる領域への公開された貢献を位置づける。しかしShengがレジストリ、レジストラ、親ゾーン、実装を管理することを意味しない。IETFの合意文書は個人命令ではなく、著者名は普遍的な導入を保証しない。

著者性の境界はロックの境界によく似ている。名前は貢献者を特定するが運用権限を移転しない。状態名は禁じる処理を特定するが、すべての主体を拘束しない。人物の実績を正確に扱うには、集合的な標準形成と現場の決定権を分ける必要がある。

最後に必要なのは主体を結んだ判断証票である

再構成可能なDS変更記録は、利用者画面とサーバー側のロック状態、設定者、時刻から始まる。次に提出主体と経路、CDS/CDNSKEYの内容、認証結果、全権威サーバー整合性、変更後の検証予測、ローカル受入ポリシー、最終判断を結ぶ。

その後に親での公開時刻、DS集合、関連TTL、レジストラと登録者への通知、リゾルバーから見た確認、独立復旧経路を加える。秘密や無関係な個人情報は不要だが、権限と結果を説明する証拠は必要である。

ここでの共通最小仕様は明快だ。通常の登録ロックに、認証済みDNSSEC継続性を偶発的に壊させない。同時に、自動化によって復旧を消さない。運用者はより強いロックや追加検査、異なる通知を選べるが、それぞれが拘束する主体と経路を明示しなければならない。

「ロックされているから安全」よりも長く使える原則がある。ロックが証拠になるのは、文書化された主体と命令の境界内だけだ。その外側にある安全の主張には、一つずつ別の証票が要る。

出典