要約

  • RFC 1101 はネットワーク名、番号、入れ子のサブネットを DNS で対応付ける方式を提案した。ホスト部ゼロの IN-ADDR.ARPA 名に PTR を置き、さらに下位のサブネットがあれば A レコードでマスクを運んだ。
  • この方式は組織がローカルに選ぶ名前と、NIC が割り当てた番号の記録を分けた。DNS の回答は範囲内の対応を記述できても、番号を割り当てず、後の改名を自動追跡せず、現在の支配や通信結果を示さない。

HOSTS.TXT から受け継がれなかった一点

P. Mockapetris の RFC 1101 は、DNS の欠落を一つだけ取り出す。DNS は拡張可能で、HOSTS.TXT が担っていた多くの情報を配布できるようになっていた。しかし、ネットワーク名とネットワーク番号を往復する機能は残っていた。1989 年 4 月の文書は、そのための具体的な方法と、より一般的な識別子—番号の「Yellow Pages」を別々に提示した。

両者の扱いは同じではない。ネットワーク名の方式は Proposed Standard、一般的な YP は実験的な案である。番号が一つの普遍的な人間的意味を獲得する、という主張ではない。管理者が責任を持つ DNS の範囲で、選んだラベルと番号の関係を公開できるようにする提案だった。診断画面は数字だけでなく名前を示せるが、それだけで所有、経路、権限、サービスの作動を知ったことにはならない。

名を決める場所は、名を維持する場所に近かった

ネットワーク名の議論は、記法の議論であると同時に統治の議論でもあった。従来の平坦な名前空間は、番号と同じように中央が名前を統制する設計になじみやすい。RFC 1101 が記録する多数意見は反対で、ネットワーク名のローカルな管理を選んだ。拡張されたホスト名の構文を使い、管理者が自分の管理下のドメインでネットワーク名を作れるようにした。

名前が単純になるわけではない。RFC は、ネットワーク名もホスト名と同じだけ複雑になると述べている。それでも、その名前を保守する文脈と責任は近くに残る。文中の ARPANET.ARPA. は当時の命名選択を示す例であり、資源の永久的な定義でも、番号の使用権を与える文書でもない。

IP アドレスから逆向きにたどるには別の入口がいる。ローカル名だけから、どの管理域に問い合わせるかは分からない。そこで RFC は、すでにアドレスに沿って委任されていた IN-ADDR.ARPA を再利用した。限定された逆引きの説明のために、もう一つの世界的な階層を作らずにすんだ。

ホスト・ゼロは端末ではなく見出しだった

提案された形は <逆順ホストゼロ番号>.IN-ADDR.ARPA. PTR <ネットワーク名> である。ネットワーク名側には逆向きの PTR を置く。さらにサブネットが続くときは、同じホスト・ゼロの場所に A レコードを置き、そのデータとしてサブネットマスクを入れる。0.0.0.10.IN-ADDR.ARPA. と 0.0.2.128.IN-ADDR.ARPA. は、あくまで RFC が印刷した構造例である。

ホスト部がゼロだからといって、そこが利用可能なホストになるわけではない。DNS ツリーの中で説明的なデータを置き、存在を確かめられる見出しになる。PTR は番号向けの入口をローカルに維持された名前へつなぐだけで、ルーターを設定せず、権限を与えず、名前を番号の法的・運用上の主体にも変えない。

この A レコードも役割を超えて読んではならない。この提案では、次のサブネット階層があるときにマスクを運ぶ。文書にある当時のクラス A/B/C の手順では、IP をマスクし、オクテットを逆順にして PTR を問い合わせる。マスクを含む A が返れば、元の IP にそのマスクを適用してもう一段調べる。A がなければ入れ子は終わる。これは歴史的な探索手順であり、現在のトポロジー、経路、到達性の証明ではない。

三方向の PTR も一つの支配権にはならない

RFC 1101 は組織名から一つ以上のホスト・ゼロ項目へ PTR を置くことも許した。ネットワーク名から番号風の項目へ、番号風の項目から選ばれた名前へ、組織名から複数のネットワーク記録へ、という三方向が可能になる。それぞれが役に立つのは、それぞれ別の小さな問いへの答えだからである。

あるドメインで公開された組織との関連は、その公開についての事実である。ネットワーク名は命名選択についての事実である。回答は、ある時点のあるアルゴリズムと問い合わせについての事実である。どれも、追加の証拠なしに現在の所有、企業関係、物理的管理、許可、BGP 経路、パケット受領、アプリケーションの成功を証明しない。RFC 1101 は、記録にそれ以上を語らせないことで記録を有用にした。

割り当てられた番号は後の名前を決めなかった

YP の節は、この境界を最も明瞭に書く。RFC はポート名と番号、自律システム識別子と番号、割り当てられたネットワーク名と IP アドレスのような対を、DNS のドメイン木で索引化する案を示した。キーには「何から何へ」の型が必要である。型のない数字には、まだ対応の意味がない。

NIC は自らの割当て決定を記録する YP ドメインを維持できた。しかし RFC は、それが扱うのは割り当てられた名前と番号であり、組織が後で自ら選んだ名前ではないと明記する。新しい所有者の改名を自動的に追わない。割当ての履歴とローカルな命名は、意図して別の事実にされた。

中央の一覧は中央の割当て決定について強い証拠になり得る。ローカルなゾーンはローカルに公開されたラベルについて強い証拠になり得る。しかし、現在の運用者、提供中のサービス、経路方針、取引の結果を近道で導く権利にはならない。記録はその境界にある現実を記述するのであって、読み手が足したい残りの現実を作り出すものではない。

歴史資料の大きさで読む

RFC 1101 は 1989 年の提案を示す資料である。クラスフルな手順、YP ドメイン、例示された組織が、現在の DNS 配置を説明するわけではない。それでも、対応には出所、方向、範囲を持たせ、記録に書かれていない決定まで背負わせないという規律は残る。公開名、割当て番号、観測された経路、証明された結果は、別々の命題のままである。

出典と証拠の境界

本稿は RFC 1101、RFC 1034、RFC 1035 を用いる。これらは 1989 年の提案、記録形式、割当て名とローカル名の区別を裏づける。現在の DNS データ、現在の支配、所有、本人性、経路、到達性、権限、サービス性能を裏づけるものではない。