要約

  • RFC 9975では、親ゾーンに現在載る子のNS集合から確認範囲を作り、各NSについて得た全アドレスへ直接問い合わせる。
  • NODATAは比較すべき応答であり、無応答は同意ではない。後者には再試行、バックオフ、必要なら別のネットワーク観測点が要る。
  • 関連状態が一致しなければ、予定していた親レコードの作成・削除・変更を一切行わない。一致は共同要求の証拠であって、権限、身元、実装品質、DNSSEC継続性の証明ではない。

ある権威サーバーが新しいCDS鍵を示し、別のサーバーが正しく署名されたNODATAを返す。どちらも故障していないかもしれない。複製の途中か、複数事業者の設定が分かれているだけかもしれない。それでも親が最初の回答だけでDSを変えれば、到着順が意思決定者になる。

通常のリゾルバーは利用可能な回答を探す。親側エージェントは異なる仕事をする。子で観測した状態を、名前空間の一段上にあるDS、NS、glueの永続的変更へ変換するためだ。使える回答と、変更に足る証拠を同じ基準で扱えない。

2026年5月に公開されたRFC 9975は、この差を「もっともらしい整合性」という要件にした。単独著者はPeter Thomassenである。全世界の全パケットが同じだと証明するのではなく、親が自ら公開している権威サービスを十分に調べ、部分的な見え方から変更を推論しないための手順である。

誰に尋ねるかは現在の親委任が決める

確認対象は、更新信号に添えられた都合のよいリストではない。エージェントは親ゾーン内の子委任からNS名を取り、検証を行うリゾルバーで各名の全IPアドレスを取得する。利用できるglueも含め、各アドレスへ対象レコードを直接問い合わせる。

要求自身が証人を選べれば、古い状態をまだ提供する事業者を除外できてしまう。現在の親委任は所有権の証明ではないが、親がインターネットに向けてすでに告知している運用上の権威集合である。

NS名を再帰リゾルバーに一度聞くだけでも不十分だ。一つの名は複数アドレスを持ち、別インスタンスや別経路に到達しうる。anycastでは同じアドレスも観測地点によって異なる設備へ届く。初回地点から無応答なら、RFCは別地点での試行を認める。

この観測は有限である。経路障害が稼働中のサーバーを隠すこともある。だからこそ、どの委任、アドレス、地点、時刻を使ったかを記録し、有限性を見えなくしないことが重要になる。

NODATAは無言ではない

NODATAでは、サーバーが権威応答を返したうえで、求めた型のレコードがないことを示す。RFC 9975はこれを明示的に受信応答へ含める。CDS/CDNSKEYの一方の観測に鍵があり、他方がNODATAなら、子サービスはまだ共通の要求を示していない。

NODATAを捨てれば、変更を求めるサーバーだけが投票できる。現状維持を示す有効な観測が、ネットワーク上に存在しなかったことにされる。

一方、無応答は観測不能である。パケット損失、経路、フィルター、サーバー障害のどれでも起こる。恒久的到達不能として除外する前に再試行しなければならない。文書は例として5、10、20、40分という指数バックオフを示すが、正確な日程はローカル方針に委ねる。別地点からの試行も、問題がサーバーか一経路かを切り分ける。

無限待機は求められない。求められるのは、いつ、誰が、どの根拠で観測対象を除外したかを説明できることだ。沈黙を賛成票へ変えてはならない。

不一致なら親の状態を原子的に保つ

関連応答が食い違った場合、過半数、最大SOAシリアル、最速応答のいずれも決着方法にならない。操作を中止し、作成予定のレコードを作らず、削除予定のものを消さず、既存集合を変更しない。

現状維持は旧状態を真理と認定することではない。親がすでに公開しており、影響範囲が既知の基準線である。相反する二状態の片方へ移れば、名前解決や検証を壊す可能性がある。子側は複製を終え、複数事業者の分裂を直すか、認証された帯域外手段を選べる。

再実行では新しい照会ラウンドを作る。以前の都合のよい応答だけを寄せ集めない。現状維持を確定する応答が得られた場合、残りの判断用照会を早期終了できる場合もある。後続は「やはり変更なし」か「不一致」のどちらかで、いずれも書き込みを生まないからだ。報告用照会は診断のため継続できる。

この原子性は、矛盾したCSYNCのうち安全そうな部分だけを先に適用することも禁じる。判断対象は一つの提案操作であり、便利な断片ではない。

CDSとCDNSKEYでは鍵の参照を揃える

整合性は全バイトの同一性を要求しない。CDS/CDNSKEYでは、どこかの応答で参照された対象鍵が、ほかの関連応答でも参照されている必要がある。一箇所に存在し、別箇所で欠ければ不一致である。

DS集合を完全削除する要求も同様だ。削除要求が更新要求やNODATAと共存する状態を、段階的削除だと勝手に解釈できない。比較対象となるダイジェスト型には標準上の境界がある。親は許容範囲で公開方針を持てるが、子が共通に参照した鍵集合を後から作り替えることはできない。

Steve ShengとThomassenが共著し、2026年7月にBest Current Practiceとして公開されたRFC 10026は、別の検査を追加する。適用後のDS集合が有効なDNSSEC検証経路を維持するかを確認する。全サーバーが一致しても、技術的に危険な要求はありうる。要求の一致と結果の継続検証は別々の証拠である。

CSYNCはシリアル差を許しても判断差を許さない

CSYNCでは通常複製による違いがあるため、項目ごとの比較が要る。immediateフラグと型ビットマップは受信応答間で一致しなければならない。SOAシリアルは異なりうるので、各CSYNCシリアルを同じサーバーから得たSOAと照合する。その結果の「更新可能か」という判断が一致する必要がある。

CSYNCがNSや関連アドレスなどの同期対象を指定する場合、関連サーバーのRDATA集合は、全て空の場合も含め等しくなければならない。ネームサーバーとglueの処理順など、CSYNC固有の他の規則も残る。

したがって「全員に尋ねる」は実装仕様の前半にすぎない。レコード族ごとに、許される差、移行中の差、変更を不能にする矛盾を定義しなければならない。

通知は検査を始めるベルである

Thomassenも著者に含まれるRFC 9859は、CDS関連状態が変わったことを子から通知できる。定期走査を待たず、親側の処理開始を早められる。

通知は証拠鎖を省かない。受信者はタイマーで開始した場合と同じDNS照会と検証を行う。通知受理、全アドレス観測、サーバー間整合性、予測DSの検証、親公開、キャッシュ満了後の可視性は別々の受領記録である。

これらを一つの「自動化済み」表示へ畳むと、最後のメッセージが前後すべての工程を証明したように見える。通知が改善するのは発見時間であり、要求の権限ではない。

一致は身元や権限の証明ではない

同じ値が全サーバーにあることは、ドメイン所有者、指示権者、アカウント侵害の有無を示さない。既存DNSSECは保守の一部を技術的に認証できる。親DSがまだない初回導入にはRFC 9615のような方法が必要だ。レジストリ、レジストラ、登録者の統制はRDATA比較の外に残る。

親での公開完了も最終結果ではない。再帰リゾルバーはTTLが切れるまで古いDSや委任を保持する。子がロールオーバーの次段階へ早く進めば、正しい書き込みの後でも障害が起こる。RFC 10026が時刻、検証、ロールバック、報告を独立作業とする理由である。

子側が共通状態を作れない場合、RFC 9975は認証された帯域外経路を残す。これは整合性規則の抜け道ではなく、異なる権限経路だ。事業者間の統治問題を、最初に応答した機械へ決めさせてはならない。

著者名が示すのは貢献である

RFC EditorはRFC 9975の単独著者としてPeter Thomassenを記載する。公開IETFプロフィールは、調査時点でdeSECの創業者兼CTO、SSEの業務執行者、Domain Connect議長、DNSOP書記と紹介する。RFC 9615、9859、10026にも共著者として名を連ねる。

これは標準形成への貢献を裏付けるが、全親側エージェント、レジストリ、レジストラを彼が制御するという意味ではない。特定実装の認証や障害原因も示さない。RFCは最低挙動を述べ、実運用ログだけが全アドレスを照会し、衝突時に本当に書き込まなかったことを示す。

この境界は機構と対称だ。著者名は貢献の証拠であって普遍的な制御権ではない。委任中のサーバー名は証拠源であって、単独で親を書き換える権限ではない。

成果物は再現可能な判断記録

実装は、範囲を定めた親委任、全アドレスとglueの由来、照会時刻と観測地点、回答またはNODATA、検証、比較、再試行、バックオフ、恒久的到達不能としての除外を残すべきだ。

さらに親の予測差分、継続検証、適用または中止の判断、公開後の実状態を記録する。秘密の認証情報は不要だが、判断を再現する証拠は必要である。

共有すべき最小仕様は、矛盾する部分集合から委任変更を推論しないことだ。再試行時間、観測地点、報告経路、許容範囲内のダイジェスト方針は地域や組織ごとに決められる。文書ではなく稼働コードが、その境界の実在を証明する。

出典