要約

  • draft-ietf-dnsop-ns-revalidation-14 は子ゾーン頂点の権威NS集合を優先できるようにする一方、親への定期的な照会を要求する。そうしなければ、委任を失った旧運用者が自分の応答だけで旧権限を更新し続けられる。
  • 必要なのは、親referralの形、NSとDSの重なり、三つのTTLの最短値、変更点以下のキャッシュ無効化、新しい解決結果を結ぶ受領記録である。単に「応答した」だけでは、そのどれも代替できない。

返事は届くのに、権限は届いていない

委任変更の日、親ゾーンは新しいネームサーバーを掲載した。新事業者もゾーンを用意した。しかし、ある再帰リゾルバーは旧子ゾーンのNS集合を保持し、旧サーバーへ問い合わせ続けた。旧サーバーにはまだゾーンの複製があり、整った応答を返し、AAビットも立てられた。

利用者から見ればDNSは動いている。親側の管理画面では移行済みである。旧サーバーの立場では、自分が保有するデータへの権威応答である。三つの観測は同時に成立するが、現在の委任権限という一つの事実にはまとまらない。

2026年9月2日付の draft-ietf-dnsop-ns-revalidation-14 は、このずれを解消するための任意アルゴリズムを示す。DNSOP作業部会の現行Internet-Draftで、想定状態はProposed Standard、Datatrackerでは作業部会議長の許可待ち、IESGでは I-D Exists である。RFCでもなければ、特定リゾルバーへの実装証明でもない。

それでも設計上の問いは明確だ。子がまだ話せるとして、親が今もその子に話す資格を与えていると、リゾルバーは何をもって判断するのか。

ゾーンカットの両側は同期していない

従来のDNS委任には、親側の委任NS RRsetと、子ゾーン頂点の権威NS RRsetがある。RFC 1034は両管理者に整合維持を求めたが、プロトコルは二つを一つのトランザクションで更新しない。

RFC 2181のデータ順位では、子の頂点NSは権威データであり、親の委任NSは非権威のreferralデータである。通常の名前解決で子側を優先することには合理性がある。子の運用者は自分のサーバー構成を知り、親が長い固定TTLしか認めない場合でも、短いTTLで切替速度を調整できる。

そこで第14版は、新しいゾーンカットをたどる際に子の頂点NSを明示的に問い合わせ、キャッシュ内で優先するよう勧める。安全な委任ならDNSKEY照会と並行できる。glueやAdditional Sectionから得た低順位のA・AAAAも、可能なら再照会し、権威回答へ置き換える。

ただし、これは情報の信頼度を上げる処理であって、委任を延長する処理ではない。子自身のNS回答が親の委任を証明できるなら、旧事業者はTTLを更新するだけで、親が撤回した権限を永久に維持できる。

子から良い情報を得ることと、親から現在の権限を確認すること。この二つを分けるのが再検証の出発点である。

一つの委任に三つの期限

再検証は、親の委任NS TTL、存在する場合の親DS TTL、子頂点NS TTLのうち、最も短い期間を超えて遅らせてはならない。

親NSの期限は、現在の委任経路を信頼できる時間を区切る。DSの期限は、委任された署名者との関係を区切る。子NSの期限は、子が示すサーバー集合の鮮度を区切る。最短値を使うことで、どれか一つの長いTTLが、別の主体の権限を勝手に延ばすことを防ぐ。

ドラフトは、極端に短いTTLで再検証負荷を押しつける計算量DoSに備え、現実的な最小TTL床を置くことも勧める。その床はローカルな防御策であり、追加時間中に委任が不変だった証明ではない。監査記録には、三つの元TTLと適用した床、取得時刻、実際の再検証期限が必要になる。

「キャッシュ残り時間」という一つの数値だけでは、どの権限境界が先に到来したかを説明できない。

継続性は集合の重なりで判定する

再検証点で親へ戻ったリゾルバーは、単に何らかの回答を得ればよいのではない。親が同じ点へのreferralを返し続け、新しい親NS集合と以前の集合に少なくとも一つのサーバー名が共通し、前後ともDSが存在する場合には少なくとも一つの委任署名者が共通する必要がある。

referralでなくなった、別のゾーンカットを指した、NS集合が全面的に新しくなった、DS集合が全面的に新しくなった場合、階層または権限が変化したと扱う。DSが空から非空へ、あるいは非空から空へ移る場合も同じである。

重なり条件は段階的移行を可能にする。一台のサーバーや一つの署名者を残しながら他を更新できる。しかし、共通要素は全構成の同一性を証明しない。アドレス、鍵、ゾーン内容、サービス結果まで同じだとは言えない。

これはリゾルバーが旧キャッシュを保持してよいかという判断である。ドメインの法的所有やレジストリ契約を裁定する仕組みではない。

上位の根拠が変われば、下位のキャッシュも使えない

階層の形または権限が変わったと分かった場合、再検証点以下のキャッシュデータを使ってはならない。即時削除、世代切替、遅延回収のいずれでもよいが、外から見た動作は削除済みと同じでなければならない。

対象はNSだけではない。旧委任の下には、ホストアドレス、メール経路、サービス発見、否定応答、さらに深い委任が残る。親ポインターだけを差し替えて子孫を利用し続ければ、現在の権限鎖を失った結論が生き残る。

そのため検証はルートから下向きに行う方が合理的である。上位の変化は下位の検証を不要にする。RFC 8020は、あるNXDOMAINが下位名にも意味を持つことを示す。再検証では逆方向の依存が見える。上位の支えが変われば、下位データのバイトが残っていても、旧来の使用根拠はなくなる。

strictは強いが、失敗も強い

strictモードでは、応答元サーバーの名前とアドレスが権威的に取得されたと確認するまで、発端となった問い合わせへの回答を待たせられる。署名済みの基盤データを検証できれば、偽造や経路上の盗聴に対して強い。

一方、低順位データへのfallbackがない。子のNS集合が壊れている、または権威サーバーが頂点NSの明示照会を誤処理するだけで、子ゾーンへの問い合わせがhard failureになる。第14版がstrictな信頼度昇格をルートと直下のゾーンに限定するよう勧める理由である。

opportunisticモードは、検証前に利用者へ回答し、必要なら親のreferral情報へ戻れる。子がNS照会を正しく処理しない場合、そのゾーンではアルゴリズムを断念する。可用性は高いが、strictと同じ保護ではない。

したがって「再検証オン」という一ビットの監視では足りない。回答が証明を待ったのか、先に出たのか、fallbackしたのか、どのキャッシュ世代がいつ変わったのかを区別する必要がある。

DNSSECが覆わない基盤データ

DNSSECは重要なレコードを認証するが、referralのNS、glue、Additional SectionのA・AAAAは一般に署名されない。攻撃者が未署名のアドレスを書き換えると、リゾルバーは攻撃者のサーバーを権威と誤認し、その下の未署名referralまで操作され得る。

RFC 5452はトランザクション照合とエントロピーを強化し、偽造回答の受理確率を下げる。委任再検証が問うのは別の層である。トランザクション後も、その基盤の信頼度と親の支持が続いているかを確かめる。

有効なDNSSEC署名も範囲限定の証拠である。最短TTLまでに親へ戻ったこと、結果を適用したこと、全子孫を無効化したこと、アプリケーションが正しいサービスへ到達したことまでは証明しない。

不一致を説明しても、移行は完了しない

第14版は、referral NS RRset mismatchのためのExtended DNS ErrorコードをIANAへ求める。RFC 8914の診断は、リゾルバーが経路を信用しなかった理由を利用者や運用者へ伝えられる。

しかしEDEは親を更新せず、子を修復せず、新サーバーの内容を確認せず、他のキャッシュを同期しない。証拠として使うなら、具体的な親応答、比較した集合、リゾルバー版、動作モード、TTL、無効化処理、その後の解決結果と結びつける必要がある。

RFC 9471が扱うglueも同様である。到達のために必要なアドレスは、現在の委任権限や最終サービスの成功を単独では証明しない。

実装欄は導入率ではない

ドラフトの実装状況欄は、Unboundが harden-referral-path でopportunistic再検証を持ち、既定では無効であること、第7節の処理が1.4.17からあることを記す。Knot Resolverについては1.5.1からroot priming応答を再検証するとする。strictモードは、著者のprototypeやtool以外では実装が知られていない。

これはrunning codeの系譜を示すが、特定現場の設定、現在のディストリビューション既定値、導入率、成功率、相互運用性を示さない。能力はリリース情報から読める。運用は、実際のバイナリ、設定、タイマー、問い合わせ、キャッシュ変化を観測して初めて言える。

権威と応答を混ぜない受領記録

残すべきものは、リゾルバーのbuildと有効設定、strict/opportunisticの別、最初の親referralとNS・DS・glue、子頂点NS、再取得したアドレス、三TTLとローカル床、ルートからの支持鎖、新しい親応答、NS/DS重なり計算、DS空非空の変化、無効化したキャッシュ世代と範囲、fallback・hard failure・EDE、新たに選んだサーバー、そして独立したサービス観測である。

分散DNSに完全な同時性はない。だからこそ、旧子がまだ応答できるという事実を消すのではなく、その応答が現在の委任権限を表さなくなった理由を示せなければならない。

出典