Summary

  • 1984年のバークレー技術報告は、BINDを分散Unix環境の名前解決サービスとして説明した。DNSの発明や最初のサーバーを主張したものではない。
  • 1987年にはBINDが4.3BSDとともに配布されたことが運用文書に記録され、1989年のインターネット解説は、/etc/hostsに基づく検索を置き換える統合サービスとして紹介した。
  • 変化は運用面にあった。仕様が相互運用の共通動作を定め、配布ソフトウェアと各組織が管理するゾーンデータが、ネットワーク上で名前を解決する手段を提供した。

仕様だけでは、名前は引けない

名前システムは、設計が優れていても日々の管理を変えるとは限らない。サーバーを導入し、データを与え、更新し、ホストのプログラムから問い合わせられるようにする作業が要る。初期DNSに対するバークレーの貢献は、その作業をUnix環境に載せたことだった。

1984年、Douglas Terry、Mark Painter、David Riggle、Songnian Zhouは、Berkeley Internet Name Domain（BIND）サーバーの技術報告を発表した。概要は、分散Unix環境にある資源へ共通の名前を付け、情報を保存・取得し、管理単位ごとに階層名前空間を分ける仕組みを説明している。これはソフトウェアと運用の設計であり、DNSを発明したという主張ではない。Paul Mockapetrisの先行サーバーJeevesは、すでにUSC-ISIとSRI-NICで稼働していた。ISCの後年の沿革も、JeevesとバークレーのBINDを別の実装として扱っている。

BINDが解こうとした実務上の課題は、複数の管理ドメインにデータが分かれた名前システムへUnixホストをどう参加させるかだった。サーバー、ローカルファイル、既存の名前解決経路を組み合わせ、ドメインの管理者が自分の範囲のレコードを保守し、リゾルバーが委任先のサーバーに問い合わせて応答をキャッシュする。名前空間が分散しているとは、データと責任が分散しているということだ。利用者が各機械の所在地を覚える必要はない。

稼働中のネットワークが仕様を変えた

時系列も重要だ。DNSの初期仕様は1983年のRFC 882とRFC 883に記された。1986年1月のRFC 973は、すでに仕様変更、運用指針、現場で見つかった問題や不足を記録している。広く使われている変更は仕様の一部として扱うべきだとも述べる。実装や運用から得た経験が、稼働中のシステムの仕様へ戻っていた。

改訂版のRFC 1034とRFC 1035は1987年11月に発行され、DNSの概念と実装を定めた。名前、リソースレコード、問い合わせ、キャッシュ、委任を相互運用可能にする共通ルールは不可欠だった。しかしRFCは管理者がインストールするソフトウェアではない。実装と運用手順も必要だった。

1984年のバークレー報告は、分散Unix資源の名前解決サービスとしてBINDを位置づける。ISCのBIND沿革は初期チームを挙げ、Computer Systems Research Groupがバージョン4.8.3まで保守したとする。この回顧から開発の流れは分かるが、各版の導入台数までは分からない。

BSDと一緒に届いたサーバー

同時代の証拠は1987年11月のRFC 1033にある。付録の見出しは「4.3 BSD UNIXとともに配布されたBIND」と明記し、named.bootなど起動・キャッシュ用の固有ファイルとゾーンの例を説明する。すべてのBSDホストが名前サーバーを動かしたと証明するものではない。しかし、管理者が馴染みのあるUnix配布物からBINDを入手し、設定資料を参照できたことは示す。

配布形態は試行のコストを下げた。管理者がDNSサーバーを書いてからでなければドメインを作れない、という状況ではなくなった。起動ファイルからサーバーを立ち上げ、ゾーンデータを読み込み、ローカル問い合わせに答え、管轄外の名前は他のサーバーに問い合わせられる。レコードの正確さ、親ドメインとの委任、更新の手間は残った。BINDは動く道具を提供したが、正しいデータを保証したわけではない。

2年後のRFC 1118は、より具体的に記述する。Ed Krolによれば、BINDは4.3BSDに統合され、ホスト名、アドレス、メールエージェントなどの検索・保存に使われ、/etc/hostsベースの検索を置き換えた。イリノイ大学アーバナ・シャンペーン校の例では、SRIが配布するホスト表に載る機械はわずかで、大学ドメインの大半の名前はローカルのBIND表に置かれていた。それでも、BINDまたは別のDNSリゾルバーを使う外部ホストから参照できた。

これは、単一のデータベースか、協調のない状態かの二択ではない。SRIのホスト表は残り、DNSは各組織がより大きな名前空間を自ら管理し、共通の問い合わせ規則で公開する道を加えた。RFC 1118は、IPで直接到達できない内部ホスト、たとえばUUCP経由の機械に向けたメール配送情報もBINDで提供できると説明する。ホストの物理位置やネットワーク上の位置が変わっても、サービス名は保てた。

ローカル管理と共有規則

「分散」という言葉から受ける印象より、運用の境界は具体的だった。バークレーと後の保守者がソフトウェアを配布し、プロトコル文書が共通動作を記述し、各ドメインの管理者が自分の範囲のレコードを管理し、リゾルバーとサーバーが問い合わせを処理する。一つが他を置き換えるわけではない。古いゾーンデータは整合した誤答を返し得るし、委任が食い違えばBINDが正常でも名前解決は失敗する。

Heng Luが後年に強調した実行中のコードという視点は、BINDの著者の意図を示すものではなく、分析上の問いとして役立つ。管理者は実際に何を受け取り、何をしたのか。証拠が示すのは、設計報告、運用経験による更新、4.3BSDとの配布、そして各組織によるローカル名の管理という流れである。文書の公開は重要だったが、それだけで大学のゾーンは埋まらず、利用者の問い合わせにも答えなかった。

証拠には限界がある。RFC 1033は4.3BSDとの配布を示し、RFC 1118は統合と大学の一例を記録する。全ホストへの導入、DNS普及の唯一の原因、すべてのホストファイルの消滅を立証するものではない。確実に言えるのは、BINDがDNSを管理者の運用できるUnixサービスにする助けとなったことだ。各ドメインが自らの範囲を管理しながら、名前の木全体と相互運用できる道を作った。

Sources