JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPRS トピックス＆コラム No.010
DNSはインターネットにとって不可欠な存在です。しかし、その動作原理について正しく理解している人は意外に多くないようです。
今回はDNSのしくみと動作について解説します。
インターネットにおける通信のしくみ
DNSについて解説する前に、インターネットにおける通信のしくみについて簡単におさらいしておきましょう。
インターネットでは通信相手を「IPアドレス」という番号で指定・識別しています。IPアドレスはインターネットに接続しているすべての機器に割り当てられ、各機器は割り当てられたIPアドレスによって識別されます。
IPアドレスはインターネットに接続しているすべての機器で異なっており、同じIPアドレスが異なった機器に重複して割り当てられることは原則としてありません。
そして、インターネットで機器同士が通信を行う場合、送信側で受信側のIPアドレスを指定してデータを送信します。そして、受信側で送信されてきたデータのIPアドレスを調べることにより、どの相手からデータが送られてきたのかを調べることができます（図 1）。
DNSの役割
このようにインターネットでは、IPアドレスが送信先の指定や送信元の特定に使われています。実際に、ユーザーが接続先を、例えばhttp://192.0.2.1/（IPv4の場合）やhttp://[2001:db8::1]/（*1）（IPv6の場合）のようにIPアドレスで直接指定しても、Webサイトを見ることができます（*2）。
しかし、我々がインターネットを使う場合、このような形でIPアドレスを直接指定する必要はほとんどありません。通常はhttp://jprs.jp/のような覚えやすい名前（ドメイン名）を使って接続先を指定できるからです。
DNS（Domain Name System）はこのように、人間が記憶しにくいIPアドレスに替え、より記憶しやすく使いやすい「名前」をインターネット上で使えるようにするために開発されたシステムです（図2）。
DNS開発物語-HOSTS.TXTからDNSへ
ここではDNS が開発され、実際に使われるようになるまでの歴史を振り返りながら、DNSの成り立ちについて解説します。
インターネットの前身であったARPANET（*3）では、ホスト名とIPアドレスの対応表として、HOSTS.TXTというテキストファイルを使っていました。
ARPANETが運用されていた1970年代から80年代にかけ、HOSTS.TXTのマスターファイルはIPアドレスの国際割り当て機関であった米国のSRI-NIC（*4）で管理され、FTPにより公開されていました。新しくARPANETに接続した組織は最新のHOSTS.TXTをSRI-NICから入手し、自分のコンピューターに導入していました。
HOSTS.TXTを入手し、自分のコンピューターに導入することにより、相手先のコンピューターを名前で指定することができるようになります（図 3）。
名前とIPアドレスの対応に追加や変更などがあった場合、ユーザーはその変更内容をSRI-NICに電子メールで通知します。SRI-NICではその都度HOSTS.TXTの更新作業を行い、更新したファイルを公開します。各組織では定期的にSRI-NICからHOSTS.TXTを入手、更新することにより、常に最新の情報に保つことができることになります。
しかしこの方法は、
① 接続ホスト数の増加による、HOSTS.TXTファイル自身の肥大化
② HOSTS.TXTファイルの更新頻度の増大による、SRI-NICの作業量の増加
③ マスターファイルを集中管理する、SRI-NICのサーバーの負荷の増大
などの理由により、1980年代の初頭には既に限界に達していました。そのため当時、問題を解決するための新たな仕組みの開発が急務となっていました。
そして、問題解決の手段としてDNSが開発され、最初のバージョンが1983年にRFC 882およびRFC 883として公開されました。その後、RFC 882とRFC 883は1987年にRFC 1034とRFC 1035に改版され、現在のDNSになりました。DNSはその後も多くの機能付加や改良が施され、開発から30年以上が経過した現在も、インターネット上で広く使われています。
DNSの基本―階層構造と委任の原理
DNSのしくみのうち最も重要な、「階層構造による分散管理」と「委任の原理」について解説しましょう。
従来からのHOSTS.TXTによる集中管理方式では、インターネット（ARPANET）におけるすべての名前とIPアドレスの対応表を、SRI-NICやDDN NICにおいて集中管理していました。そのため、インターネット自身の成長により名前の管理が限界に達してしまいました。
そこでDNSでは、この対応表を各組織において分散管理することにより全体の負荷を軽減し、かつネットワーク全体で一つの大きな対応表のように連携して動作するようにするための仕組みの開発が、重要なテーマとなりました。
▼ドメイン名の導入と対応表の分散
そこでDNSでは、「ドメイン名」と呼ばれる新しい概念が導入されました。従来のHOSTS.TXTによる名前管理方式ではすべての名前を一カ所で集中管理していたのに対し、DNSではドメイン名を用いた階層構造の導入を行い、階層的な名前（名前空間）による分散管理を実現したわけです。
DNSによる管理では、まず名前空間の起点となる「ルートサーバー」と呼ばれるDNSサーバーを配置します。ルートサーバーは「jp」や「com」など、各ドメイン名の一番右側（*5）のドメイン名（TLD）のDNSサーバーが、インターネット上のどこにあるのか（どのIPアドレスにあるのか）を管理します。そしてルートサーバーでは通常、各組織内の実際のドメイン名とIPアドレスの対応表は管理しません（図 4）。
次に「jp」や「com」などといったTLDを管理するDNSサーバー（TLDサーバー）では、自分が管理しているTLD内の情報のみを管理します。例えばjpのDNSサーバーではjpの下の階層、つまり「example.jp」や「日本語.jp」などのDNSサーバーがどこにあるか（どのIPアドレスにあるか）という情報のみを管理します。
TLDサーバーにおいても通常、各組織内の実際のドメイン名とIPアドレス対応表は管理しません（図 5）。
その下の階層に準備されるDNSサーバーでは、例えば「example.jp」というドメイン名内の名前のみを管理することになります。例えば「www.example.jp」のような名前とIPアドレスの実際の対応表を持たせることもできますし、「subdomain.example.jp」といった、更に深い階層のドメイン名を設定することも可能です（図 6）。
DNSでは、このようなドメイン名の委任（delegation）により、それぞれの名前の管理権限を明確にすることができます。そして、ドメイン名とIPアドレスの対応表は、各組織のDNSサーバーにおいて分散管理されるため、データの一極集中を回避することができます。
DNSにおける実際の問合せの流れ
では、このようにデータが分散管理されたDNSにおける名前解決（ある名前に対応するIPアドレスを得ること）は、どのように行われるのでしょうか。
www.example.jpのIPアドレス情報をDNSで入手する場合を例に、順を追って解説しましょう（図 7）。
① まず「それぞれのDNSサーバーに対し、問い合わせを行うコンピューター」を用意します。そのコンピューターにはルートサーバーのIPアドレスが書かれた表を、あらかじめ準備しておきます。
② www.example.jpに対するIPアドレスの情報が必要になった場合、ユーザーは問い合わせを行うコンピューターに名前解決を依頼します。
③ 依頼を受けたコンピューターは、ルートサーバーにwww.example.jpのIPアドレスを問い合わせます。
④ ルートサーバーはこの名前に対するIPアドレスの情報を管理していません。しかし、jpを管理しているDNSサーバーの情報は知っているので、問い合わせ元にjpのDNSサーバーの情報を返します。
⑤ 応答を受け取ったコンピューターはその情報を元にjpのDNSサーバーに対し、③と同様の形でwww.example.jpのIPアドレスを問い合わせます。
⑥ jpのDNSサーバーもルートサーバーと同様、自分が知っているexample.jpのDNSサーバーの情報を、問い合わせ元に返します。
⑦ 応答を受け取ったコンピューターはその情報を元にexample.jpのDNSサーバーに対し、③と同様の形でwww.example.jpのIPアドレスを問い合わせます。
⑧ example.jpのDNSサーバーは、自分が管理している対応表からwww.example.jpのIPアドレス情報を、問い合わせ元に返します。
⑨ 応答を受け取ったコンピューターは、入手したIPアドレスの情報をユーザーに返します。
以上の①から⑨までの手順によりユーザーは、www.example.jpのIPアドレス情報を入手できます。
このようにDNSでは、問い合わせを行うコンピューターが、情報を管理しているそれぞれのDNSサーバーに対し、ルートサーバーから順に反復検索（Iterative query）を行うことにより、名前解決が行われます。
異なった機能を持つ2種類のDNSサーバー
前述した「問合せを行うコンピューター」は、ユーザーのコンピューターに対し名前解決のサービスを提供する役割を備えていることから、階層構造を構成するDNSサーバーと同様、DNSサーバーと呼ばれています。
しかし、このDNSサーバーはこれまでに説明したDNSサーバーとは異なり、下の階層のDNSサーバーの情報やホスト名とIPアドレスの対応表など、名前情報の実体は管理していないことに注意する必要があります。
すなわちDNSでは、
① 階層構造をたどり、名前解決を行うサーバー
② 階層構造を構成し、情報を管理するサーバーの、異なった機能を持つ2種類の「DNSサーバー」が存在することになります（図 8）。
DNSでは①のサーバーを「フルリゾルバー（full resolver）」と呼びます。フルリゾルバーは名前解決の際に得られた名前情報をキャッシュする機能（*6）を備えていることから、キャッシュDNSサーバー（caching DNS server）と呼ぶことが一般的です。
また、②のサーバーを、それぞれのドメイン名に対する管理権限（オーソリティ）を持つことから、「権威DNSサーバー（authoritative DNS server）」と呼びます。
DNSを理解する場合、この2種類のサーバーの動作と役割をきちんと区別して把握することが重要です。
サーバーの機能の違いに注意―機能分割を
DNSリフレクター攻撃（*7）やカミンスキー型攻撃手法（*8）に対する防御のため、権威DNSサーバーとキャッシュDNSサーバーを別のサーバー、あるいは別のIPアドレスに機能分割し、そのうえでキャッシュDNSサーバーに適切なアクセスコントロールを実施し、オープンリゾルバー（*9）として利用されないように対策することが強く推奨されています。
また、権威DNSサーバーでは名前解決を行う必要がないため、階層構造をたどる反復検索機能は必要ありません。そのため権威DNSサーバーではオープンリゾルバーとして利用されないように、再帰検索要求の受け付けを無効に設定することが強く推奨されています。
重要なDNSサーバーの多重化と信頼性の向上
DNSでは階層構造によって名前が管理されているため、階層構造を構成している権威DNSサーバーに障害が発生した場合、その影響はインターネット全体に及ぶことになります。
そのため、特に重要な役割を負っているルートサーバーやTLDのDNSサーバーなどでは、権威DNSサーバー自身の冗長化に加え、IP Anycast（*10）などの技術を導入することにより、DNSサービスが停止することがないよう、細心の注意を払った運用が行われています。
インターネットを支え続けるDNS
インターネットでDNSが運用され始めてから、既に30年以上が経過しています。しかしDNSは現在も運用開始当初と基本的に同じ仕組みで運用されており、最近では電子メールの送信元認証（SPFやDKIM）に使われるなど、その重要度がさらに高まっています。
DNSは今後も、成長し続けるインターネットを支える、重要な基本機能の一つであり続けることでしょう。
IPv6接続環境が必要になります。
Webサーバー側でバーチャルホスト機能を使用している場合など、IPアドレスを直接指定して見ることができない場合もあります。
1969年に米国国防総省高等研究計画局（ARPA）により構築されたコンピューターネットワーク。
Stanford Research Institute - Network Information Center
ドメイン名による管理方法では左から右に行くに従い、より広い名前空間を表します。
得た情報を一時的に記憶し、非効率な再検索を防ぐための機能。
DNSリフレクター攻撃についてはJPRS トピックス&コラムNo.3「DDoSにあなたのDNSが使われる」をご参照ください。
カミンスキー型攻撃手法についてはJPRS トピックス&コラムNo.9「新たなるDNSキャッシュポイズニングの脅威」をご参照ください。
必要なアクセスコントロールや機能制限が実施されておらず、インターネット上のどこからの名前解決要求であっても実行してしまう状態のDNSサーバー。
IP Anycast の詳細についてはJPRS トピックス&コラムNo.5「DNSのさらなる信頼性向上のために」をご参照ください。
掲載内容は2014年12月のものです。
Copyright©2001-2024 Japan Registry Services Co., Ltd.
