冒頭、「誕生当時のDNSとその進化のカタチ」を担当した芳野氏は、インターネットが始まった当時、DNSは動かすことが優先であり、悪意の存在を想定していなかったことを述べた(図1)。
図1:誕生当時のDNSのカタチ(プロトコル)動かすことが優先、悪意の存在を想定しないという「カタチ」は、当時のインターネットは利用者や利用目的が制限されており、かつ匿名ではなかったこと、コンピューターの処理能力の低さや通信環境がさほどよくなかったという背景を考えると、やむを得なかったとも言える。当時のインターネットはとにかく相手とつながることが最優先であり、通信プロトコルはシンプルで動作が軽く、実装・運用が容易であることが求められていた。
図1で示される内容は、現在もDNSの解説書でよく見かける内容である。UDPを使用し、平文による問い合わせと応答が1セット、UDPメッセージサイズの最大値が512バイトといった内容は、古くからDNSに関わっておられる方にはおなじみのものであろう(この図はあとで意味を持つので、覚えておいていただきたい)。
DNSの本来の役割は「名前解決」であり、ドメイン名とIPアドレスを紐付けることで、アクセスしたい相手と名前で通信できるようにすることである。すなわち、分かりにくく覚えにくいIPアドレスに替え、人間にとって分かりやすく使いやすい「名前」を使えるようにするというのが、HOSTS.TXTから続くそもそもの役割である。
しかしながら、DNSでは当初からドメイン名に対応するIPアドレスだけでなく、より一般的な情報を扱うことも想定していた。それを活用した代表例がMXレコードであり、「そのドメイン名宛ての電子メールを送信すべきサーバー」を情報として登録できるようになっていた。この機能は従来のHOSTS.TXTでは実現が難しく、電子メールの普及がDNSの普及を促進する原動力の1つとなった(図2)。
図2:誕生当時のDNSのカタチ(運用)その後、インターネットが広く普及していく中で、DNSにおいても足りない機能の追加や新たなニーズへの対応、信頼性や利便性の向上が図られていった(図3)。機能追加の例としてIPv6アドレスや国際化ドメイン名が挙げられるが、資料では他に、DNS NOTIFYによる権威DNSサーバー間のゾーンデータ同期の迅速化やネガティブキャッシュによる名前解決の効率向上、BIND以外のDNSソフトウェア実装の登場などについても述べられている(図4)。
図3:DNSの進化のカタチ図4:まとめ:誕生当時のDNSとその進化のカタチ