第 3 章 ドメインネームシステム (概要)

この章ではドメインネームシステム (DNS) の概要を説明します。

DNS の利用で最も一般的で重要なことは、ネットワークをグローバルなインターネットに接続することです。 インターネットに接続するためには、親ドメインの管理者にネットワークの IP アドレスを登録してもらう必要があります。

この章の内容は次のとおりです。

• DNS の基礎

• サーバーの構成とデータファイルの名前

• ドメイン名

• resolv.conf ファイル

• named.conf ファイル

• ゾーンと DNS

DNS の基礎

ドメインネームシステム (DNS) は、標準 TCP/IP プロトコル群の 1 つのアプリケーション層プロトコルです。 DNS ネームサービスはインターネットで使用されるネームサービスです。

ここでは、DNS の基本的な概念について説明します。 説明に際しては、ネットワークの管理 (特に TCP/IP) に精通していて、NIS+ や NIS といった他のネームサービスについての知識があることを前提とします。

DNS の初期設定と構成については、第 4 章「DNS の管理 (手順)」を参照してください。

DNS、NIS+、NIS、FNS には同じような機能があり、時として異なる構成要素を定義するのに同じ用語を使用している場合がありますが、 この章では、ドメインやネームサーバーといった用語は DNS の機能に合わせて定義しています。

名前のアドレス解決

DNS はインターネット上の複雑で全世界的なコンピュータの階層をサポートしますが、それ自身の基本機能は非常に簡単なものです。 すなわち、DNS が TCP/IP に準拠したネットワークに「名前のアドレス解決」を提供するということです。 名前からアドレスへの解決は「マッピング」ともいい、あるコンピュータのホスト名をインデックスとして用い、その IP アドレスをデータベースから見つけ出す処理のことです。

名前のアドレスマッピングは、ローカルマシンで実行されているプログラムが遠隔コンピュータにアクセスする必要があるときに行われます。 このプログラムでは遠隔コンピュータのホスト名はわかっても、 その場所を特定できません。特に遠隔マシンが別の会社のドメインにある場合には場所を特定できません。 プログラムは遠隔マシンのアドレスを得るために、ローカルマシン上で動作している DNS ソフトウェアに要求を送ります。この時のローカルマシンを「DNS クライアント」と呼びます。

ローカルマシンは、「DNS ネームサーバー」に要求を送ります。DNS ネームサーバーは 分散型 DNS データベースを保持しています。 DNS ファイルは、同様の情報を保持する他のファイルと異なる部分が多くあります。 たとえば、NIS+ host、ipnodes テーブル、ローカルの /etc/hosts および /etc/inet/ipnodes ファイルは、ホスト名、ipnode 名、IPv4 および IPv6 アドレス、その他コンピュータの特定のグループに関する情報を保持します。 ネームサーバーは、遠隔マシンの IP アドレスを検索、すなわち「解決」するために、ローカルマシンのホスト名を使用します。 ホスト名が DNS データベースにある場合、ネームサーバーはこの IP アドレスをローカルマシンに返します。

次の図に、DNS クライアントのローカルネットワーク上で行われる、クライアントとネームサーバー間の名前のアドレスマッピングを示します。

図 3–1 名前のアドレス解決

ホスト名がネームサーバーの DNS データベースになければ、そのマシンは権限の外側にある、すなわち、DNS の用語でいう「ローカル管理ドメイン」の外側にあることを意味します。 このように、各ネームサーバーは、ローカル管理ドメインに対して権限があるとされています。

幸い、ローカルネームサーバーでは、要求の転送先であるルートドメインネームサーバーのホスト名と IP アドレスのリストを保持しています。 ルートネームサーバーは、DNS 階層とインターネットで詳しく説明しているように、大きな組織のドメインに対して権限があります。 その階層は、上下逆のツリー構造で編成された UNIX のファイルシステムに似ています。

各ルートネームサーバーは、指定された組織における最上位のドメインネームサーバーのホスト名とIP アドレスを管理しています。 ルートネームサーバーは、既知の最上位のネームサーバーに要求を送信します。 要求されたホストの IP アドレスをあるネームサーバーが保持している場合、そのサーバーにより情報がローカルマシンに返されます。 最上位のサーバーが要求されたホストを認識しない場合、第 2 レベルのネームサーバーに要求が渡されます。 このようにローカルマシンからの要求は組織の巨大なツリー構造の下へ向かって順に渡されます。 最終的に、ローカルマシンからの要求に関する情報がデータベースに格納されているネームサーバーが IP アドレスを返します。

次の図に、ローカルドメインの外側での名前のアドレス解決を示します。

図 3–2 遠隔ホストに対する名前のアドレス解決

DNS 管理ドメイン

DNS から見ると「管理ドメイン」は 1 つの単位として管理されるマシン群を構成しています。 このドメインに関する情報は、ドメインに対して権限を持つ 2 つ以上のネームサーバーによって管理されます。 DNS ドメインはマシンを論理的にグループ分けしたものですが、 小規模のビジネスにおいて全マシンが Ethernet に接続されている場合のように、ドメインのグループがマシンの物理的グループと対応している場合もあります。 同様に、ローカルの DNS ドメインには、大学の大規模なネットワークのすべてのマシンが入っていることがあります。これらのマシンは、コンピュータサイエンスの学科や管理部門に属しています。

たとえば、Ajax という会社が 2 つのサイトをサンフランシスコとシアトルに持っているとします。 そして、Retail.Sales.Ajax.com. ドメインがシアトルにあり、 Wholesale.Sales.Ajax.com. ドメインがサンフランシスコにあるとします。 また、Sales.Ajax.com. ドメインが 2 つの市に分かれているとします。

各管理ドメインは、固有のサブドメイン名を持たなければなりません。 さらに、ネットワークをインターネットに接続するのであれば、そのネットワークの属する管理ドメインはすでに登録されたものでなければなりません。 ドメイン名とドメインの登録の詳細については、インターネットへの参加 の節を参照してください。

in.named と DNS ネームサーバー

すでに説明したように、管理ドメイン内のネームサーバーは、DNS データベースを保持しています。 また、このネームサーバーは in.named デーモンを実行して DNS サービスを実装します。 in.named は、パブリックドメインの TCP/IP プログラムであり、Solaris オペレーティング環境に含まれています。

in.named は、カリフォルニア大学バークレー校で開発されたデーモンで、Berkeley Internet Name Domain service (BIND) と呼ばれることもあります。

DNS ネームサーバーには、次の 3 種類があります。

• マスターサーバー

• スレーブサーバー

• スタブサーバー

各ドメインには、マスターサーバーが 1 つと、バックアップ用のスレーブサーバーが 1 つ以上必要です。 マスターサーバーとスレーブサーバーの詳細については、DNS の実装の実例 を参照してください。

サーバーの構成とデータファイルの名前

in.named デーモンを正しく機能させるには、1 つの構成ファイルと 4 つのデータファイルが必要です。

構成ファイル

マスターサーバーの構成ファイルは、/etc/named.conf です。このファイルには、ドメイン名と、ホスト情報を含むファイル名が記述されています。 named.conf ファイルの詳細については、named.conf ファイル を参照してください。

DNS データファイルの名前

内部で一貫性が取れていれば、ゾーンデータファイルには何でも好きな名前を付けることができます。 名前の付け方への柔軟性が高いために、他のサイトで作業をしたり、DNS 間連の各種マニュアルを参照する場合に、混乱を招くことがあります。

たとえば、Sun のマニュアルで使われているファイル名は、『DNS and BIND』(Paul Albeltz & Criclcet Liu 著、浅羽登志也／上水流由香監訳 、アスキー出版局、1995年) で使われているファイル名とは異なります。そしてこれら 2 派の命名方法は、『Name Server Operations Guide for BIND』に記載されているパブリックドメインの命名方法とも若干の相違があります。

さらに、本書では、説明にはファイルの主な役割を表す総称名を使い、コード例では具体的な固有の名前を使っています。 たとえば、本書では、ファイルの機能や役割を説明する場合は hosts という総称名を使い、 コード例では db.doc や db.sales といった名前を使っています。

必要なデータファイルは次のとおりです。

• /var/named/named.ca。named.ca ファイルの詳細については、named.ca ファイル を参照してください。 内部で一貫性が取れていれば、このファイルには任意の名前を付けることができます。

• /var/named/hosts。hosts ファイルの詳細については、hosts ファイル を参照してください。

  hosts という名前はファイルの役割や内容を表す総称名です。 ただし、この総称名をそのまま使うと /etc/hosts と紛らわしいので、この種のファイルは hosts 以外の名前にします。 最も一般的な名前の例は、db.domainname です。 たとえば、doc.com ドメインにある hosts ファイルであれば、その名前は db.doc となります。

  ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts ファイルを置き、 各 hosts ファイルには一意の名前を付けなければなりません。 たとえば、doc.com と sales.doc.com に分けられている DNS ドメインであれば、一方の hosts ファイルの名前は db.doc、もう一方の名前は db.sales とします。

• /var/named/hosts.rev。hosts.rev ファイルの詳細については、hosts.rev ファイル を参照してください。

  hosts.rev という名前は、ファイルの役割や中身を表す総称名です。 ドメイン内に複数のゾーンがある場合は、各ゾーンに1 つずつ hosts.rev ファイルを置き、 各ゾーンの hosts.rev ファイルには一意の名前を付けなければなりません。 たとえば、doc.com と sales.doc.com に分けられている DNS ドメインであれば、一方の hosts.rev ファイルの名前は doc.rev 、もう一方の名前は sales.rev とします。

• /var/named/named.local。named.local ファイルの詳細については、named.local ファイル を参照してください。 内部で一貫性が取れていれば、このファイルには任意の名前を付けることができます。

$INCLUDE ファイル

インクルードファイルは、DNS データファイルの中の $INCLUDE() 文で指定された任意のファイルです。 $INCLUDE ファイルを使ってデータを型ごとに別々のファイルに分割しておくと便利です。 $INCLUDE ファイル を参照してください。

参考のため、次の表で上で述べた 3 種類の BIND ファイル名を比較します。

ドメイン名

「ドメイン名」とは、ローカルネットワークの中で DNS 管理ファイルを共有する複数のシステムを 1 つのグループとして扱って、そのグループに付けた名前のことです。 ドメイン名は、ネットワーク情報サービスデータベースが正常に動作するために必要です。

デフォルトのドメイン名

DNS がデフォルトで使用するドメイン名は resolv.conf ファイルに指定されています。

• resolv.conf ファイルが利用できず、ネームサービスが NIS または NIS+ の場合、Sun が実装する DNS はこれらのサービスからデフォルトのドメイン名を取得します。

• NIS も NIS+ も稼動していない場合、 resolv.conf はドメインの指定や LOCALDOMAIN 環境変数の設定を行えません。

ドメイン名の末尾のドットについて

各種 DNS 関連ファイルを使用する場合、ドメイン名の末尾のドットには次のような規則があります。

• hosts、hosts.rev、named.ca、named.local の各データファイルの中では、ファイル名の末尾にドットを付けます。 たとえば、sales.doc.com. は、これらのファイルの中では有効です。

• named.conf ファイル内、または resolv.conf ファイルの中では、ドメイン名の末尾にドットを付けません。 たとえば、sales.doc.com は、これらのファイルの中では有効です。

DNS クライアントとリゾルバ

あるマシンを DNS クライアントにするには、「リゾルバ」を実行する必要があります。 リゾルバはデーモンでも単一のプログラムでもなく、 アプリケーションによって使用される動的ライブラリ関数の集合です。マシン名を知る必要があるときに、このライブラリが使用されます。 リゾルバの機能はユーザーの照会を解決することです。 リゾルバがネームサーバーに照会すると、ネームサーバーは要求された情報か、または他のサーバーに照会する旨を返します。 一度リゾルバを設定すれば、そのマシンはネームサーバーに DNS サービスを要求できるようになります。

DNS ネームサーバーは、いくつかのファイルを使用して、そのデータベースを読み込みます。 リゾルバのレベルでは、要求された情報を格納するサーバーのアドレスを登録するファイル (/etc/resolv.conf) が必要です。 リゾルバは resolv.conf ファイルを読み取り、ローカルドメインの名前とネームサーバーの位置を見つけます。 この resolv.conf ファイルはローカルドメイン名を設定し、 リゾルバルーチンに指示して、登録されたネームサーバーに情報を照会させます。 通常、ネットワーク上の各 DNS クライアントシステムの /etc ディレクトリには、resolv.conf ファイルがあります。 クライアントに resolv.conf ファイルがない場合は、IP アドレス 127.0.0.1 のデフォルトサーバーが使用されます。

リゾルバがホストの IP アドレスまたはアドレスに対応するホスト名を探さなければならないときには、照会パッケージを構築し、/etc/resolv.conf に登録されたネームサーバーにこれを送信します。 サーバーは、その照会にローカルに応答するか、または他のサーバーのサービスを使ってリゾルバに答えを返します。

あるマシンの /etc/nsswitch.conf ファイルで hosts: dns が指定されているか、あるいは hosts 行に dns を含む別のパターンが指定されていると、リゾルバのライブラリが自動的に使用されます。 nsswitch.conf ファイルが dns より前に、他のネームサービスを指定した場合、最初にそのネームサービスに対して問い合わせます。 要求されたホストの情報が見つからなかった場合、リゾルバのライブラリが使用されます。

たとえば、nsswitch.conf ファイル内の hosts の行で hosts:nisplus dns と指定されている場合、ホストの情報を得るために NIS+ ネームサービスが最初に検索されます。 NIS+ で情報が見つからない場合は、DNS リゾルバが使用されます。 スイッチファイルに hosts:nisplus dns 行を指定すると、ローカルホストの情報に対しては NIS+ が使用され、遠隔ホストの情報に対しては DNS が使用されることになります。

DNS クライアントには、次の 2 種類があります。

• クライアント専用

  クライアント専用の DNS クライアントは in.named を実行せず、 代わりにリゾルバを参照します。 リゾルバはドメインに対するネームサーバーのリストを保持しているので、リゾルバに問い合わせが転送されます。

• クライアント兼サーバー

  クライアント兼サーバーの DNS クライアントは、クライアントマシンのリゾルバによって転送されてきた問い合わせを解決するために in.named で提供されるサービスを使用します。

resolv.conf ファイル

resolv.conf ファイルの機能については、resolv.conf(4) のマニュアルページを参照してください。

resolv.conf ファイルの設定方法については、resolv.conf ファイルの設定を参照してください。

named.conf ファイル

BIND 8.1 では、新たに構成ファイル /etc/named.conf が追加され、 /etc/named.boot ファイルと置き換えられました。 /etc/named.conf ファイルは、マスター、スレーブ、キャッシュ専用のネームサーバーを確立します。 また、named.conf はサーバーが権限を持つゾーンを指定し、どのデータファイルから初期データを取得するかを指定します。

/etc/named.conf ファイルには、次の機能を実装するための文が含まれます。

• アクセス制御リスト(ACL) によるセキュリティ。このリストには、NIS+ ホストが読み取り権と書き込み権を持っている IP アドレスの集まりが定義されている

• ロギング動作の指定

• すべてのゾーンにではなく、ゾーンのセットに対して選択的に適用されるオプション

この構成ファイルは、サーバーの起動スクリプト /etc/init.d/inetsvc によってデーモンが起動されるとき、 in.named によって読み取られます。 そして、in.named が他のサーバーや、指定されたドメインのローカルデータファイルに対して実行されるようにします。

named.conf ファイルは、いくつかの文とコメントで構成されています。 文はセミコロンで終わります。 一部の文には、文のブロックを記述することができます。 ブロック内の各文もセミコロンで終わります。

例 3–1 マスターサーバー用のマスター構成ファイルの例

options {
         directory "/var/named";
         datasize 2098;
         forward only;
         forwarders {
                  99.11.33.44;
         };
         recursion no;
         transfers-in 10;
         transfers-per-ns 2;
         allow-transfer {
                  127.0.1.1/24;
         };
};
 
logging {
         category queries { default_syslog; };
};
 
include "/var/named/abcZones.conf"
 
 
// here are the names of the master files
zone "cities.zn" {
         type master;
         file "db.cities.zn";
};
 
zone "0.0.127.in-addr.arpa" {
         type master;
         file "db.127.cities.zn";
};
 
zone "168.192.in-addr.arpa" {
         type master;
         file "db.cities.zn.rev";
};
 
zone "sales.doc.com" {
         type slave;
         file "slave/db.sales.doc";
         masters {
                  192.168.1.151;
         };
};
 
 
zone "168.192.in-addr.arpa" {
	         type slave;
         file "slave/db.sales.doc.rev";
         masters {
                  192.168.1.151;
         };
};

ローカルドメイン内の DNS 階層

大規模な会社であれば、複数のドメインをサポートしており、ローカルな名前空間が構成されていることでしょう。 次の図に、ある会社に存在するドメインの階層構造の例を示します。 最上位のドメイン、すなわちルートドメインは、ajax.com で、 その下に sales.ajax.com、test.ajax.com、manf.ajax.com の 3 つのサブドメインがあります。

図 3–3 ある組織での DNS ドメインの階層

DNS クライアントは、そのドメインをサポートしているサーバーに対してのみサービスを要求します。 クライアントの必要としている情報がそのドメインサーバーにない場合、要求は親サーバーに転送されます。 親サーバーは、1 つ上の階層のドメインに存在します。 要求が最上位のサーバーに達した場合、最上位のサーバーはクライアントのドメインが有効かどうか調べます。 ドメインが有効でない場合、サーバーは「not found」というメッセージをクライアントに返します。 ドメインが有効な場合、最上位のサーバーはそのドメインをサポートしているサーバーに要求を転送します。

DNS 階層とインターネット

次の図に示したドメインの階層は、グローバルなインターネット上でサポートされる巨大な DNS 名前空間の「枝葉」のようなものです。

それは、ドット (.) で表されるルートディレクトリと、最上位のドメインの階層 2 つ (組織的なものと地理的なもの) で構成されます。 次の図の com ドメインは、インターネットに存在する最上位の組織ドメインの 1 つです。

図 3–4 インターネットのドメインの階層

現在、組織的な階層の名前空間は、次の表に示した最上位のドメインに分けられます。 将来、これ以外にも最上位の組織ドメインが追加される可能性があります。

地理的な階層においては、各国に対して2、3 文字の識別子が割り当てられ、 それが、各国に対する公式名として用いられます。 たとえば、イギリス国内のドメインは、uk という最上位のドメインのサブドメインになります。日本国内のドメインは、jp のサブドメインで、他の国に関しても同様です。

インターネットへの参加

インターネットのルートドメイン、すなわち地理的および組織的に最上位のドメインは、様々なインターネット運営体によって管理されています。 規模にかかわらずネットワークを有する人は、そのネットワークのドメイン名を組織的な階層か地理的な階層に登録することによってインターネットに参加できます。

DNS ドメインはドメイン名を持つ必要があります。 インターネットに接続しないで、ネームサービスとしてDNS を使用する場合は、ドメインやサブドメインに任意の名前を付けることができます。 ただし、インターネットに参加する場合は、そのドメイン名をインターネット運営体に登録する必要があります。

インターネットに参加する場合は、次の手順に従います。

• DNS ドメイン名を、適切なインターネット運営体に登録する

• そのインターネット運営体から、ネットワークの IP アドレスを入手する

  上記のことを行うには、次の 2 つの方法があります。

  • 適切なインターネット運営体またはその代理団体と直接連絡をとる方法

  • インターネットサービスプロバイダ (ISP) と契約する方法。 ISP は、コンサルティングから実際の接続まで広範なサービスを提供している

DNS 名前空間でのドメイン名

ドメイン名は、DNS 名前空間全体でのドメインの位置を表します。それは UNIX のファイルシステムでパス名がファイルの位置を表しているのと同じです。 ローカルドメインが登録されると、そのドメイン名は所属するインターネットの階層の名前に追加されます。 たとえば、図 3–5 で示した Ajax ドメインはインターネットの階層である com の一部として登録されました。 したがって、そのインターネットドメイン名は ajax.com となります。

次の図に、ajax.com ドメインがインターネット上の DNS 名前空間のどこに位置しているのかを示します。

図 3–5 DNS 名前空間における Ajax ドメインの位置

ajax.com のサブドメインには以下のような名前があります。

sales.ajax.com
test.ajax.com
manf.ajax.com

DNS ではドメイン名を大文字にすることは可能ですが、必須ではありません。 次に、マシン名とドメイン名の例を挙げます。

boss.manf.ajax.com
quota.sales.ajax.com

インターネット運営体は、各ドメインにホスト名に関する権限を与えます。 各ドメインには、それ以下のレベルの権限が委任されます。 したがって、com ドメインはそのドメイン内のホスト名に対して権限があります。 また、運営体は、ajax.com ドメインの編成について権限を与え、そのドメイン内の名前に対する権限を委任します。 それを受けて ajax.com はドメイン内のホストに名前を割り当て、 sales.ajax.com、 test.ajax.com、manf.ajax.com の各ドメインの編成を承認します。

完全指定ドメイン名 (FQDN)

ドメイン名にローカルドメインから DNS のルートドメイン (.) までのすべての DNS のドメインが含まれているとき、そのドメイン名は「完全指定されている」といいます。 概念的には、完全指定ドメイン名は、UNIX ファイルの絶対パス名と同様に、ルートへのパスを示しています。 しかし、完全指定ドメイン名を読む場合、左から右に進むにしたがって最下位から最上位となります。 したがって、完全指定ドメイン名は次のような構文になっています。

ajax ドメインとそのサブドメインの完全指定ドメイン名は、次のとおりです。

ajax.com. 
sales.ajax.com. 
test.ajax.com. 
manf.ajax.com.

ここで、各名前の一番右に付けられたドット (.) に注意してください。

ゾーンと DNS

ドメインの DNS サービスは、ネームサーバーの集合で管理されます。 ネームサーバーは、単一のドメイン、複数のドメイン、あるいは複数のドメインとその下のサブドメインを管理できます。 ネームサーバーによって管理される名前空間の一部は、「ゾーン」と呼ばれます。 したがって、ネームサーバーはゾーンに対して権限があるといわれます。 ネームサーバーの責任者は、「ゾーン管理者」とも呼ばれます。

ネームサーバーのデータベース内のデータは、「ゾーンファイル」と呼ばれます。 ゾーンファイルの 1 つには、IP アドレスとホスト名が格納されています。 ftp または telnet のようなユーティリティでホスト名を用いて遠隔ホストに接続しようとすると、 DNS は名前のアドレスマッピングを実行し、 ゾーンファイルの中でホスト名を探して、IP アドレスに変換します。

図 3–6 ドメインとゾーン

たとえば、上の例で示した Ajax ドメインは、最上位のドメイン (Ajax) 、4 つのサブドメイン、そして 5 つのサブサブドメインから構成されます。 このドメインは、4 つのゾーンから構成されます。 したがって、Ajax ネームサーバーは、Ajax、Sales、Retail、Wholesale の各ドメインから成るゾーンを管理します。 Manf と QA の両ドメインは、ゾーンであり、自分自身のネームサーバーからサービスを受けます。 Corp ネームサーバーは、Corp、Actg、Finance、Mktg ドメインから成るゾーンを管理します。

逆マッピング

DNS データベースには、IP アドレスを使用してマシンのホスト名を見つけだすゾーンファイルもあります。このファイルで IP アドレスのホスト名解決が可能になります。 このプロセスを、「逆解決」または、より一般的には「逆マッピング」と呼びます。 逆マッピングは基本的にはメッセージを送ってきたマシンの識別情報を確認したり、ローカルホスト上での遠隔操作を許可したりするために使用されます。

in-addr.arpa ドメイン

in-addr.arpa ドメインとは、DNS 名前空間において概念的な存在で認証 (許可) のためにドメインでなく IP アドレスを用います。 このドメインは、ゾーンの一部ですが、これによってアドレスから名前のマッピングが可能になります。

in-addr.arpa ドメインでは、IP アドレスは最下位のレベルからルートになるように理解されます。 すなわち、IP アドレスは逆転します。 たとえば、あるホストの IP アドレスが 192.168.21.165 であるとします。 in-addr.arpa ゾーンファイルでは、そのアドレスは 165.21.168.192.in-addr.arpa. と記述されます。ここで最後のドットは、in-addr.arpa ドメインのルートを示しています。