DNS の歴史は古く、インターネットの前身である、ARPAnet でネームサービスとして採用されました。それ以前の TCP/IP ネットワークにおける名前解決は、HOSTS.TXT という単なるテキストファイルで行われていました。ネットワーク上のすべてのホスト名と IP アドレスの対応付けをこのファイルに記述し、それをすべてのホストがローカルディスクに保管して、名前解決が必要なときは必ずそのファイルを参照するという単純な仕組みです。しかし、ネットワークに接続されるホストの数が増大し、HOSTS.TXT での一元管理は事実上不可能となりました。そこで登場したのが、分散データベースとも呼べる DNS サービスです。インターネットでは、世界中に存在する無数の IP アドレスとホスト名との対応付けを行わなければなりませんが、これを 1 つのデータベースシステムで管理することは現実的ではありません。 DNS サーバーは、階層構造を持つドメインごとに配置され、お互いに協調することで名前解決を行っています。

ドメインは、.(ルート)ドメインを最上位とするツリー型の構造で管理されています。.(ル ート)ドメインの直下には、jp、cn、com、org などのトップレベルドメインが存在します。jp ドメイン の下には co や gr などのサブドメインが存在し、co の下には、turbolinux などが存在しています。そして、turbolinux というサブドメインにぶら下がる www といったホストをターボリナックス株式会社が管理しています。また、DNS サーバーを管理/構築していく上で必要になるのがゾーンという概念です。ゾーンは、DNS サーバーが管理する名前空間の範囲を意味します。jp というゾーンには、co というサブゾーンが存在し、またその下には、turbolinux というサブゾーンが存在します。そのゾーンごとに DNS サーバーが配置され、そのゾーンを管理します。また、turbolinux の下位に tokyo、osaka といったサブゾーンを作り、そのゾーンを管理する権利をそれぞれの DNS サーバーに委任することもできます。
これらを、.(ドット)で区切って繋げることにより特定のホスト名を指定することができます。www.turbolinux.co.jp のように完全なドメインで指定した名前を FQDN(Fully Qualified Domain Name:完全修飾ドメイン名)と呼びます。こうして、各団体、企業が各ドメインを管理することによって、漏れのない、また世界中で 1 つのホスト名を維持することができます。このように、DNS サービスはインターネット上に存在する数多くの DNS サーバーが協調して動作している世界規模の大規模分散データーベースであり、インターネットを支える重要な骨格となっています。
名前解決のために DNS サーバーに問い合わせを行うクライアントは、リゾルバ(Resolver)と呼ばれます。通常、アプリケーションは、gethostbyname() や gethostbyaddr() などのライブラリ関数を呼び出して、正引きや逆引きによる名前解決の結果を取得します。その際、リゾルバは、以下の 2 つのファイルを参照することにより、名前解決を行います。
名前解決を行う仕組みには、DNS だけでなく、/etc/hosts ファイルを用意する方法もあります。また、NIS を使用することもできます。/etc/hosts による名前解決は、すべてのホストが同じファイルを保持しなければならないため、大きなネットワークでは維持管理の手間が大きく現実的ではありません。しかし、4〜5 台までのホスト数の少ないネットワークでは簡単に名前解決の仕組みを実装できるメリットがあります。以下のように IP アドレスとホスト名の対応を /etc/hosts に記述しておけば、リゾルバはこのファイルから得た結果をアプリケーションに返します。
127.0.0.1 localhost.localdomain localhost 192.168.1.82 www.turbolinux.co.jp www |
このように名前解決の手段にはいくつかの方法があります。/etc/nsswitch.conf は、このように複数存在する名前解決の優先順位を決定するための設定ファイルです。Turbolinux 10 Server の /etc/nsswitch.conf には、以下の行が指定されています。
hosts: files nisplus dns |
この場合、リゾルバはローカルに存在する /etc/hosts による名前解決を試みて、解決できない場合は NIS、次に DNS の順に名前解決を行うことを意味しています。つまり、これらの順番を変更することで名前解決の優先順位を変更することも可能です。
DNS による名前解決が行われる際に参照されるファイルです。/etc/resolv.conf は、ドメイン名と DNS サーバーに関する情報が以下のように記述されています。
nameserver 192.168.0.1 nameserver 192.168.0.2 search turbolinux.co.jp |
nameserver は、使用する DNS サーバーの IP アドレスを指定します。DNS サーバーが複数ある場合は、複数指定することが可能です。search は、ドメイン名の無いホストからの問い合わせの際に補うドメイン名を指定します。
このように、リゾルバは、これらのファイルの内容に従い取得した結果をアプリケーションに渡します。したがって、デフォルトの設定では、アプリケーションからの名前解決要求に対して /etc/hosts ファイルを参照し、名前解決できなかった場合に /etc/resolv.conf を参照し、そこに指定された DNS サーバーへ問い合わせを行います。例えば、リゾルバから www.turbolinux.co.jp の名前解決を求められた場合、DNS サーバーは、以下のようなプロセスを経て、クライアントに結果を返します。

リゾルバは、DNS サーバーに対して www.turbolinux.co.jp の IP アドレスの取得を要求します。要求を受けた DNS サーバーは、. (ルート)サーバーから順に、DNS サービスのツリー構造をたどることによって取得した、目的のホストの IP アドレスをリゾルバに返します。上記は、ホスト名から IP アドレスを取得する正引きの例ですが、IP アドレスからホスト名を取得する逆引きの場合でもその動作原理は同じです。ただし、トップレベルドメインとセカンドレベルドメインは、.in-addr.arpa という特別なドメイン名を使用します。以降のサブドメインは、IP アドレスの各オクテットを逆順に並べたものとなります。
ここで、重要なことは、リゾルバから名前解決を要求された DNS サーバーと、その DNS サーバーから名前解決を要求された DNS サーバーの働きの違いです。前者の DNS サーバーは、クライアントが名前解決を行うために使用される DNS サーバーであり、他の DNS サーバーへ再帰的な問い合わせを行うことにより、完全な結果を取得しようとします。それに対し、名前解決の途中で、この DNS サーバーから問い合わせを受ける DNS サーバーは、他の DNS サーバーに再帰的な問い合わせを行うことはなく、自分が管理しているゾーンデータのみを返している点に注意してください。このように、DNS サーバーは、その役割や機能によって、いくつかのタイプに分かれます。
DNS サーバーは、その役割や機能に応じて以下 3 つのタイプに分類されます。
ゾーンデータベースを持たず、リゾルバからの名前解決の要求に対して、他の DNS サーバーに対して再帰的な問い合わせをするだけのサーバーです。名前の通り、一度あった問い合わせを一定時間キャッシュ(保持)しますので、2 度目からの問い合わせには迅速に応答することができます。
自ドメインに存在するホスト情報の管理、メールサーバーへの転送経路の確保、セカンダリネームサーバーへのゾーンファイルの転送、上位ドメインを管理するネームサーバーとの連携などの役割を持つ重要なサーバーです。キャッシュオンリーサーバーからの問い合わせに対して、自分が管理するドメインのゾーン情報を返します。
プライマリネームサーバーのバックアップ的な存在で、定期的にプライマリネームサーバーからゾーン情報をコピーし、万が一プライマリネームサーバーにトラブルがあった場合の代理として機能します。この目的からして、プライマリサーバーと同じネットワークセグメントにセカンダリサーバーを用意するのはあまり意味がありません。DNS サーバーの構築では、プライマリとセカンダリを最低 1 台ずつ用意することが推奨されています。
DNS サーバーは、複数のタイプを共有してもかまいません。つまり、あるゾーンにおいてはプライマリネームサーバーとして動作し、他のゾーンでは、セカンダリネームサーバーとして動作させることも可能です。DNS サーバーは、タイプによって設定方法が異なります。以下では、各タイプの DNS サーバーを構築する基本的な設定手順について解説します。