【DNS】One day, Jon walked into my office and asked
Jon Postel からの依頼、Paul Mockapetris の答え
Jon Postel（インターネットの神）が Paul Mockapetris にした依頼からはじまった Domain Name System の構想。
今回の記事は DNS 誕生前についての物語。当時のインターネットの名前解決システムは、主にHOSTS.TXTファイルに依存しており、この単一のファイルがSRIのNICによって一元的に管理されていた。この仕組みは、インターネットの規模拡大に対応できず、限界を迎えていたのだ。
今回の記事の主要な登場人物と組織
Jon Postel (インターネットの神)
出典:https://en.wikipedia.org/wiki/Jon_Postel
インターネットの初期における、通信規約(protocol)や番号割り当てなどの標準化を、事実上一人で担っていた中心人物なのだ。その絶大な影響力と貢献から、多くの技術者に「神 (god of the Internet)」とまで呼ばれている。今回の物語では、彼が「依頼者」として登場するのだ。
Paul Mockapetris (DNSの父)
今回の物語の主人公であり、DNS (Domain Name System) を発明した人物なのだ。「神」であるJon Postelからの依頼を受け、中央集権的だったHOSTS.TXTの問題を解決するため、全く新しい「分散型」のシステムを設計した。後に「DNSの父」として知られることになるのだ。
USC ISI (南カリフォルニア大学情報科学研究所)
今回の物語の主要な「舞台」となる研究所なのだ。Paul MockapetrisとJon Postelは当時この研究所に在籍しており、DNSの設計と開発は、ここUSC ISIで行われた。
SRI (スタンフォード研究所)
SRIは Stanford Research Institute の略なのだ。
当時、このSRIの中にあったNIC (Network Information Center) という組織が、HOSTS.TXT ファイルの管理と配布を一手に行っていた。
つまり、SRIは当時のインターネットにおける中央集権的な管理者であり、名前解決におけるボトルネックでもあったのだ。
今回の記事のモチベ
今回の記事の元になった Paul Mockapetris 自身の執筆記事なのだ
この記事を読むと、Paul Mockapetris が DNS を設計した際、いかに「分散型」という考えを強く意識していたかがわかるのだ。
彼がDNSを発明したのは1983年。これは、webの父 Tim Berners-Lee によって web が公開される1991年よりも、ずっと前の出来事なのだ。
web がまだ存在しなかった時代に、彼はどのような文脈で開発に臨み、どんな哲学を持っていたのかを伝えたいと思ったのだ。
はじまり：魅力的な機会
1978年、Paul Mockapetris 氏が UC Irvine 校の大学院生としてISI（情報科学研究所）に参加した頃、ネットワークの世界は大きな変革の時期にあったのだ。
当時の研究コミュニティは、最初の実用的な computer network であった ARPANET から、私たちが今日使っている IP/TCP ベースの internet への移行を進めていた。そのため、network 設計のほとんどあらゆる側面が、根本から再考される状況だったのだ。
彼が所属したチームは、後に「インターネットの神」と呼ばれることになる Jon Postel 氏に監督されていた。そんなある日、Jon Postel 氏が彼に直接声をかけたのだ。
"One day, Jon walked into my office and asked whether I’d like to work on the domain naming problem. It’s hard to overstate how attractive that opportunity was."
「そんなある日、Jonが私のオフィスに歩いてきて、domain naming problem（ドメインネーミング問題）に取り組んでみないかと私に尋ねたのだ。その機会がどれほど魅力的だったかは、言葉で言い表せないほどなのだ。」
インターネットのレジェンド、Jon Postel（技術者たちが「神」と崇める男）が、Paul Mockapetris に「ドメインの名前問題、なんとかしてよ！」と声をかけた瞬間から、DNSの物語は始まったのだ。
最初の依頼：5つの提案のレビュー
この問題を解決するため、すでに何人かの研究者から解決策のアイデアが提出されていた。
インターネットの舵取り役であった Jon Postel 氏がMockapetris氏に最初に依頼したのは、全く新しいものを発明することではなかった。その依頼とは、「今あるこれらの提案を専門家としてレビューして、どれが良いか、あるいはこれらを統合してうまく動くシステムが作れるか、意見を聞かせてほしい」というものだったのだ。
提案の先に見た「拡張性」と「分散型」
依頼を受けたPaul Mockapetris氏は、提出されていたすべての提案をレビューした。しかし、彼はどの案にも満足できなかったのだ。彼の目には、それらの提案は目先の修正に過ぎず、将来の成長に対応できるような、十分な拡張性 (scalability) を持っていないと映った。
そこで彼は、自身が大学で研究していた「分散型 (distributed)」システムの考え方をベースにした、全く新しいアプローチを考案する。
"I was actually tasked with consolidating five different proposals, and nobody noticed that I did something completely different."
「私は本当は5つの異なる提案を統合するよう任されていたのだ。そして、私が全く違うことをしたことに、誰も気づかなかったのだ。」
当初の依頼の範囲を超えて彼が作り上げたものこそ、現在我々が使っている階層的で分散型のDNS (Domain Name System) の原型となったのだ。
この発言や経緯が示す通り、DNSの背景には Paul Mockapetris 氏の設計思想があるのだ。
彼は、未来を正確に予測するのではなく、未知の規模拡大に対応できる「拡張性 (scalability)」という考え方を取り入れた。そして、その拡張性を実現する手段として、「分散型 (distributed)」システムという構造を採用したのだ。
彼が作り上げたこの仕組みが、誕生から数十年が経過した現在も、インターネットを支え続けているのだ。
DNS の核心をなす三つのビジョン
Paul Mockapetris 氏が DNS について抱いたビジョン。先ほどの記事の内容も踏まえ、彼が DNS の設計で考えていたこと３つを最後にまとめたいと思うのだ。
1. 権限の分散 (Delegation of Authority)
DNSの最大の革新は、名前空間の管理権限を分散させたことなのだ。彼は、単一の master file に依存する中央集権的な体制をなくし、階層の各レベルが独立して管理できる分散型システムを構想した。これにより、全世界的な一貫性を保ちつつ、管理を分散させることが可能になったのだ。
2. 自律的な運用 (Autonomous Operation)
この分散化により、各組織は自身のdomain空間を自律的に管理できるようになった。これによりSRIという単一のボトルネックが解消され、各組織が自身のデータを直接管理できるようになったのだ。中央の許可や介入を必要としないこの自律性が、インターネットの爆発的な成長を支えたのだ。
3. 拡張性 (Scalability)
彼は、階層構造とDNS Cachingという仕組みを設計し、システムが未知の巨大化に対応できるよう設計したのだ。
階層構造 (Hierarchical Structure)
Paul Mockapetris氏がDNSを設計した際の最も大きな功績の一つが、それまでのフラットな名前空間（単一のHOSTS.TXT）を、階層構造（ツリー構造）にしたことなのだ。これは彼の独創的なアイデアであり、ドメインを委譲（分散）させることを可能にしたのだ。
DNS caching
キャッシュ機構（DNS caching）とは、一度調べた名前解決の結果を、一時的にコンピューターやサーバーが「覚えておく（保存しておく）」仕組みのことなのだ。
例えば、あなたのコンピューターが www.example.com のIPアドレスをDNSに問い合わせて答えを得たとします。キャッシュ機構があると、その答え（IPアドレス）を一定時間、近くのサーバーやPC内に保存しておくのだ。次にあなたが（あるいは同じネットワークの誰かが）同じ www.example.com にアクセスしようとした時、わざわざ大元のサーバーまで聞きに行かなくても、保存しておいた答えをすぐに使えるのだ。
これにより、ネットワーク全体の問い合わせ量が劇的に減り、応答速度も速くなるのだ。
「量」に対応する能力
ドメインの数が100万から10億に増えても、問い合わせの数が1日1億回から1000億回に増えても、システムが破綻せずに対応できる能力のこと。分散管理やキャッシュが、この拡張性を支えているのだ。
「種類」や「機能」を追加できる能力
DNSの基本ルールをシンプルにしておくことで、後からメール用の情報(MXレコード)や、セキュリティー用の情報(DNSSEC)など、新しい「種類」の情報を追加できるようにしたのだ。
参考文献
Note
SRIのwebsiteからはなぜか HOSTS.TXT に関する記事ページがみつけれなかったのだ。
この辺りのソースは改めて RFC（インターネットの技術仕様やプロトコルを定めるために公開される公式な文書シリーズ）を調べた方がよさそうなのだ。
いちおう調べた範囲だとこのページでhosts.txtというファイル名は明記されてこそいないが、NICがネットワークの「ホストテーブル」を維持・管理し、それがホスト名とアドレスを関連付けてトラフィックを指示する役割を担っていたことが示されているので、これはhosts.txtが果たす役割と概念的に類似しているのだ。
Discussion