要約

  • RFC 849 は、NIC のマスターファイルが更新済みでも、各サイトで実際に使われるコピーは古いままになり得ると指摘した。
  • 推奨案は、速さのための一度だけのプッシュと、取りこぼしを直す起動時・定期ポーリングを、安価な版確認で結んだ。

停止中のホストには通知音が鳴らない。翌朝に電源が入り、名前解決が動き出せば、外からは正常に見えることもある。ただし、参照しているのは更新前の対応表だ。

ここで誤っているのは、必ずしも中央の記録ではない。発行された状態と、利用中の状態が一致していないのである。

Mark Crispin が 1983 年 5 月の RFC 849 で扱ったのは、この間隙だった。題名は Suggestions for Improved Host Table Distribution。冒頭には、提示する解決策はまだ標準ではなく、意見を集めて将来の合意を探るものだと明記されている。したがって、この文書から導けるのは配備実績ではない。導けるのは、当時すでに更新の失敗を一枚の表の問題として扱えなくなっていた、という事実である。

配布以前に、変換があった

RFC 608 が描いた初期の仕組みでは、NIC が一つの原本を保守し、そこから ASCII のホスト名ファイルを定期的に生成する。頻度は毎週、または必要に応じて、とされた。生成物 <NETINFO>HOSTS.TXT は FTP で取得できた。

これは原本の所在を一つにした。しかし、各ホストの利用状態を一つにはしなかった。

RFC 810 は 1982 年、Internet 向けの新しい表形式を定めた。ネットワーク、ゲートウェイ、ホスト、OS、プロトコル情報などを機械可読にし、SRI-NIC から匿名 FTP で取得する方法と Host Name Server を示した。同時に、利用者が自分の目的に合う形式へ変換する責任を負う、と書いた。

この責任は重要である。NIC 上のファイル、転送されたファイル、ローカル形式へ変換されたデータ、そして名前解決器が現在参照している状態は連続していても同一ではない。

RFC 811 の Hostnames Server は TCP の 101 番ポートで HNAME、HADDR、ALL を受け付けた。ALL なら表全体を BEGIN と END の間に返す。照会手段は整ったが、すでに手元にある版が現在の版かを軽く確かめる手段は別問題のままだった。

「変わったか」を尋ねるために全文はいらない

RFC 849 で最も小さい提案は、現在のホスト表の版を NIC が答えるプロトコルである。Tenex や TOPS-20 なら、ファイルの generation number が使いやすい。Crispin は、NIC と同じ世代番号を付けた SYSTEM:HOSTS.TXT をローカルに置き、ときどき番号の変化を確認していた。この比較を自動化したかった。

世代番号は中身の正しさを保証しない。ローカル変換の成功も、名前解決器への反映も保証しない。答えるのは一つだけだ。同じ版か、違う版か。

だが、その一つの問いが転送量と発見可能性を変える。番号が同じなら全表を再取得する必要はない。番号が違えば、古いコピーを「正常に動いているから正しい」と誤認せずに済む。版の証拠が、転送という重い操作の前に置かれた。

プッシュの速さは、相手が起きている間だけ

第一案は NIC 側から更新を送り込む方式だった。各サイトに登録ポートを待ち受けるサーバープロセスを置き、SRI-NIC など特定の “trusted” サイトから来た更新を受ける。対象ホストが稼働中なら、ほぼ即時の更新が可能になる。

問題は停止中の相手である。純粋なプッシュで全員への到達を保証しようとすれば、NIC は応答しなかったサイトを記憶し、後で再試行しなければならない。名前の原簿に加えて、受信登録、各試行の結果、停止していた相手、残った再送義務を持つことになる。受信者が増えるほど、中央の状態と責任も増える。

RFC 849 は、更新された名前レジストリが完全なまま届いたことを確かめるチェックサムも提案した。ただし、そこで主張されたのは到着の完全性である。送信者を暗号学的に認証する仕様ではなく、悪意ある置換への防御でもない。完全に届いた表の記載が正しいか、変換後に利用されたかは別の証拠を要する。

メールは配送後の状態を見えにくくする

第三案は、更新表を受信者リストへメールで送り、各サイトが独自の導入手順を決める方法だった。NIC にとっては実装しやすい。しかし RFC 849 は、肥大するファイルを多数へ一括配送する手段としてメールは不向きだと評した。

メールが受理されても、システムの表が切り替わったとは限らない。キュー、メールボックス、添付や本文からの抽出、形式変換、反映という段階が残る。配送の成功を導入の成功に読み替えると、古い状態は成功記録の裏に隠れる。

一度送り、戻ってきた側が確かめる

Crispin が最良とした第四案は、第一案と版確認の組み合わせだった。NIC は更新受信を登録したホストへ一度だけ送る。再試行を無期限には抱えない。各サイトはシステム起動手順の一部として NIC をポーリングし、新版があれば取得する。さらに、例えば一日一回の定期確認を予備経路にできる。

この設計では、同じ仕事を二経路で競わせていない。プッシュは速度を担当する。起動時ポーリングは、停止中に逃した変化を、自分が再び動き始めた時点で回収する。定期ポーリングは、通知も再起動もない長時間稼働ホストを補う。版確認があるため、回復の試みは毎回の全表転送にならない。

中央側は一台ごとの停止履歴を永久に管理せず、ローカル側は自分の導入版を最も近い場所で観測する。失敗をなくしたのではなく、失敗を見つけて次の行動へ移す場所を定めたのである。

もちろん、収束は瞬時ではない。プッシュを逃したホストが起動した時に NIC へ到達できないかもしれない。転送が切れ、チェックサムが合わず、変換が止まり、新版がアクティブにならないこともある。RFC 849 の強みは、これらをすべて「表は更新済み」という一つの旗で覆わなかった点にある。

分散化しても、鮮度は時間を持つ

1983 年 11 月の RFC 881 は、当時ほぼすべての Internet ホストが NIC のマスター HOSTS.TXT に基づく何らかの表を使っていると記した。そのうえで、ドメイン形式の名前と既存表を併存させながら移行する計画を示した。

RFC 882 は、世界表の大きさ、とりわけ更新頻度が管理限界に近づいており、分散データベースが必要だと診断した。RFC 883 では、名前空間を複数のネームサーバーに分け、権威を持つゾーンデータとキャッシュを区別した。ゾーンのコピーは定期的にマスターから更新し、キャッシュは時間切れで捨てる。マスターの変更は全コピーを即時に変えるのではなく、徐々に浸透すると明記された。

これは RFC 849 が DNS として実装されたことを意味しない。RFC 849 自身が非標準の提案であり、後続文書はもっと大きな権威分割と照会方式を設計している。共通するのは、コピーを持つ以上、鮮度には版、時刻、更新手順、失敗時の回復が要るという認識である。

現在とは、最後に反映を終えた状態である

権威ある記録は、受理された最新の対応関係を示せる。しかし、停止中のホストをその記述だけで更新することはできない。プッシュは変換を行わず、チェックサムは利用開始を行わず、版番号はアプリケーションの参照先を変えない。

RFC 849 が残したのは、配布方式の勝敗ではなく、更新を検証可能な鎖として読む方法である。原本の版、通知の試行、受信したバイト、完全性の確認、ローカル変換、アクティブ化、そして逃した時の回復。それぞれに別の証拠がある。

中央の主表が今日になった瞬間と、ネットワーク全体が今日を使い始める瞬間は同じではない。発行は原本側の出来事であり、鮮度は利用側で確認される状態なのである。

出典