要約

  • RFC 2010 は、複数の物理回線を持つ場合でも一つのネットワークインターフェースを広告することを含め、ルートサーバー運用を個別に検査できる条件へ分解した。
  • ただし、サイトや管理者の選定、不遵守時の手続きは対象外であり、条件への適合は任命の正当性、ゾーン内容の正しさ、全世界からの到達性を証明しない。

外から見える入口は一つ、内部の支えは複数。RFC 2010 が求めた「広告されるネットワークインターフェースは一つ」という条件は、単純な構成美の話ではない。複数の物理インターフェースを冗長性に使いながら、利用者が観測するサービス面を一定にする試みだった。ここには、運用の内部構造と外部に提示する証拠を分ける発想がある。

当時のルートサーバー群は、高い能力を持つ志願者によって支えられ、Network Information Center を介して緩やかに調整されていた。RFC 2010 はその共同体を置き換えず、信頼の中身を分解した。文書上の zone master である IANA がソフトウェアを選び、必要なら 96 時間以内の更新を求める。全応答に UDP チェックサムを付け、少なくとも二つの認証された NTP サーバーから時刻を得る。専用ホストを使い、無関係なサービスを載せず、遠隔管理を暗号化する。

機械、施設、人を別々に確かめる

物理アクセスの管理、電源とネットワーク接続の冗長化、セキュリティ関連ログも独立した条件だった。平均毎秒1,200問い合わせを5ミリ秒未満で処理し、毎秒2,000を望ましいとする数値は、1996年の歴史的基準である。現在の性能目標として転用はできないが、「十分な余裕」を計測可能にしようとした意図は読める。

AXFR は許可先に限定され、FTP による完全ゾーン取得、NOTIFY、IXFR も扱われた。再帰問い合わせは、足りない glue に必要な狭い例外を除いて無効化する。通常のメールには24時間以内に返答し、予定外または24時間未満の予告による停止には電話連絡を求めた。サービスを動かす機械だけでなく、応答する人と連絡経路も運用面の一部になった。

それでも、一つのインターフェースが到達性全体を証明するわけではない。チェックサムは内容の権威性を保証せず、ログは復旧を保証せず、二系統の電源も共通障害がないことを自動では示さない。文書、設定、観測結果を同じ現実として扱えば、チェックリストは証拠ではなく装飾になる。

選定と処分は文書の外側に残った

RFC 2010 は、サイトと管理者をどう選ぶか、条件違反をどう処理するかを明示的に対象外とした。したがって、運用義務の可視化は制度的正当性の付与ではない。誰が任命し、誰が裁定し、どのような救済や制裁があるかは別の権限層に残る。

RFC Editor の記録では、本書は Informational で現在は Legacy、IETF が推奨として承認した文書ではない。RFC 2870 がこれを廃止し、後に RFC 7720 がルート名前サービスの要求を記録した。この継承は仕様史であって、全面実装の証明ではない。

Lu Heng の running code、最小初期仕様、現実の層という三つの視点を使うと、成果は狭く、しかし重要に見える。RFC 2010 は中央権力を完成させたのではなく、個人の能力に預けていた運用を、別々に検証し、別々に失敗できる証拠へ変換した。

出典