要約

  • RFC 8806は、再帰リゾルバーと同じホストに完全なDNSルートゾーンを持つ権威サービスを置く方式を記述する。そのサービスが答えられるのは同じホストのリゾルバーだけで、DNSSEC情報を含むデータは公開ルートと同一でなければならない。
  • ローカルコピーにはSOAで決まる終点がある。古いルートデータの提供は許されず、期限前に非ローカルのルートへ切り替える必要がある。これは撤回可能な実行経路であって、ルート権威の移転ではない。

障害訓練で外向きの回線を落としても、再帰リゾルバーがルートの問い合わせに答え続ける。パケットはホストの外へ出ない。これはRFC 8806が想定する利点の一つだ。

ところが、この構成を「自前のルート」と呼ぶと設計の本質を外す。自前なのは、公開データを使うための短い経路である。ゾーンの内容、署名の根拠、有効期間は自前ではない。

RFC 8806ではWarren KumariとPaul E. Hoffmanが著者として記載され、Hoffmanは2番目に位置する。2020年6月に公開されたInformational RFCで、IETFの合意を反映し、RFC 7706を置き換えた。共同執筆の記録は標準化への参加を示すが、単独発明や全リゾルバーへの導入勧告を示すものではない。

同じネットワークではなく、同じホスト

完全なルートゾーンは、再帰リゾルバーと同一ホストで動く権威サービスにロードされる。再帰プロセスは通常なら公開ルートへ送る問い合わせを、そのサービスに向ける。

対象範囲は厳しい。同じLAN、同じラック、同じ運用組織では足りない。同じホスト上のリゾルバーだけが利用でき、別ホストのリゾルバーへは応答してはならない。

RFC 7706はloopbackアドレスを指定していた。RFC 8806は実装の自由度を広げ、必要なとき非ローカルルートへ戻れる形を扱うが、一台のホストという境界は残した。

境界を越えて共有すると、壊れたコピーの影響範囲が広がる。ゾーン取得の失敗、権威サーバーの不具合、設定ミスが、導入を選んでいないリゾルバーまで巻き込むからだ。

同時に、名称の誤解も防ぐ。このサービスは公開ルートサーバーの新しいインスタンスではない。国別ルートでも地域別ルートでもなく、TLDの存在を決める場所でもない。ローカルであることは、主権ではなく障害範囲の説明である。

同一性がコピーの利用資格になる

ローカルゾーンは公開DNSルートと同一でなければならない。RFC 8806はglueの変更を避けるよう求め、DNSSECレコードを含む完全なゾーンを必要とする。

よく使われるTLDだけを置く方法では、存在しないのか、コピーされなかったのかを区別できない。再帰リゾルバーは次に来る名前を予想できず、部分的なファイルを世界全体の答えとして扱えない。

さらに、ローカルサービスの署名付き応答も検証対象である。近いプロセスだから信じるのではない。リモートルートの応答と同じようにDNSSECを検証し、現在の公開ルートKSKのトラストアンカーを持つ必要がある。

HoffmanはRFC 7958の4人の著者の一人でもある。この文書はIANAによるルートトラストアンカーの公開を扱う。署名チェーンをどこから信頼するかは、ファイルを保存した主体の都合では決まらない。

この構造によって、通信経路の依存を減らしながら参照元を共通に保てる。コピーが役立つのは、自分で自分を正当化できないからである。

SOAはローカル運用の退場時刻を持つ

ルートゾーンは更新される。ローカルコピーはSOAのタイマーに従って再取得しなければならない。完全なゾーンはAXFRや公開ファイルなど、利用可能な手段で得る。

公開ルートの運用者は変更通知を受け、ローカルコピーより早く新しい状態へ進む場合がある。短い遅れはあり得るが、SOAの期限を越える理由にはならない。

expiryの前に、再帰リゾルバーは非ローカルのルートへ直ちに切り替える。期限切れのルートデータをそのまま提供してはならない。フォールバックは予備機能ではなく、ローカルコピーを使うための必須条件だ。

更新が止まると、新しいTLD委任や変更されたレコードが見えなくなる可能性がある。それでも権威プロセスは応答し、一般的な死活監視は成功する。動くサービスと新しいゾーンは別の事実である。

必要な観測は、公開側とローカル側のSOA serial、最後の完全取得、DNSSECレコードの完全性、検証結果、トラストアンカー、期限までの余裕、そして実際に選ばれた問い合わせ先を一つの時間線に並べる。

Primingはルートの居場所を確かめる

Hoffmanが共同執筆したRFC 8109は、リゾルバーのprimingを記述する。root hintsから出発し、リモートのルートへ現在のNS RRsetとアドレスを問い合わせ、公開サービスの位置情報を更新する。

これは完全なゾーンコピーをローカル権威サービスへ入れる作業ではない。root hintsは出発点、primingは到達先の確認、ゾーン転送はデータ取得、ローカルサービスは応答実行である。

一つを確認しても他を証明しない。primingが成功してもローカルコピーの期限は分からない。ローカルコピーが検証できても、期限時に使うリモート経路が通るとは限らない。

運用台帳がすべてを「ルート設定済み」でまとめると、どの証拠が切れたのか分からなくなる。違う仕組みには違うレシートが必要だ。

プライバシーの利益はローカルな責任を増やす

問い合わせと応答をホスト内に留めれば、経路上の観測者へ見えるルートトラフィックを減らせる。外部ルートへの経路が切れたり攻撃を受けたりした場合も、コピーの有効期間内なら解決を続けられる。

通常時の速度向上は大きいとは限らない。正当なTLDデータはTTLが長く、再帰リゾルバーはキャッシュしているため、利用者の問い合わせごとにルートへ出るわけではない。

一方、再帰プロセスとローカル権威サービスは一台のホストで運命を共有する。資源不足、更新失敗、設定ミスが同時に両方へ影響し得る。外部の経路リスクを、内部の運用責任へ置き換える構成である。

ゾーン取得手段にも永久保証はない。RFCは転送やファイルのサービスを示すが、将来も存在するとは保証しない。2026年8月30日時点でIANAはルートゾーンファイル、root hints、トラストアンカー関連情報を公開していた。この観測は将来の可用性を約束しない。

Running-Code Primacyが問うのは現場の結果だ。完全なゾーンを取得したか、署名を検証したか、serialが進んだか、外部ホストを拒否したか、期限前に離脱したか。RFCの文言だけでは一件も実行されない。

Hoffmanの記録と運用責任を分ける

2026年8月30日に確認したPaul E. HoffmanのIETFプロフィールは、83本のRFC、3つのワーキンググループchair、RFC Production Advisory Teamの役割を掲載していた。RFC 7706、7958、8109、8806も含まれる。

役割と本数は変わり得る。文書に名前があることは共同作業への参加を示すが、各実装の正しさや導入率、DNSルートへの個人的な権限を示さない。

人物の帰属にも、コピーと同じ制限が必要である。著者名は貢献のレシートであり、すべての運用を支配する鍵ではない。ローカルゾーンはデータ保持のレシートであり、ルートを変更する鍵ではない。

RFC 8806の設計は、近さを権威へ変えない。答える相手を一台に閉じ、データを一致させ、署名を検証し、時間が来たら必ず外へ戻る。その撤回可能性がローカル実行を安全にする。

出典