要約

  • DNSOPの委任再検証草案第14版では、親が同じ委任点への参照を返し、現在と過去の親側NSに少なくとも一つ共通名があれば継続性が成立する。前後ともDSを観測していた場合は、少なくとも一つの委任署名者も共通でなければならない。
  • NSまたは該当するDSが完全に新しくなった場合、あるいはDSが空から非空、非空から空へ変わった場合、権威の変更として、その点以下のキャッシュは使えなくなる。厳格方式と機会的方式では、失敗とフォールバックの配分が異なる。
  • 集合の重なりはリゾルバー向けの継続判定であって、運用移行の承認記録ではない。意図した重なり、変更権限、三つのTTL、旧系の退役時刻、監視とロールバック責任者を結ぶ「委任移行レシート」が必要だ。これはDaniel Kadeの提案であり、IETF本文ではない。

委任の情報は一枚ではない。親ゾーンは参照用のNS、必要なグルー、DNSSECを使うならDSを置く。子ゾーンは自分の頂点で権威NSを公開し、各サーバーが実際にゾーンを提供する。RFC 1034はゾーンカットの両側を整合させるよう管理者に求めるが、DNSには親子を同時に更新する原子的な手続きがない。

そのため、停止していないのに状態が食い違う。親の委任TTLが固定で長く、子の頂点NSは短いことがある。レジストリへの変更が先に反映される場合も、子側の切替が先に進む場合もある。応答を小さくする設定によって、通常の回答に頂点NSが現れないこともある。アプリケーションはNSを明示的に尋ねないので、リゾルバーが子側の集合を一度も学ばない可能性まである。

2026年9月2日付のDelegation Revalidation by DNS Resolvers第14版は、この揺れを予測可能にしようとする。DatatrackerではDNSOPワーキンググループの有効なInternet-Draftで、Standards Track、想定されるRFC種別はProposed Standard、状態は「WG Chair Go-Ahead待ち」である。失効予定は2027年3月6日。まだRFCではなく、全リゾルバーへの導入指示でもない。

草案は三つの働きを組み合わせる。親の参照をたどった後、子の頂点NSを明示的に問い合わせ、RFC 2181のデータ順位に従って、非権威の親側コピーより権威回答を優先する。NS名に対応するAとAAAAも、可能なら権威データで置き換える。そして一定時間後に親へ戻り、委任が削除、再委任、全面更新されていないかを確認する。

交差が残すもの、残さないもの

再検証するキャッシュは、親から受け取ったNS名とそのTTL、観測した場合はDSのTTLも保持する。親に問い直して同じゾーンカットへの参照が得られ、以前のNS集合と現在の集合に少なくとも一つ同じ名前があれば、委任は「still valid」と扱われる。

ただしDSが前後とも存在したなら、条件はNSだけではない。委任署名者にも一つ以上の重なりが必要になる。DSが全く別の集合になった場合は権威変更である。DSなしからあり、ありからなしへの移行も、単なる連続とは扱われない。

これは過半数判定ではない。旧NSが四つあり、新しい状態が旧名一つと新名三つでも交差は成立する。鍵のロールオーバーでも旧署名者を一つ残し、新しい署名者を追加できる。段階移行を壊さないための、小さく明確な条件である。

逆に、親が参照を返さない、別の委任点へ変わる、NSまたはDSが全面的に新しくなる、DSの有無が反転するなら、階層または権威が変化したと判定する。その時点以下のキャッシュ済みデータは使用禁止になる。直ちに消す実装でも、世代を切り替えて旧データを到達不能にする実装でもよいが、利用結果は削除と同じでなければならない。

この強い結果と引き換えに、継続判定は意図的に狭い。同じNS名が、退去中の事業者の最後の設備なのか、共有Anycastなのか、登録者が削除し忘れたのかは分からない。まして、契約、本人確認、レジストラ承認、侵害の有無をDNS集合だけで証明する仕組みではない。

子の権威を優先し、親の取消しを忘れない

子の頂点NSは子自身が権威を持つため、親の参照NSよりデータ順位が高い。第14版は、参照で見つけたサーバーへ頂点NSを問い合わせる検証クエリを、通常の解決と並行して送るよう勧める。成功すれば、次の問い合わせは子が示すNSを優先できる。

失敗やNODATAなら、親側のNSを上位のまま残してサービスを続ける。機会的方式では、利用者への回答を検証完了まで待たせないのが普通である。

しかし、子側を優先することと、親側の取消しを無視することは違う。親は、その名前を委任し続けるか、別の運用者へ移すか、取り消すかを示す場所である。子NSを問い合わせるたびTTLを更新し、親へ戻らなければ、既に再委任された旧運用者へキャッシュが居残る。草案がGHOSTドメイン対策として親の再確認を組み込む理由である。

アドレス情報にも同じ二重性がある。グルーは子へ到達するために不可欠でも、通常は非権威である。完全なRRsetと検証可能な署名がありDNSSEC Secureなら、そのアドレスを権威データとして保存できる。それ以外は別問い合わせが要る。一方、権威的に取得したアドレスが全滅した場合、低順位のグルーを最後の手段として残す選択も認められる。

このフォールバックは障害を救うが、外から経路を推測しにくくする。NS一覧だけを採取しても、どのアドレスが届き、どの順位のデータが使われ、検証が利用者回答より先か後かは分からない。

厳格方式は信頼を上げ、同時に停止点を増やす

厳格な再検証では、権威的に得た名前の、権威的に得たアドレスから回答が来たと確認するまで、元の問い合わせを待たせられる。偽造や経路上の観測に強くなる一方、子のNSやアドレスが壊れていて低順位データへ戻れなければ、解決そのものが失敗する。

草案が厳格な信用度引上げをルートとルート直下のゾーンに限るよう勧めるのは、そのためだ。より深い子ゾーンには、頂点NSの明示問い合わせに正しく答えない運用も残る。

機会的方式は、まず利用者の回答を進め、検証結果を後続問い合わせに生かす。子サーバーが頂点NS問い合わせを誤処理するなら、そのゾーンではアルゴリズムを断念し、親の参照だけに戻る。可用性は高いが、厳格方式と同じ保護を得たとは言えない。

従って管理画面の一つのチェックボックスでは足りない。どの深さで、どちらの方式を使い、失敗時に何へ戻り、キャッシュをどこまで捨てるのかが運用方針である。

三つのTTLと一つの防御的な下限

再検証の期限は、親NS TTL、DSがある場合の親DS TTL、子頂点NS TTLのうち最短の値で決まる。親の時計は、取消しや再委任の後に旧経路を使い続ける時間を抑える。子の時計は、自分の運用集合を再観測させる周期を短くできる。

ただし、極端に短いTTLで計算作業を強制されないよう、リゾルバーは耐えられる最小値を設けるべきだと草案はいう。共通の秒数は決めていない。つまり、ゾーン側が短いTTLを出しても、世界中のキャッシュが同じ秒に失効する保証にはならない。

検証失敗はRFC 9520に従って負にキャッシュし、失敗先を何度も叩かないようにする。NSだけでなくアドレスも再取得すれば、権威側への追加トラフィックは大きくなり得る。作業上限と失敗キャッシュは、DoS耐性を含む設計要件である。

不一致通知に判決をさせない

親NSと子頂点NSの違いを見つけたリゾルバーは、RFC 9567のReport-Channelを使い、親側と子側の両方へ通知してよい。草案はreferral NS RRset mismatch用のExtended DNS Errorを提案するが、値はまだTBDである。

差異は必ずしも障害ではない。計画移行の途中、親の固定TTL、作業待ち時間でも発生する。通知が示すのは、ある観測者がある時刻に二つの集合を見たという事実だ。どちらが契約上正しいか、変更要求が本人のものか、残した一台が意図的かは裁けない。

報告は照合作業の入口にすべきで、親または子を自動的に非難する材料にしてはならない。回答が成功した場合も、残存経路の承認までは確認できない。

委任移行レシートという別の台帳

運用者AからBへ移るとき、親NSにAの一名を残しながらBを追加し、DSにも一つ旧署名者を残す。この橋はリゾルバーにとって連続であり、移行チームにとっては期限付きでなければならない。

そこでDNSの外側に委任移行レシートを置く。最初に旧状態と目標状態を分け、親NS・グルー、親DS、子頂点NS、各サーバーのアドレスを記録する。継続のため意図して共有するNS名と署名者を名指しし、その役割と退役条件を書く。

次に、レジストリまたはレジストラの変更参照、旧・新DNS運用者、最終削除を承認する者、戻す権限を持つ者を結ぶ。レシート自体は認証情報ではなく、資格情報を格納もしない。公開観測と内部の正当な変更手続きを結ぶ索引である。

時間欄には親NS、親DS、子NSのTTLを別々に置き、最短期限と想定するリゾルバー下限を示す。設定受付終了、親からの削除、旧サーバーの権威応答停止、観測上の流量終了は別の出来事として扱う。

監視は厳格経路と機会的経路を分ける。機会的に名前が引けても、厳格リゾルバーで新しい子データが壊れていないとは限らない。全面更新を選ぶなら、子孫キャッシュの無効化と問い合わせ増加を計画済みの効果として扱う。

終了時には、親子が目標集合へ収束し、予定した共通項が消え、旧運用者が意図しない権威応答を止め、ロールバック窓が閉じた証拠を残す。リゾルバーはこのレシートを読まない。プロトコルの集合判定と、人間の移行責任を混同しないための記録である。

情報源

  1. DNSリゾルバーによる委任再検証・第14版
  2. 委任再検証のDatatracker記録
  3. 委任再検証の文書履歴
  4. DNSOPの有効文書
  5. DNSOP憲章
  6. RFC 1034：Domain Names―概念と機構
  7. RFC 2181：DNS仕様の明確化
  8. RFC 9520：DNS解決失敗のネガティブキャッシュ
  9. RFC 9567：DNSエラー報告
  10. DNSの拡張可能な委任・第11版