要約

  • RFC 897は、ホスト名を階層形へ変える作業と、名前からアドレスを得る仕組みを中央表から分散サーバーへ変える作業を別の段階にした。
  • RFC 921は最初の予定を残し、改名は予定どおり、サーバーは遅延、複数の制度・データ・アプリ作業は未完了だと記録した。
  • 一台のホストでもアプリごとに表のみ、表とDNSの併用、DNSのみという異なる状態を持ち得た。

旧方式にも複数の受入れ点があった。RFC 810 はNICが管理する機械変換可能なホスト表を定めたが、各サイトは表を取得し、自分のシステム向けに変換しなければならなかった。RFC 811 のHostnames Serverは個別照会にも全表取得にも応じた。中央の行が正しいこと、転送が完了すること、ローカル版が有効になること、アプリがそれを読むことは同じ証拠ではない。

RFC 881 は導入時の循環を率直に書いた。一部がドット付きの名前を使えば、その名前はメールを通じて未対応の場所へも届く。全員の準備を待てば、現実的な時期には始められない。そこで、ドメイン形式の表を従来表と並行提供し、後に主表へ置き換え、最終的には従来のライブラリ呼出しをresolverで置換する案が採られた。アプリからは、答えがファイル由来かサーバー由来かを隠せる。

RFC 882 と RFC 883 は、名前、型付きデータ、zone、server、referral、resolver、cacheを持つ分散系を示した。ただし仕様の完成は、個々のmailerやTelnetが新しい呼出しへ移った証拠ではなかった。

ドットは先に付き、参照先は後で変わった

1984年2月の RFC 897 は二つの変更を明記した。一つは、平らな文字列だった名前を階層化すること。もう一つは、中央で保守された完全表のローカルコピーから、データの一部ずつを持つ分散サーバーへの動的照会へ移ることだった。

移行は四段階だった。まず古い名前へ .ARPA を付ける。次に少数のdomainを導入する。三番目に表からserverへ参照方式を変える。最後に多数のdomainを許す。この順序では、USC-ISIF.ARPA という名前がHOSTS.TXTに載り得る。ドットはresolver利用の観測値ではなかった。

旧名を一時的なnicknameにする方法も記された。しかし、それが直せるのは別名を受け入れる側の入口だけである。遠隔地のaddress book、過去のFromやCc、外部で管理されるmailing listまでは書き換えられない。名前が一度配布されると、改名の残作業は管理境界の外へ出る。

また、アドレスからprimary nameを得られる性質を分散databaseでも保つ必要があった。これは整合性の要件であって認証ではない。逆引きが成功しても、相手の権限や現在の到達性は証明されない。

同じ名前政策、異なる参照義務

RFC 897の予定では、1984年3月14日にdomain-style nameをprimaryにし、5月2日に旧名を停止する。6月6日に一般のmulti-level domain、7月18日に組織を表す名前、9月5日にARPA研究コミュニティ向け完全host tableの退役、10月3日にDDNの計画が続いた。

しかし二つのコミュニティは同じ技術義務を負わなかった。ARPA研究側は完全移行を目指す。DDN運用側は名前を同じ日程で変えるが、server利用を同時には強制されず、後の計画までNICの中央表を使える。

見た目のnamespaceがそろっても、lookupのauthorityはそろわない。一つの日付で「Internet全体がDNSになった」とは言えない理由がここにある。

未達を消さなかった改訂

RFC 920 は新domainの要件とtop-levelの構成を1984年10月に示した。RFC 897が想定した2月より遅く、移行中に制度設計そのものが修正された。

RFC 921 は旧予定へ実績を書き込んだ。初期のdomain-style host tableと3月のprimary name変更は予定どおり。ARPA domain serverは動いたが4月ではなく9月。top-level domain table、新domain、multi-level domain、組織名のindirection、host table退役、DDN計画は未実施だった。

改訂版は残作業を三相に分けた。machineryはserverとresolver、databaseはデータの設置、user programsはmailerやTelnet、FTPなどの実呼出しである。1984年10月にはmachineryが進み、ARPAデータと他のtop-levelの初期化もあったが、user programの変更はわずかだった。

新しい予定は1985年10月まで延びた。将来の日付が達成を証明するわけではない。史料として強いのは、過去を「実施」「遅延」「未実施」に分け、どの層が残ったかを隠さなかった点である。

最後の切替単位はアプリだった

1987年の RFC 1031 はMILNETに三つの状態が同時に存在するとした。host tableのみ、tableとDNSの併用、DNSのみである。TelnetとFTPだけ先にDNSへ移し、MAILは表を使い続ける場合も、その逆もあった。

同文書では当時の多くのhostがtable-only段階にあるとされた。古いarchitectureや変更不能なsoftwareは移行できない可能性があり、共通表の終了後は二者間契約、特定communityのrepository、local tableのどれかを自ら確保する必要があった。fallbackは無料の共有物から、所有者を要する依存へ変わった。

RFC 1034 は後にHOSTS.TXT配布の拡張性問題をまとめ、旧関数を模倣するresolver interfaceを残した。互換性は一斉改修を避けるが、アプリ表面だけを見てもbackendの移行状態が分からなくなる。

RFC 1401 が収録した1992年のIABとDISAの往復書簡では、MILNET移行は未完了とされ、tableとDNSの不整合が到達失敗へ結び付けられた。これは中立的な普及調査ではなく政策提言である。それでも、別日程とされた支流が長く残ったことを示す一次文書ではある。

出典と限界

根拠はRFC 810、811、881、882、883、897、920、921、1031、1034、1401である。仕様、政策日程、自己監査、後年の文書記録は確認できるが、全世界共通の切替日、全siteの遵守、名前による認証、現在の到達性、現行製品の挙動は証明しない。