DNS導入に向けての予備知識：DNSの仕組みと運用（3）（1/3 ページ）

　多くの読者は、すでにDNS環境を構築したか、あるいはこれからDNSと付き合わなければならないのかもしれない。それは、勤務先のDNSサーバの場合もあれば、個人でドメインを取得しようという方もいるだろう。最終回の今回は、これまでの内容を基に、実際にDNS環境を構築するに当たって必要となるいくつかのヒントについて述べてみよう。

DNSサーバの配置と種類

　DNS環境を構築する場合に考慮しなくてはいけないのが、実際にDNSサーバをどのように配置するかだ。実は一言でDNSサーバといっても、その役目に応じていくつかの種類に分けられる。自社や個人利用の目的に応じて、配置や種類を決定しなくてはいけない。

図1　DNSサーバの種類

●プライマリ・サーバとセカンダリ・サーバ

　まずDNSサーバには「プライマリ・サーバ」と「セカンダリ・サーバ」の2種類がある＊1。プライマリ・サーバは自ドメインの全情報を記述した「ゾーン・ファイル」を起動時にローカルから読み込み、その情報を基にDNS問い合わせに応答する。いわゆる「DNS環境の立ち上げ」とは、まさしくこのプライマリ・サーバを立ち上げることにほかならない。一方、セカンダリ・サーバとは定期的にプライマリ・サーバへ接続し、プライマリサーバに設定されているゾーン情報を取得して、同じくDNS問い合わせに応答するためのサーバだ。プライマリ・サーバからセカンダリ・サーバへのゾーン情報のコピーを「ゾーン転送」と呼んでいる。

　両者の違いは、ゾーン情報をどこから入手するかだけだ。管理者はプライマリ・サーバ用のゾーン情報ファイルでDNS情報を設定しておけば、後は自動的に複数のセカンダリ・サーバにも反映されることになり、管理の手間も省ける＊2。一般には、1台のプライマリ・サーバと、1台または複数台のセカンダリ・サーバを配置することになるだろう。本連載の第2回「インターネットを支えるDNS」で、ルート・ネームサーバやjpドメインDNSサーバが複数設定されていたのを覚えているだろうか。実はこれらがプライマリ・サーバとセカンダリ・サーバ群だ。複数台のDNSサーバをそのドメインのDNSサーバとすることで、障害時の対応や問い合わせ負荷の分散を行っているのだ＊3。

　しかし問い合わせ側からすると、実際にどれがプライマリ・サーバでセカンダリ・サーバなのかは分からない。実はプライマリ・サーバとセカンダリ・サーバの違いは、ゾーン情報をローカルのゾーン情報ファイルから入手するか、ほかのDNSサーバ（プライマリ・サーバ）から入手しているかの違いでしかない。問い合わせ側は特に区別はしない（できない）。リゾルバは、通常は複数のDNSサーバからランダムに選択して利用することになる。逆をいえば、実は複数台のDNSサーバがすべてプライマリ・サーバであるという設定も可能だ。見かけ上違いは分からない。ただし、ゾーン情報はそれぞれのサーバで設定することになり、手間が増えるだけなので、あまり意味はないだろう。

「外向けDNS」と「内向けDNS」とは？

　これらプライマリ・サーバ／セカンダリ・サーバの説明は一般に「外向けDNS」と呼ばれる利用方法を想定している。パブリックDNSとも呼ばれるが、自ドメイン以外からの問い合わせ応答用DNSだ（実は内部からの問い合わせも含まれる）。一方、「内向けDNS」などと呼ばれる自ドメイン内ユーザーのためのDNSも、別途必要になることもあるだろう。これらは、ファイアウォールの内と外にそれぞれ配置されるイメージからきている。

　内向けDNSを別に分ける主な目的は、内部用の独自のゾーン情報を設定したい場合だ。イントラネット向けにローカル・ホストは登録するものの、外部には公開したくないなどのニーズを満たせる。つまり、外向けDNSとは異なる独自のゾーン情報（ときには仮想的にルート・ネーム・サーバを構築してドメイン・ツリーも含めて）を保持することになる。また、プライマリ・サーバやセカンダリ・サーバなどを複数台配置してもいい。

　内部向けという意味では、「フルサービス・リゾルバ」「キャッシュ・サーバ」として構築する場合もある。つまり、内部ユーザーのための「リゾルバ・サービス」も考慮しなくてはならない。これについては後ほど述べよう。

　本連載の第2回「インターネットを支えるDNS」で述べたように、ドメインをレジストラなどから取得するに当たって登録機関に通知する必要があるのが、この自身のドメイン名と、外向けのプライマリ・サーバ名やセカンダリ・サーバ名およびIPアドレスだ。上位ドメインのDNSサーバでは、権限委譲のためにゾーン情報へ登録し、ドメイン・ツリーにおいてドメインが認識されることになる。一方、内向けDNSはあくまで内部利用のためのDNSサーバなので、その必要はない。フルサービス・リゾルバから「フォワーダ」などの指定によって検索できるようになっていればよい。

　ここまで、それぞれの機能を別のサーバとして表現したが、組織の規模によってはすべてを1台のサーバで兼ねるという構成も珍しくない。規模がもともと小さいという場合など、近年ではパブリックIPアドレスが必要個数だけ取得できないこともあるからだ。同一のサーバを別々に用意するかどうかの違いはあるが、いずれにせよ、これらの機能を一通り準備することは必要になる。

DNSの重要な概念「ゾーン」と「オーソリティ」

　ドメインにおけるプライマリ・サーバとセカンダリ・サーバには、DNS情報の実体ともいえる重要な概念がある。それが「オーソリティ」だ。

　1つまたは複数のドメインの情報を記載するのがゾーン情報であることは、すでに述べた。ドメイン運用に必要なすべての情報を網羅する。各ドメインは、自身に関するゾーン情報を責任を持ってインターネット全体に告知する必要がある、ということになる。これを自ドメインに対する「オーソリティ（権限）」を持つと表現する。SOAレコードはドメインにおけるオーソリティを記述するレコードである。

　ただし、より正確にはオーソリティを持っていると見なされるのは、上位ドメインのゾーン情報で、そのドメインのDNSサーバとして指定されたサーバ（NSレコードに記載されたサーバ）に限られる。ドメイン・ツリーに参加していないサーバが、いかにその情報を知っていると主張しても、外部からはそれが正しい情報かどうか確認できないからだ。

図2　ゾーン情報を設定してサブドメインを分割する。サブドメインのDNSサーバがそのサブドメインにオーソリティを持つサーバとなる（図をクリックすると別ウィンドウで拡大表示します）

　図2では、「dns1.forum.atmarkit.co.jp」と「dns2.forum.atmarkit.co.jp」の管理するゾーン情報はオーソリティを持っているが、「dns3.forum.atmarkit.co.jp」は持っているとは認められない。

　いい方を変えよう。forum.atmarkit.co.jpドメインのゾーン情報は、最初はすべて「dns1.forum.atmarkit.co.jp」によって生成される。また、atmarkit.co.jpドメインのゾーン情報によれば、「dns1.forum.atmarkit.co.jp」はDNSサーバとして設定されているので、「dns1.forum.atmarkit.co.jp」はforum.atmarkit.co.jpドメインでオーソリティを持つサーバである。また「dns2.forum.atmarkit.co.jp」は、「dns1.forum.atmarkit.co.jp」からゾーン情報を取得し、atmarkit.co.jpドメインでDNSサーバとして設定されているので、やはりオーソリティを持っている。

　しかし「dns3.forum.atmarkit.co.jp」は、同じく「dns1.forum.atmarkit.co.jp」からまったく同じゾーン情報を取得しているものの、atmarkit.co.jpドメインで設定されていないため、オーソリティは持たないのである＊4。一方、あるドメインのセカンダリ・サーバが別のドメインのセカンダリ・サーバでもある、という設定も行える。

図3　1台のサーバで複数ドメインのセカンダリ・サーバを兼ねている例

　図3の例では、このサーバが複数のドメインのオーソリティを持っている。つまり、このサーバは複数のドメインのゾーン情報を管理していることになる。また、1台で複数ドメインのプライマリ・サーバとなることも可能なほか、（実用上の利点はまた別として）ある2台のサーバがそれぞれ一方のドメインのプライマリ・サーバであり、もう一方のドメインのセカンダリ・サーバとなるような複雑な設定も可能だ。

　結局のところ、オーソリティとはあくまでゾーン情報の権威の問題であって、物理的なサーバ配置に依存するものではない。ゾーンのオーソリティという観点からは、権限委譲とは、実はゾーン情報の管理権限を別のサーバ（サブドメインのDNSサーバ）に引き渡し、その「証」に自ドメインのゾーン情報へ記載することであり、ドメインの「信頼の連鎖」とは、ゾーンというデータの信頼連鎖である、と理解いただけるだろう。