要約

  • RFC 920はトップレベルの名前だけを列挙したのではない。各カテゴリーに管理者と登録窓口を割り当て、認可の条件も示した。
  • ARPAは明示的に一時的な名前だった。GOV、EDU、COM、MIL、ORGは組織カテゴリーで、国コードと複数組織のドメインは、まだ実例がない候補だった。
  • トップレベルでは500ホスト超が一般的な目安だった一方、セカンドレベルの50ホスト超は「非常に柔軟」なガイドラインで、大規模組織なら下回っても認められ得た。

名前を選ぶ前に、入口が決められていた

1984年の一覧を「初期のドメイン名」とだけ呼ぶと、その名前を誰が承認できたのかが見えなくなる。Jon PostelとJoyce Reynoldsが10月に発表したRFC 920は、ARPA-InternetとDARPA研究コミュニティでドメインを設けるための、Internet Activities BoardとDARPAの公式な政策声明だった。そこには名称の階層だけでなく、どの種類のドメインを設けられるのか、誰が担当するのか、申請がどのように認可へ進むのかが書かれている。

技術的な計画はその前からあった。RFC 881はドメイン名計画を説明し、RFC 882とRFC 883は概念と実装を扱った。RFC 920は先行文書の要件を詳しくし、限られたトップレベルの集合を導入したと説明する。名前を解決する仕組みと、その最上位に誰を置くかという政策は、関係はしていても同じ決定ではない。

最初の集合には、一時的な名前、組織カテゴリー、まだドメインが存在しない二つの候補が含まれていた。

初期集合での位置 名前または分類 1984年の記載
一時的 ARPA 当時のARPA-Internetホスト。明確に一時的とされた
組織カテゴリー GOV、EDU、COM、ORG DARPAが管理者、NICがエージェント
軍事カテゴリー MIL DDN-PMOが管理者、NICがエージェント
国 英語表記のISO alpha-2、2文字コード 国別ドメインはまだ設立されていなかった
複数組織 具体的なラベルは未定 設立例はなく、ほかの分類に収まらない大規模な国際団体が候補となり得た

この一覧は、すべての枝がすでに使われていたという記録ではない。RFC 920は、国別と複数組織のドメインがまだ設立されていないと明記する。管理者も一律ではなかった。ARPA、GOV、EDU、COM、ORGはDARPAが管理し、Network Information Centerが代理を務めた。MILの管理者はDDN-PMOで、NICはここでも代理と登録窓口を担った。トップレベルの名前は、見栄えのよい文字列を選べば自動的に成立するものではなく、認可と登録を要した。

ホスト数の基準も、単純な足切りではない。トップレベルには特別な認可が必要で、一般には500ホスト超が見込まれるドメインに限るとされた。セカンドレベルは50ホスト超が目安だったが、RFC 920はこれを「非常に柔軟」な要件と呼び、主要な大学や企業なら数台のホストでも認められ得ると説明する。数値を超えたからといって、新しいドメインを作る義務が生じるわけでもない。規模に加えて、責任ある管理者、信頼できる名前解決サービス、上位への登録が必要だった。

複数組織の例外は、分類表だけでは扱えない集団のために設けられた。複数の組織から成る大規模な国際団体で、既存カテゴリーに簡単に当てはまらないものは、トップレベルの候補となり得た。RFC 920は、大学や産業研究所を含むCSNETという仮想の共同体を例に挙げる。複数のプロトコルやネットワークを使っても、責任を持つ管理者がいればドメインの条件を満たし得る、という説明だった。ここでのCSNETは例示の役割に限られる。同じ文書が、当時はそのようなトップレベルドメインがまだ存在しないとも述べているため、実際にCSNETがその地位を得た証拠ではない。

登録の連鎖は下位の階層にも続く。セカンドレベルの管理者はトップレベルの管理者に登録し、その下の管理者は直上の管理者または責任者に登録する。上位側が要件を満たすと判断してから、認可が与えられる。サブドメインに権限や作業を渡すことはできるが、トップレベルの責任者は名称ツリー全体への責任を保つ。階層は名前を分割するだけでなく、保守と問題対応の責任も分けていた。

その責任には実務が伴う。ドメインには、質問を取りまとめ、技術的な知識と問題を直す権限を持つ担当者が必要だった。ホストが域外との通信に問題を起こせば、報告を受け、解決に動かなければならない。名前解決サービスにも堅牢性が求められた。別々の電源系統を持つ独立した2台のサーバーは共通障害を避ける一つの方法だが、それだけに限定されない。ほかのドメインと協力してサーバーを提供する方法や、第三者に委託する方法も記されている。条件は同一構成の採用ではなく、データとサービスを維持できる管理体制だった。

ARPAは期限のある例外だった。RFC 920は、この名前がシステムの開発経緯から生じたもので、いずれ使われなくなる予定だと述べる。現在の利用者には別のドメインへ移る準備を勧めた。新サービスに参加しないDDNホストは、NICが保守するHOSTS.TXTを継続利用できるとされた一方、将来は名前を変更する見込みも書かれていた。これは1984年の方針と計画であり、全ホストが移行したことや、特定日にARPAが消えたことを示す証拠ではない。

後の段階は1987年のRFC 1032に見える。ドメイン管理者向けのこのガイドは、NICの登録窓口とルートゾーン運用を説明し、CSNETとUUCPの管理部門が申請を自組織向けに処理してからNICへ情報を渡す役割を担ったと記す。ここでのトップレベル一覧にはNETや国別ドメインも含まれる。これは後年の状態であり、1984年の初期一覧へ遡って当てはめるべきではない。後の運用の証拠ではあるが、1984年に書かれた期待がすべて同じ形で実現した証明ではない。

RFC 920の初期一覧は、見慣れたラベルの寄せ集めではなかった。分類を定め、管理者を割り当て、既存カテゴリーを横断する集団の例外を設け、誰が新しい枝を認めるかを定めていた。名前の集合は小さくても、最上位に入るかどうかはすでに制度的な判断にかかっていた。

出典

次の関連文書は扱う範囲を限定するために確認したもので、後年の状態を1984年へ遡及させるものではない。