Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)

パート II DNS の設定と管理

ここでは、Solaris オペレーティング環境における DNS ネームサービスの設定、構成、管理、障害追跡について説明します。

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

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

注 –

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

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

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 クライアントがリモートネットワーク上の一連のサーバーにホストデータを送信して、対象となるネームサーバーが IP アドレスを返すまでを示しています。

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 ファイル名を比較します。

表 3–1 ファイル名の例


Solaris	O'Reilly / その他	カリフォルニア州立大学バークレイ校	ファイルの内容と役割
`/etc/named.conf` (全て同じファイル名)			BIND 8.1 では新たに `named.conf` ファイルを追加して、従来の `named.boot` ファイルと置きかえる。この構成ファイルにはセキュリティ、スタートアップオプション、ロギングが追加されている。このファイルによって、稼動中のサーバーの種類を指定する。このファイルによってすべてのゾーンまたはサーバーではなく、ゾーンごとまたはサーバーごとにオプションが選択的に適用される。このファイルには、ドメイン名とデータファイル名のリストが含まれる
`/etc/resolv.conf` (全て同じファイル名)			各クライアント (DNS サーバーを含む) 上に存在するファイル。DNS 情報を探すためにクライアントが照会するサーバーを示す
`named.ca`	`db.cache` `db.root`	`root.cache`	ルートサーバー名とそのアドレスがリストされている
総称名: `hosts` 例: `db.doc`、`db.sales`	総称名: `db.domain` 例: `db.movie`、`db.fx`	総称名: `hosts` 例: `ucbhosts`	サーバーがサービスを提供するローカルゾーン内のマシンに関する全データが格納されている
総称名: `hosts.rev` 例: `doc.rev`	総称名: `db.ADDR` 例: `db.192.249.249 db.192.249.253`	`hosts.rev`	逆マッピング (アドレスから名前) を行うための特殊なドメイン `in-addr.arpa.` のゾーンを指定する
`named.local`	総称名: `db.cache` 例: `db.127.0.0`	`named.local`	ローカルループバックインタフェース (ローカルホスト) 用のアドレスを指定する
`$INCLUDE` 全てで同じ規則			データファイル内の `$INCLUDE()` 文によって指定されるファイル

ドメイン名

「ドメイン名」とは、ローカルネットワークの中で 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–2 named.conf で使用する文


文	説明
`acl`	アクセス制御に使用する、IP アドレスの一致リストを名前を付けて定義する。アドレスの一致リストは、1 つ以上の IP アドレス(ドット形式の 10 進表記) または IP 接頭辞 (ドット形式の 10 進表記の後にスラッシュとネットマスクのビット数が付く) を示す。名前を付けたIP アドレスの一致リストは、アドレスを他の場所で使用する前に `acl` 文で定義されている必要がある。前方参照は不可
`include`	`include` 文がある箇所にインクルードファイルを挿入する。 `include` を使用することで、管理しやすいまとまりに構成情報を分割することができる
`key`	特定のネームサーバーでの認証と承認に使用される鍵の ID を指定する。 `server` 文を参照
`logging`	サーバーが記録するログの種類とログメッセージの送り先を指定する
`options`	グローバルなサーバー構成のオプションを制御して、他の文に対するデフォルト値を設定する
`server`	遠隔ネームサーバーに関して、指定された構成オプションを設定する。すべてのサーバーに対してではなく、サーバーごとにオプションを適用する
`zone`	ゾーンを定義する。すべてのゾーンに対してではなく、ゾーンごとにオプションを適用する

例 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 ドメインの階層例として、Sales、Test、および Manf というサブドメインを持つ Ajax.com ドメインを示しています。

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

DNS 階層とインターネット

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

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

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

この図は、インターネットの最上位のドメイン構造を組織的な階層と地理的な階層で示しています。

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

表 3–3 インターネットの組織ドメイン


ドメイン	目的
`com`	営利団体
`edu`	教育機関
`gov`	行政機関
`mil`	軍事組織
`net`	ネットワークサポートセンター
`org`	非営利団体
`int`	国際組織

地理的な階層においては、各国に対して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 ドメインの位置

この図は、全世界的な DNS 名前空間での .com のサブドメインとして 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 ドメインとゾーン

この図は、4 つのサブドメインと 5 つのサブサブドメイン (これらは 4 つのゾーンに分かれている) から構成された Ajax ドメインを示しています。

たとえば、上の例で示した 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 ドメインのルートを示しています。

第 4 章 DNS の管理 (手順)

この章では、DNS (Domain Name System) の管理方法について説明します。

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

`resolv.conf` ファイルの設定

ここでは、doc.com ドメインのサーバーで使用する簡単な resolv.conf ファイルの例を示します。

例 4–1 DNS サーバー用 `resolv.conf` ファイルの例

;
; /etc/resolv.conf file for dnsmaster (sirius)
;
domain             doc.com
nameserver         192.168.0.0
nameserver         192.168.0.1

このファイルの最初の行では、ドメイン名を次の書式で指定します。

domain domainname

ここで、domainname は InterNIC (日本では JPNIC) に登録されている名前です。

注 –

ドメイン名の末尾にスペースまたはタブを使うことはできません。ドメイン名の最後の文字を入力したら、必ずキャリッジリターンで強制改行してください。

2 行目には、サーバーを次の書式で指定します。

nameserver 192.168.0.0

以降の行では、スレーブ DNS ネームサーバーまたはキャッシュ専用ネームサーバーの IP アドレスを 1 つ以上指定します。リゾルバはこれらの行を照会して該当するアドレスを識別します。各行の書式は次のとおりです。

nameserver IP_address

IP_address には、スレーブ DNS ネームサーバーまたはキャッシュ専用ネームサーバーの IP アドレスを指定します。リゾルバは、必要な情報が見つかるまで、ここに指定されている順番どおりにネームサーバーを探していきます。

BIND 8.3.3 では、DNS クライアントは IPv6 トランスポートを使用して IPv6 DNS サーバーに接続できます。このような接続を有効にするには、resolv.conf ファイルの nameserver の後に、IPv6 アドレスを入力します。

IPv6 ネームサーバーを使用する /etc/resolv.conf ファイルの例を次に示します。

domain			doc.com
nameserver			2000::100:a00:20ff:de8a:643a
nameserver			2000::55:a00:20ff:dec1:5ade
nameserver			192.168.0.1

resolv.conf ファイルでは、ネームサーバーの IPv4 アドレスと IPv6 アドレスを任意に組み合わせて使用できます。

DNS 用ネットワークの構成

DNS 用のネットワークを構成する場合は、クライアントとサーバーを設定する必要があります。

DNS クライアントの設定

DNS サーバーを設定する前に、クライアントを設定します。

スーパーユーザーになります。

/etc/resolv.conf ファイルを作成します。

次に、doc.com ドメインのクライアント (非サーバー) マシン用の簡単な resolv.conf ファイルの例を示します。

例 4–2 `resolv.conf` ファイルの例

; Sample resolv.conf file for the machine polaris
domain doc.com
; try local name server
nameserver 127.0.0.1
; if local name server down, try these servers
nameserver 2000::16:a:a00:20ff:de8a:643a
nameserver 192.168.16.7
; sort the addresses returned by gethostbyname(3c)
sortlist
130.155.160.0/255.255.240.0
130.155.0.0

/etc/resolv.conf ファイルの最初の行では、ドメイン名を次の書式で指定します。

domain domainname

ここで、domainname は InterNIC (日本では JPNIC) に登録されている名前です。

注 –

2 行目では、ネームサーバーを次の書式で指定します。

nameserver 127.0.0.1

以降の行では、DNS マスターネームサーバー、DNS スレーブネームサーバー、またはキャッシュ専用ネームサーバーの IP アドレスを最大 3 つまで指定します。リゾルバはこれらの行を照会して該当するアドレスを照会します。マスターサーバーまたはスレーブサーバーを 4 つ以上指定することはできません。各行の書式は次のとおりです。

nameserver IP_address

IP_address には、マスターDNS ネームサーバーまたはスレーブ DNS ネームサーバーの IP アドレスを指定します。 IP_address には、IPv4 または IPv6 アドレスを指定できます。リゾルバは、必要な情報が見つかるまで、ここに指定されている順番どおりにネームサーバーを探していきます。

/etc/resolv.conf ファイルの 5 行目では、アドレス sortlist を次の書式で指定します。

sortlist
addresslist

addresslist は、gethostbyname() によって戻されるアドレスのソート順序を示します。上記の例では、gethostbyname は、IP アドレス 130.155.0.0 より先に 1 組のネットマスク 130.155.160.0/ 255.255.240.0 を戻します。

/etc/nsswitch.conf ファイルを変更します。

「NIS」。エンタープライズレベルで主として使っているネームサービスが NIS で、設定に問題がない場合、DNS はすでに使用可能になっています。

「ファイルベース」。エンタープライズレベルで主として使っているネームサービスが /etc ファイルベース、または NIS+ の場合は、次の手順に従います。
1. /etc/nsswitch.conf ファイルをオープンします。
2. DNS は、ホスト情報のソースとして、「唯一の」ソースとしても「追加の」ソースとしても使用できます。 hosts を見つけ、次のように DNS を使用します。
  hosts: files dns
  または、
  hosts: nis dns [NOTFOUND=return] files
  または、
  hosts: dns nis [NOTFOUND=return] files
  NIS クライアントの場合は、上記の指定をしないでください。この指定をすると、名前を見つけることができない場合に 2 度 DNS から検索することになります。
3. ホスト情報のソースとして DNS を指定します。
4. ファイルを保存してリブートします。

DNS サーバーを設定する方法

スーパーユーザーになります。

サーバーを DNS クライアントとして設定します。これには、サーバーの resolv.conf ファイルの設定も含まれます。詳細については、DNS クライアントの設定を参照してください。

構成ファイルを設定します。詳細については、構成ファイルの例を参照してください。

データファイルを設定します。次の 4 つのデータファイルを設定する必要があります。
- named.ca
- hosts
- hosts.rev
- named.local

サーバーの初期設定を行います。詳細については、サーバーの初期設定を行う方法を参照してください。

サーバーをテストします。詳細については、インストール結果を確認する方法を参照してください。

注 –
DNS の最も一般的な役割は、ローカルなネットワークをインターネットに接続することです。インターネットに接続するためには、親ドメインの管理者にネットワークの IP アドレスを登録してもらう必要があります。管理者は、ネットワークの地理的な位置と親ドメインの種類によって異なります。ドメイン管理者にネットワークを登録してもらう方法については、本書では説明をしていません。

マスターサーバーを指定する方法

マスターサーバーには、次の 2 つの種類があります。

「ゾーンマスターサーバー」。各ゾーンには、そのゾーンの「マスター」サーバーが 1 つあります。ゾーンのマスターサーバーは、そのゾーンの「正規」サーバーです。
「ゾーンスレーブサーバー」。ゾーンには、1 つ以上の「スレーブ」マスターサーバーがあります。「スレーブ」マスターサーバーは、その DNS データをゾーンのマスターサーバーから入手します。

サーバーをある特定のゾーンのマスターサーバーに指定する場合は、そのサーバーの named.conf ファイルに以下の文を追加します。

ゾーンファイル用のディレクトリを作成します。

次の行は、指定されたディレクトリ内でゾーンデータファイルを探すように DNS ネームサーバーに指示します。このディレクトリは、スーパーユーザーの所有とし、権限を 0700 に設定することが推奨されます。また、このディレクトリが、ネームサーバー起動時にネームサーバーからアクセスできるファイルシステム上に存在することが推奨されます。
options { directory "/var/named"; };
オプションセクション内の文はグローバルに適用可能な構成オプションであり、ネームサーバーのデフォルトです。詳細は、named.conf(4) のマニュアルページを参照してください。

ゾーンのマスターレコードを作成します。

以下の行は、DNS ネームサーバーをゾーンのマスターサーバーとして指定します。ゾーン定義は、キーワード zone で始まり、ドメイン、クラスの順に続きます。 in はインターネットクラスを意味します。これはデフォルトであるため省略できます。このレコードは、ゾーンに対する権限をサーバーに与える SOA (Start of Authority、権限の開始) レコードの場所もサーバーに示します。ファイル db.doc.sun.com は、オプション文で指定されたディレクトリに存在しなければなりません。
zone "doc.sun.com" in { type master; file "db.doc.sun.com"; };

ゾーンの逆マッピング用のマスターレコードを作成します。

以下の行は、サーバーをゾーンの逆アドレスマッピングのマスターサーバーとして使うことを指定します。逆アドレスゾーンは、そのゾーンにおける IP アドレスを逆にならべ、in-addr.arpa がこれに続きます。たとえば、doc.sun.com ゾーンの IP アドレスが 10.0.0 だとします。この場合、逆アドレスゾーンは 0.0.10.in-addr.arpa になります。
zone "0.0.10.in-addr.arpa" in { type master; file "db.10.0.0"; };

ローカルループバックインタフェースのマスターレコードを作成します。

次の行は、サーバーをループバックインタフェースのマスターサーバーとして指定します。

注 –
ループバックホストは常に、0.0.127.in-addr.arpa で識別されます。

次に示す構成ファイルの行は、そのサーバーをループバックホストの逆アドレスドメインでマスターサーバーとして使い、正規の hosts ファイルとして named.local を使うことを示すものです。
zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; };

ルートのヒントとなるファイルを作成します。
zone "." in { type hint; file "named.ca"; };
ファイル named.ca には、ルートゾーンのネームサーバーの場所が記述されています。上記の doc.sun.com ゾーンの場合、これは sun.com ドメインのネームサーバーです。

スレーブサーバーを指定する方法

「スレーブ」サーバーは、ゾーンに関するデータのコピーを保持しています。マスターサーバーはそのデータをスレーブサーバーに送り、権限を任せます。クライアントは、DNS 情報をスレーブサーバーに照会できます。スレーブサーバーを使用することによって、負荷が複数のマシンに分散され、応答時間を短縮することができます。スレーブサーバーは、マスターサーバーがクラッシュしたときのバックアップも提供します。

in.named の起動時に、デーモンは所定のゾーンに関するすべてのデータをマスターサーバーに要求します。その後、マスターサーバーがデータベースを更新する必要があるかどうかを調べるため、スレーブサーバーはマスターサーバーを定期的にチェックします。最新のゾーンデータベースをマスターサーバーからスレーブサーバーに送信するプロセスを「ゾーン転送」と呼びます。このため、スレーブサーバー上のデータファイルを変更するのではなく、ゾーンのマスターサーバー上のデータファイルを変更します。その後、スレーブサーバーのファイルがマスターサーバーから更新されます。

サーバーを所定のゾーンのスレーブサーバーに指定する場合は、そのサーバーの named.conf ファイルにスレーブレコードを作成します。別々のレコードで、サーバーをそのゾーン、逆アドレスドメイン、およびループバックホストのスレーブサーバーとして指定できます。スレーブゾーン定義の書式は、マスターゾーン定義と似ています。 type が slave に変わり、キーワード masters の行がマスターサーバーの IP アドレスと共に加えられます。

次に示す構成ファイルの行は、サーバーを doc.sun.com ゾーンとその逆アドレスドメインのスレーブサーバーとして使うことを示します。これらの行は、スレーブサーバーがその正規データを 172.16.0.1 のマスターサーバーから取得し、初めにそのデータをファイル tmp.db.doc.sun.com から読み込むことも指定します。

zone "doc.sun.com"   in   {
       type slave;
       file "tmp.db.doc.sun.com";
       masters { 172.16.0.1; };
};

注 –

1 台のサーバーは、1 つまたは複数のゾーンのマスターサーバーとして機能でき、さらに 1 つまたは複数のゾーンのスレーブサーバーとしても機能できます。構成ファイル内のエントリの組み合わせによって、サーバーが指定したゾーンのマスターサーバーになるかスレーブサーバーになるかが決まります。

キャッシュ専用 (スタブ) サーバーを指定する方法

DNS データのキャッシュを保持するという意味では、すべてのサーバーがキャッシュサーバーであるといえます。キャッシュ専用 (スタブ) サーバーは、in-addr.arpa. ドメインの逆ループバックゾーン以外のどのゾーンのマスターサーバーでもないサーバーです。

キャッシュ専用サーバーは照会を行いますが、正規データそのものは一切保持しません。キャッシュ専用サーバーは、named.ca ファイルにリストされているホストに必要な情報を問い合わせることによって照会を行います。

次に、キャッシュ専用サーバーの構成ファイルの例を示します。クラス (in) はデフォルトであるため省略されています。

例 4–3 キャッシュ専用サーバーのマスター構成ファイルの例

;
; Sample named.conf file for caching only name server
;

options {
        directory "/var/named";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "db.127.0.0";
};

zone "." {
        type hint;
        file "named.ca";
};

DNS 互換性と +/- 構文

この節では、マスターネームサービスとして NIS または NIS+ を使用する場合に、+/- 構文を使用する方法について説明します。

+/- 構文との DNS 互換性を追加する方法

スーパーユーザーになります。

/etc/nsswitch.conf ファイルをオープンします。

passwd と groups の各ソースを compat に変更します。
- NIS を使う場合は次のように入力します。
  passwd: compat group: compat
- NIS+ を使う場合は次のように入力します。
  passwd: compat passwd_compat: nisplus group: compat group_compat: nisplus
これにより Solaris 1.x リリースと同じ構文を使用できます。ファイル内の +/- エントリに従って、/etc ファイルと NIS マップ (または NIS+ テーブル) を検索します。

-+ または -+ netgroup を /etc/passwd、/etc/shadow、/etc/group の各ファイルに追加します。

注 –
-+ または -+ netgroup のエントリを /etc/shadow および /etc/passwd に必ず追加してください。追加しないと、ログインできません。

ファイルを保存して、システムをリブートします。

ライブラリ関数の中には、nsswitch.conf ファイルが更新されたかどうかをチェックしないものがあります。このため、マシンをリブートして、これらの関数が最新情報を保持するようにする必要があります。

DNS サーバーの設定

サーバーの初期設定を行う方法

サーバーの初期設定を行う場合は、次の手順に従います。

スーパーユーザーになります。

前出の節の説明に従って、named.conf 構成ファイルとその他必要なファイルをインストールします。

in.named を実行します。

#/usr/sbin/in.named

コマンド行から in.named を実行する代わりに、リブートするという方法もあります。

インストール結果を確認する方法

構成ファイルとデータファイルを設定し、in.named を実行したら、インストールが正しく行われたかどうかを確認してください。

スーパーユーザーになります。

syslog ファイルをオープンして、エラーメッセージが書き込まれていないかどうか確認します。

一般的な DNS エラーメッセージと障害追跡情報については、第 6 章「DNS の障害追跡 (参照情報)」を参照してください。

nslookup コマンドを使用して、ローカルドメインのホスト名を検索します。
dnsmaster% nslookup altair Server: dnsmaster.doc.com Address: 192.146.168.5 Name: altair.doc.com Address: 192.146.168.10
- 検索が正常に実行できれば、ネームサーバーは正常に機能していると推定されます。
- 「Can't find」、「can't initialize address」、または「non-existent domain 」といったメッセージが表示された場合は、サーバーが構成ファイルまたは hosts ファイルに正しく設定されていない可能性があります。
- 「can't find name」または「non-existent domain」といったメッセージが表示された場合は、ホストがサーバーの hosts ファイルに記述されていないか、 resolv.conf 内でドメインが適切に設定されていない可能性があります。また、このエラーメッセージは、サーバーの一般的な問題を示す場合もあります。

nslookup を実行して遠隔ドメイン名を検索します。

インターネットに接続されているネットワークの場合、遠隔ドメイン名を検索します。インターネットに接続されていないネットワークの場合は、他のゾーンにサブドメインがあれば、その名前を検索します。

たとえば、インターネット上の遠隔ドメイン名 internic.net を検索するには、次のように入力します。
dnsmaster% nslookup internic.net Server: dnsmaster.doc.com Address: 192.168.168. Name: internic.net Addresses: 192.168.0.9, 192.168.0.6, 192.168.0.5, 192.168.0.8
- 正常に実行できれば、ネームサーバーはおそらく正常に機能しています。
- 上記のコマンドを実行しても遠隔ドメイン名が表示されない場合は、ネットワーク接続を確認してください。
- あるいは、named.ca ファイルが正しくインストールまたは設定されていないことも考えられます。
もう一度 nslookup を使用してドメインを検索すると、「non-authoritative 」というメッセージが出るはずですが、これは無視してかまいません。 2 回目の実行で、遠隔ネームサーバーからではなく、キャッシュから応答が来ているからです。

遠隔ドメインから自分のドメインのホスト名を検索します。

インターネットに接続されているネットワークの場合、遠隔ドメインから自分のドメインのホスト名を検索します。インターネットに接続されていないネットワークの場合は、他のゾーンから自分のドメインのホスト名を検索します。

たとえば、インターネット上の遠隔ドメインから自分のドメインにあるホスト名を検索するには、nslookup コマンドに続けて、引数を 2 つ指定します。 1 つめの引数はホスト名です。 2 つめの引数は nslookup を実行するネームサーバーの名前です。
remotemachine9% nslookup altair remotemaster.foo.org. Server: remotemaster.foo.org Address: 192.168.0.1 Name: altair.doc.com Addresses: 192.168.1.2
- 正常に実行できれば、ネームサーバーはおそらく正常に機能しています。
- 上記のコマンドを実行しても探しているマシンが見つからない場合は、ドメインが正しく登録されていない可能性があります。

サーバーの追加

ネットワークにマスターサーバーやスレーブサーバーを追加できます。

スーパーユーザーになります。

DNS クライアントとしてサーバーを設定します。詳細は、クライアントの追加を参照してください。

構成ファイルと、構成ファイル内に指定されているゾーンデータファイルの設定を行います。

詳細については、DNS サーバーの設定を参照してください。

DNS データファイルの変更

DNS マスターサーバー内のいずれかの DNS データファイルを修正する場合は、常に以下の操作も実行してください。

スレーブサーバーがそのデータを変更するように、SOA リソースレコードのシリアル番号を変更します。 SOA のシリアル番号を変更する方法を参照してください。
データファイルを再度読み込んで内部データベースを更新するようにマスターサーバーの in.named に情報を与えます (in.named に DNS データを強制的に再度読み込ませる方法を参照)。

`SOA` のシリアル番号を変更する方法

すべての DNS データベースファイルには権限の開始 (SOA) リソースレコードがあります。 DNS データベースのデータを変更したときは必ず、SOA シリアル番号を 1 増加させる必要があります。

たとえば、データファイルの SOA のシリアル番号が現在 101 で、ファイルのデータに変更を加えた場合は、シリアル番号を 101 から 102 に変更する必要があります。 SOA のシリアル番号を変更しないと、ドメインのスレーブサーバーは新しい情報でデータベースファイルのコピーを更新しません。その結果、マスターサーバーとスレーブサーバーが同期しなくなります。

hosts ファイル例の一般的な SOA レコードは、以下のとおりです。

$TTL 5h
; sample  hosts  file
@	IN       SOA 	nismaster.doc.com. root.nismaster.doc.com. (
			109 ; Serial
			10800 ; Refresh
 	                1800 ; Retry
			3600000 ; Expire
			86400 ) ; Minimum

このため、hosts ファイルを変更すると、シリアル番号を 109 から 110 に変更して、次にファイルを変更した場合、110 から 111 に変更します。

`in.named` に DNS データを強制的に再度読み込ませる方法

in.named が無事起動すると、デーモンはそのプロセス ID を /etc/named.pid ファイルに書き込みます。 in.named で named.conf を再び読み込み、データベースを再度読み込ませる場合は、次の手順に従います。

スーパーユーザーになります。

# kill -HUP `cat /etc/named.pid`

この操作によって、以前のキャッシュはすべて削除され、キャッシュの処理が再スタートします。

注意 –

inetd から in.named を実行しないでください。これを行うとネームサーバーは繰り返し再起動され、キャッシュを持つ意味がなくなります。

クライアントの追加と削除

クライアントを追加または削除するときは必ず、DNS マスターサーバーに格納されたデータファイルを変更してください。スレーブサーバーのファイルは編集しないでください。 SOA シリアル番号を変更すると、ファイルはマスターサーバーから自動的に更新されます。

クライアントの追加

DNS ドメインにクライアントを追加するには、新しいマシンを DNS クライアントとして設定してから、新しいマシンのレコードを該当する hosts と hosts.rev の各ファイルに追加します。

たとえば、rigel というホストを doc.com ドメインに追加する場合は、次の手順に従います。

スーパーユーザーになります。

/etc/resolv.conf ファイルを rigel 上に作成します。

rigel の /etc/nsswitch.conf ファイルの hosts の行に dns を追加します。

DNS とインターネットでのアクセスを参照してください。

マスターサーバーの hosts ファイルに、rigel 用のアドレス (A) レコードを追加します。
rigel IN A 192.168.112

マスターサーバーの hosts ファイルに、rigel 用の任意指定のレコードを追加します。

任意指定のレコードには、次のものがあります。
- エイリアス (CNAME)
- メール交換 (MX)
- 既知サービス (WKS)
- ホスト情報 (HINFO)

hosts.rev ファイルに rigel 用の PTR レコードを追加します。

マスターサーバーの hosts ファイルと hosts.rev ファイルの SOA シリアル番号を増やします。

サーバーのデータを再度読み込みます。

サーバーをリブートするか、次のように入力します。

# kill -HUP `cat /etc/named.pid`

クライアントの削除

DNS ドメインからクライアントを取り除く場合は、次の手順に従います。

スーパーユーザーになります。

削除するマシンの nsswitch.conf ファイルの hosts の行から dns を削除します。

マシンの /etc/resolv.conf ファイルを削除します。

マスターサーバーの hosts ファイルと hosts.rev ファイルからそのマシンのレコードを削除します。

そのマシンを示す CNAME レコードが存在するかどうかを確認します。レコードが存在する場合は、その CNAME レコードを hosts ファイルから削除する必要があります。

削除されるマシンによってサポートされていたサービスの代替を設定します。

マシンがマスターサーバーまたは必要なプロセスまたはを実行する別のマシンを設定する必要があります。

クライアントで IPv6 を使用できるようにする

次の手順を実行すると、クライアントで IPv6 を使用できるようになります。

クライアントで IPv6 を使用できるようにする方法

スーパーユーザーになります。

/etc/nsswitch.conf ファイルを編集します。

新しい ipnodes ソースを追加して、ネームサービス (LDAP など) を指定します。
ipnodes: ldap [NOTFOUND=return] files
ipnodes は、デフォルトでは files です。 IPv4 から IPv6 への変更中すべてのネームサービスが IPv6 のアドレスを認識できるわけではないので、デフォルトの files を使用してください。デフォルトを使用しない場合は、アドレスの解決中に不必要な遅延が生じることがあります。

ファイルを保存して、マシンをリブートします。

nscd デーモンはこの情報をキャッシュに保存するため、マシンをリブートする必要があります。

DNS サブドメインの作成

ネットワークは大きくなっていくので、ネットワークを複数の DNS サブドメインに分割すると便利です。 DNS ドメインの階層と構造については、DNS 名前空間の階層を参照してください。

ネットワークを親ドメインと複数のサブドメインに分割すると、負担が複数のドメインに分散して、各 DNS サーバーの負荷は減ります。このため、ネットワークのパフォーマンスは改善されます。

ネットワークを地理的または組織的な構成に合うように複数のサブドメインに分割することによって、DNS ドメイン名はどこに対象とするマシンがあるか、電子メールのアドレスが組織のどこにあたるのかを指し示すことになります。たとえば、rigel@alameda.doc.com は、マシン rigel が Alameda というサイトにあることを意味し、電子メールのアドレス barnum@sales.doc.com は、ユーザー barnum が営業 (sales) 部署の者であることを意味します。

ネットワークを複数のドメインに分けると、すべてをひとつのドメインに置く場合よりも設定作業が増えます。また、ドメインを互いにつなぐ委託データを保持しなければなりません。一方で、複数のドメインを持つと各ドメインの保守をそれぞれの管理者に分散させることができます。

サブドメインの設計

次に、ネットワークを 1 つの親ドメインと複数のサブドメインに分割するにあたって考慮すべき点をいくつかあげます。

「サブドメインの数」。作成するサブドメインの数が多ければ、それだけ初期設定の作業が増え、運用時の親ドメインの管理者の調整作業も増えます。一方で、ドメインの数が少ないということは、各ドメインが大きいということを意味し、ドメインが大きければそれをサポートするためにサーバーのスピードやメモリーが余計必要になります。
「ネットワークの分割方法」。ネットワークはどのようにでも複数のドメインに分割できます。重要なのは、ドメインの構造が統一されていて論理的かつ自明であれば、管理はより簡単になるということです。
「将来に対する考慮」。もっとも問題が多いのは、新しいサイトや部が増えるに従って、サブドメインが無計画に追加されて大きくなったドメインです。可能な限り、将来のドメインの拡大を見越してドメインの階層を設計してください。安定性も考慮に入れてください。最も安定しているものを基礎として、サブドメインを分けるようお勧めします。たとえば、地理的なサイトは比較的安定しているけれども、部や課が頻繁に再編成されるなら、サブドメインは組織よりも地理的な位置に基づいて決定する方が良いでしょう。一方、組織は比較的安定しているがサイトが頻繁に追加される場合は、サブドメインを組織の階層に基づいて決定する方が良いでしょう。
「広域ネットワーク (WAN) とのリンク」。ドメインが広域ネットワーク (WAN) に広がっていないなら、パフォーマンスと信頼性は高くなります。多くの場合、WAN のリンクは連続的なネットワーク接続より遅く失敗に終わる傾向があります。サーバーが、WAN のリンク経由だけで接続できるマシンをサポートする場合は、より遅いリンクを経由するトラフィックファネリングが増加することになります。 1 つのサイトで停電や何か他の問題が起こった場合には、他のサイトのマシンにも影響が及ぶ可能性があります。同様のパフォーマンスと信頼性の配慮は DNS ゾーンについても必要です。一般的な方法として、ゾーンをWAN のリンクに広げないようにすることをお勧めします。
「NIS+ 互換性」。エンタープライズレベルのネームサービスが NIS+ である場合は、DNS と NIS+ のドメイン構造とサブドメイン構造が一致すると管理がより簡単になります。
「サブドメイン名」。サブドメインに名前を付けるのに一貫したポリシーを確立してそれを守ってください。ドメイン名が一貫していれば、ユーザーは簡単に記憶し正しく指定できます。ドメイン名はすべてのDNS データファイルで重要な要素です。サブドメインを変更すると、古いドメイン名があるすべてのファイルを修正する必要があります。したがって、安定していて変更の必要がないと思われるサブドメイン名を選択するようにしてください。サブドメイン名として manufacturing のように完全指定することもできますし、manf のように短縮して指定することもできます。しかし、あるサブドメインが短縮形で指定され他が完全指定された場合、利用者は混乱します。短縮形を使用するのであれば、名前を識別するのに十分な文字数にしてください。短かすぎる名前は利用や記憶が困難だからです。最上位のインターネットのドメイン名として使用されている名前をサブドメイン名として使わないで下さい。すなわち、org、net、com、gov、edu と、2 文字の国のコード jp、uk、ca、it などは、サブドメイン名として使うことはできません。

サブドメインの設定

ほとんどの場合、新しいサブドメインは、新しいネットワークやマシンを接続するか、既存のドメインを分ける場合に作成されます。どちらの場合も、プロセスはよく似ています。

新しいサブドメインを設計した後、次の手順に従って設定します。

新しいサブドメイン内のすべてのマシンが DNS クライアントとして正しく設定されていることを確認してください。

既存のドメインから新しいサブドメインを分ける場合、ほとんどのマシンは DNS クライアントの設定がすでにされているはずです。既存のネットワークに新しいマシンを追加する場合は、正しく設定された resolv.conf ファイルと nsswitch.conf ファイルを各マシンにインストールする必要があります。

正しく設定された構成ファイルと DNS ゾーンデータファイルをサブドメインのマスターサーバーにインストールします。
- /etc/named.conf
- /var/named/named.ca
- /var/named/hosts
- /var/named/hosts.rev
- /var/named/named.local
サーバーのホストファイルには、サブドメイン内のマシンごとにアドレス (A) レコードと、場合によっては CNAME レコードが必要です。また、サーバーの hosts.rev ファイルには、サブドメイン内のマシンごとにポインタ (PTR) レコードが必要です。任意指定の HINFO と WKS レコードも追加できます。

ドメインを分割する場合は、新しいサブドメインのマシン用のレコードをマスターサーバーの hosts ファイルと hosts.rev ファイルから削除してください。

そのためには、現在新しいサブドメイン内にあるマシン用の A レコードを古いドメインサーバーの hosts ファイルから削除します。また、同じマシンの PTR レコードを古いドメインサーバーの hosts.rev ファイルから削除します。移動するマシン用の任意指定の HINFO レコードと WKS レコードも、削除する必要があります。

既存のドメインを分割する場合は、新しいサブドメイン名を、マスターサーバーの hosts ファイル内の CNAME レコードに追加します。

たとえば、aldebaran というマシンをファックスサーバーとして使うとします。このファックスサーバーの親ドメインのサーバーの hosts ファイル内の CNAME レコードが次のとおりであるとします。
faxserver IN CNAME aldebaran
新しいマスターサーバーの hosts ファイル内に、aldebaran 用の faxserver CNAME レコードを作成します。また、以下のように親ドメインの hosts ファイル内の CNAME レコードを変更して、aldebaran のサブドメインを含める必要もあります。
faxserver IN CNAME aldebaran.manf.doc.com

新しいサブドメインのサーバーの NS レコードを、親ドメインの hosts ファイルに追加します。

たとえば、親ドメインは doc.com とします。 rigel というマシンを manf のマスターサーバーとし、manf.doc.com という新しいサブドメインを作成します。 aldebaran をスレーブサーバーとして指定します。この場合、次のレコードを doc.com のマスターサーバーの hosts ファイルに追加することになります。
manf.doc.com 99999 IN NS rigel.manf.doc.com 99999 IN NS aldebaran.manf.doc.com

新しいサブドメインのサーバー用の A レコードを、親ドメインの hosts ファイルに追加します。

この場合、次のレコードを doc.com のマスターサーバーの hosts ファイルに追加することになります。
rigel.manf.doc.com 99999 IN A 1.22.333.121 aldebaran.manf.doc.com 99999 IN A 1.22.333.136

サブドメインのサーバー上の in.named を起動します。

# /usr/sbin/in.named

コマンド行から in.named を実行する代わりに、リブートします。 in.named と DNS ネームサーバーを参照してください。

Solaris DNS BIND 8.3.3 の実装

Solaris オペレーティング環境では、コンパイル版の Berkeley Internet Name Domain (BIND) 8.3.3 を提供します。このバージョンの BIND には、BIND バージョン8.3.4 に組み込まれるセキュリティ上の修正が含まれています。コンパイルにあたっては、より多くのサイトのニーズを満たすように各種オプションを設定しました。このコンパイル済みの BIND が要件に合わない場合は、公開されているソースコードから独自にコンパイルすることができます。

Solaris オペレーティング環境で提供される BIND バージョンのコンパイルでは、以下の選択が行われました。

「RFC1535」。実装によって暗黙の検索リストが削除されるため、現在は実装されていません。
「逆参照」。これがないと SunOS 4 の nslookup が機能しないため許可されています。
「デフォルトのドメイン名」。 DNS ドメイン名が /etc/resolv.conf 内または LOCALDOMAIN 環境変数で設定されていない場合、libresolv() は DNS ドメイン名を NIS または NIS+ ドメイン名から引用します。
「ユーティリティスクリプト」。 BIND のユーティリティスクリプトは、今回の Solaris リリースには含まれていません。
「テストプログラム」。 BIND のテストプログラムである dnsquery および host は、今回の Solaris リリースには含まれていません。これらのテストプログラムの目的は、nslookup と dig の目的と同様であるためです。

BIND 4.9.x から BIND 8.3.3 に移行する方法

Solaris 9 リリースでは、named.boot ファイルは無視されます。

スーパーユーザーになります。

DNS 構成ファイルを変換します。

Korn シェルスクリプト /usr/sbin/named-bootconf を実行し、BIND 4.9.x の named.boot ファイルを BIND 8.3.3 の named.conf ファイルに変換します。

DNS の転送

nsswitch.conf ファイルは、クライアントの DNS 転送とインターネットへのアクセスを管理します。 NIS クライアントには、転送機能が含まれています。 NIS+ クライアントにはこの機能がありません。次の手順を参照してください。

NIS+ クライアントで DNS 転送機能を使用できるようにする方法

スーパーユーザーになります。

/etc/nsswitch.conf ファイルの hosts 行を次のように正しく設定します。 hosts: nisplus dns files.

この NIS 実装では、該当するサーバー上に /etc/resolv.conf ファイルが存在する場合は、ypstart が -d オプションで「自動的に」 ypserv デーモンを起動して DNS に要求を転送します。 DNS への転送を停止する場合は、/usr/lib/netsvc/yp/ypstart スクリプトを編集して -d オプションを ypserv コマンドから削除してください。その後マシンをリブートする必要があります。

以前の NIS クライアントで DNS 転送機能を使用できるようにする方法

スーパーユーザーになります。

hosts.byname マップ内に YP_INTERDOMAIN キーを設定します。 Makefile の次の行を修正して、hosts.byaddr マップを設定してください。
#B=-b B=
から
B=-b #B=
これで、マップの作成時に makedbm が -b フラグを使って起動されるようになるため、YP_INTERDOMAIN が ndbm ファイルに挿入されます。

マップを作成し直します。
# /usr/ccs/bin/make hosts

有効な名前のサーバーを指定している /etc/resolv.conf ファイルが NIS サーバーに存在することを確認します。

ypstop スクリプトを使用して、各サーバーを停止します。
# /usr/lib/netsvc/yp/ypstop

ypstart スクリプトを使用して、各サーバーを再起動します。

# /usr/lib/netsvc/yp/ypstart

注 –

Solaris 2 リリース以降が稼動していない NIS サーバーを使用している場合は、ホストマップに YP_INTERDOMAIN キーが存在することを確認してください。また、マスターサーバーとスレーブサーバーが「異なる」バージョンの Solaris を実行している場合は、問題が発生することがあります。次の表に、このような問題を回避するためのコマンドがまとめてあります。「4.0.3+」という表記は、「SunOS のリリース 4.0.3 以降」であることを意味します。makedbm -b コマンドは、Makefile の変数「B」への参照です。

表 4–1 異機種システムが混在する NIS ドメインにおける NIS/DNS


スレーブサーバー	マスターサーバー
	4.0.3+	Solaris NIS
4.0.3+	マスターサーバー: `makedbm` `-b` スレーブサーバー: `ypxfr`	マスターサーバー: `makedbm` `-b` スレーブサーバー: `ypxfr` `-b`	マスターサーバー: `ypserv` `-d` スレーブサーバー: `ypxfr` `-b`
Solaris NIS	マスターサーバー: `makedbm` `-b` スレーブサーバー: `ypxfr`	マスターサーバー: `makedbm` `- b` スレーブサーバー: `ypxfr`	マスターサーバー: `ypserv` `-d` スレーブサーバー: `resolv.conf` が存在する `ypxfr` または `ypxfr` `-b`

Solaris オペレーティング環境には、リゾルバを構成している動的ライブラリ関数が含まれています。

第 5 章 DNS の管理 (参照情報)

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

DNS の実装の実例

この節では、この章で説明する例を基にして、サンプルのインターネット接続ネットワークを想定し、そこで使う DNS を設定するために必要なファイルを示します。

注意 –

このマニュアル内の例やコード例で使われている IP アドレスとネットワーク番号は、説明に具体性を持たせるために仮に決めたものです。これらの情報は、実際のネットワークやホストに使われていることがあるので、そのまま使うのは避けてください。

この実例では、次のことを前提としています。

インターネットに接続されている
2 つのネットワークが存在していて、それぞれ個別のドメインを持つ (doc.com と sales.doc.com)。DNS ゾーンも別々に管理
doc.com ドメインおよび doc.com ゾーンが sales.doc.com サブドメインおよび sales.doc.com ゾーンの上の最上位ゾーンである
2 つのネットワークはそれぞれ個別のネットワーク番号を持つ
表 5–1 ネットワークドメインとゾーン構成の例

名前/ゾーン

番号

doc.com

123.45.6

sales.doc.com

111.22.3

名前/ゾーン	番号
`doc.com`	`123.45.6`
`sales.doc.com`	`111.22.3`

各ゾーンにマスターサーバーとスレーブサーバーが 1 台ずつあり、doc.com のマスターサーバーが sales.doc.com のスレーブサーバーを兼ねている

表 5–2 ネットワーク DNS サーバーの例


ゾーン	ホスト名	機能	アドレス	CNAME
`doc.com`	`sirius`	`doc.com` のマスターサーバー	`123.45.6.1`	`dnsmaster`
`doc.com`	`deneb`	`doc.com` のスレーブサーバー	`111.22.3.5`	`dnssecond`
`sales.doc.com`	`altair`	`sales.doc.com` のマスターサーバー	`111.22.3.4`	`dnssales`
`sales.doc.com`	`altair`	`sales.doc.com` のスレーブサーバー	`123.45.6.1`	`dnsmaster`

構成ファイルの例

次に示すのは、2 つのネットワークで使われている 3 つのサーバーの構成ファイルです。

例 5–1 `dnsmastr` ネームサーバー用構成ファイルの例

;
; Sample named.conf file on dnsmastr (sirius) name server
; 
; global options and defaults
;

options {
        directory  "/var/named";
};

; master zone definitions
;
zone "doc.com"  in  {
        type master;
        file "db.doc.com";
};

zone "6.45.123.in-addr.arpa"  in  {
        type master;
        file "db.123.45.6";
};

zone "0.0.127.in-addr.arpa"  in  {
        type master;
        file "db.127.0.0";
};

; slave server definitions
;
zone "sales.doc.com"  in  {
        type slave;
        file "tmp.db.sales";
        masters { 111.22.3.4; };
};

zone "3.22.111.in-addr.arpa"  in  {
        type slave;
        file "tmp.db.111.22.3";
        masters { 111.22.3.4; };
};

; root hints

zone "."  in  {
        type hint;	
        file "named.ca";
};

例 5–2 `dnssales` ネームサーバー用構成ファイルの例

; 
; Sample named.conf file on the dnssales (altair) name server
; 

options {
        directory  "/var/named";
};

zone "sales.doc.com"  in  {
        type master;
        file "db.sales.doc.com";
};

zone "3.22.111.in-addr.arpa"  in  {
        type master;
        file "db.111.22.3";
};

zone "0.0.127.in-addr.arpa"  in  {
        type master;
        file "db.127.0.0";
};

; root hints

zone "."  in  {
        type hint;
        file "named.ca";
};

例 5–3 `dnssecond` ネームサーバー用構成ファイルの例

; 
;S ample named.conf file on the dnssecond (deneb) name server
; 

options {
        directory  "/var/named";
};

zone "doc.com"  in  {
        type slave;
        file "tmp.db.doc.com";
        masters { 123.45.6.1; };
};

zone "6.45.123.in-addr.arpa"  in  {
        type slave;
        file "tmp.db.123.45.6";
        masters { 123.45.6.1; };
};

zone "0.0.127.in-addr.arpa"  in  {
        type master;
        file "db.127.0.0";
};

; root hints

zone "."  in  {
        type hint;
        file "named.ca";
};

`resolv.conf` ファイルの例

次に示すのは、2 つのネットワークで使われている 3 つのサーバーの resolv.conf ファイルです。そのホストが in.named を起動していない場合、そのローカルホストのアドレスをネームサーバーとして使用しないでください。

例 5–4 `dnsmastr` サーバー用 `resolv.conf` ファイルの例

;
; /etc/resolv.conf file for dnsmaster (sirius)
;
domain           doc.com
nameserver       0.0.0.0
nameserver       111.22.3.5

例 5–5 `dnssales` サーバー用 `resolv.conf` ファイルの例

;
; /etc/resolv.conf file for dnssales (altair)
;
domain           sales.doc.com
nameserver       111.22.3.4
nameserver       123.45.6.1

例 5–6 `dnssecond` サーバー用 `resolv.conf` ファイルの例

;
; /etc/resolv.conf for dnssecond
;
domain           doc.com
nameserver       111.22.3.5
nameserver       123.45.6.1

`named.local` ファイルの例

次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーで使われている named.local ファイルです。どちらのサーバーも同じファイルを持っています。

例 5–7 マスターサーバー用 `named.local` ファイルの例

$TTL 5h
; SOA rec
0.0.127.in-addr.arpa. IN SOA siriusdoc.com. sysop.centauri.doc.com.(
                          19970331    ; serial number
                          10800       ; refresh every 3 hours
                          10800       ; retry every 3 hours
                          604800      ; expire after a week
                          86400 )     ; TTL of 1 day
; Name Servers
0.0.127.in-addr.arpa.  IN  NS   sirius.doc.com.
0.0.127.in_addr.arpa   IN  NS   dnssecond.doc.com
1  IN  PTR localhost.

`hosts` ファイルの例

次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーで使われている db.doc ファイルと db.sales ファイルです。

例 5–8 `dnsmastr` サーバー用 `db.doc` ファイルの例

$TTL 5h
; SOA rec
doc.com. IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                          19970332    ; serial number
                          10800       ; refresh every 3 hours
                          10800       ; retry every 3 hours
                          604800      ; expire after a week
                          86400 )     ; TTL of 1 day
; Name Servers
doc.com.               IN  NS  sirius.doc.com.
sales.doc.com.         IN  NS  altair.sales.doc.com.
; Addresses
localhost              IN  A  127.0.0.1
sirius                 IN  A  123.45.6.1
rigel                  IN  A  123.45.6.112
antares                IN  A  123.45.6.90
polaris                IN  A  123.45.6.101
procyon                IN  A  123.45.6.79
tauceti                IN  A  123.45.6.69
altair.sales.doc.com.   N  A   111.22.3.4
; aliases
dnsmastr               IN  CNAME   sirius.doc.com.
dnssecond.doc.com      IN  CNAME   deneb.doc.com

例 5–9 `dnssales` サーバー用 `db.sales` ファイルの例

$TTL 5h
; SOA rec
sales.doc.com.  IN SOA altair.sales.doc.com. sysop.polaris.doc.com. (
                           19970332    ; serial number
                           10800          ; refresh every 3 hours
                           10800          ; retry every 3 hours
                           604800         ; expire after a week
                           86400 )        ; TTL of 1 day
; Name Servers
doc.com.                IN  NS  sirius.doc.com.
sales.doc.com.          IN  NS  altair.sales.doc.com.
; Addresses
altair                  IN  A  111.22.3.4
localhost               IN  A  127.0.0.1
sirius.doc.com.         IN  A  123.45.6.1
luna                    IN  A  192.168.8.22
phoebus                 IN  A  192.168.8.24
deimos                  IN  A  192.168.8.25
ganymede                IN  A  192.168.8.27
europa                  IN  A  192.168.8.28
callisto                IN  A  192.168.8.29
; 
; aliases
dnssales.sales.doc.com  IN  CNAME    altair.sales.doc.com

`hosts.rev` ファイルの例

次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーで使われている hosts.rev ファイルです。

例 5–10 `dnsmastr` サーバー用 `hosts.rev` ファイルの例

$TTL 5h
; SOA rec
6.45.123.in-addr.arpa.  IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                           19970331    ; serial number
                           10800       ; refresh every 3 hours
                           10800       ; retry every 3 hours
                           604800      ; expire after a week
                           86400 )     ; TTL of 1 day
; Name Servers
6.45.123.in-addr.arpa.  IN  NS  sirius.doc.com.
;Pointer records for 123.45.6
1                       IN  PTR sirius.doc.com.
112                     IN  PTR rigel.doc.com.
90                      IN  PTR antares.doc.com. 
101                     IN  PTR polaris.doc.com. 
79                      IN  PTR procyon.doc.com.
69                      IN  PTR tauceti.doc.com.

例 5–11 `dnssales` サーバー用 `hosts.rev` ファイルの例

$TTL 5h
; SOA rec
3.22.111.in-addr.arpa.  IN SOA altair.sales.doc.com. \
sysop.polaris.doc.com.(
                           19970331    ; serial number
                           10800       ; refresh every 3 hours
                           10800       ; retry every 3 hours
                           604800      ; expire after a week
                           86400 )     ; TTL of 1 day
; Name Servers
3.22.111.in-addr.arpa.  IN  NS  altair.sales.doc.com.; \
Pointer records for 111.22.3
22                      IN  PTR  luna
23                      IN  PTR  deneb
24                      IN  PTR  phoebus
25                      IN  PTR  deimos
26                      IN  PTR  altair
27                      IN  PTR  ganymede
28                      IN  PTR  europa
29                      IN  PTR  callisto

`named.ca` ファイルの例

次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーにそれぞれ格納される named.ca ファイルです。どちらのサーバーも同じ named.ca ファイルを使用します。

例 5–12 `named.ca` ファイルの例

;
; formerly NS1.ISI.EDU
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
; formerly C.PSI.NET
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;.                       3600000      NS    E.ROOT-SERVERS.NET.
 
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
; formerly NIC.NORDU.NET
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
;
; temporarily housed at NSI (InterNIC)
.                        3600000      NS    J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
;
; temporarily housed at NSI (InterNIC)
.                        3600000      NS    K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000      A     198.41.0.11
;
; temporarily housed at ISI (IANA)
.                        3600000      NS    L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
;
; temporarily housed at ISI (IANA)
.                        3600000      NS    M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000      A     198.32.65.12
; End of File

データファイルの設定

DNS のデーモン in.named によって使用されるすべてのデータファイルは標準リソースレコード書式で書かれます。標準リソースレコード書式では、ファイルの各行は、リソースレコード (RR) と呼ばれるレコードです。各 DNS データファイルには決められたリソースレコードが必要です。

最も一般的に使用されるリソースレコードのタイプを表 5–6 に列挙します。通常、表 5–6 に並んだ順で入力しますが、この順序は必須ではありません。

これ以降に示すサンプルファイルでは、@ は現在のゾーンまたは現在の起点を示します。セミコロン (;) で始まる行はコメントです。

サブドメインの設定

単一ゾーン内、また複数ゾーン内のサブドメインを設定できます。次の節では、両方の方法について説明します。

単一ゾーンのサブドメインの設定

最も簡単な方法は、サブドメインを親ドメインのゾーンに含めることです。こうすると、1 セットの DNS サーバーとデータファイルでドメインに関係なくすべてのマシンを管理できます。

単一ゾーン方式の長所は、管理が簡素化され簡単なことです。短所は 1 セットのサーバーですべてのゾーンのドメインにあるマシンを管理しなければならないということです。マシンの数が多すぎると、サーバーの負荷が大きくなり過ぎ、パフォーマンスが低下することがあります。

複数のドメインで構成されているゾーンのデータファイルには、そのゾーンに含まれる各ドメインのすべてのマシンとサーバーに関わるレコードが必要です。

複数のドメインで構成されているゾーンを設定するのも、単一ドメインで構成されているゾーンを設定するのも、必要な作業は基本的に同じです。唯一の相違は、遠隔ドメインのマシンを識別できるようにするために、hosts ファイルには完全指定のドメイン名を使用しなければならないということです。サーバーのローカルドメインにあるマシンであれば、hosts ファイルにマシン名しか指定されていなくても識別できます。しかし、他のドメインにあるマシンを識別するには、完全指定のドメイン名、つまり、machine.domain という書式で指定しなければなりません。

hosts.rev ファイルと named.local ファイルに指定するサーバー名やマシン名にも、完全指定のドメイン名を使用する必要があります。ただし、これはゾーンがいくつのドメインで構成されているかには関係ありません。

複数ゾーンのサブドメインの設定

複数ゾーン方式の長所は、ドメインごとにその中のマシンを管理するサーバーセットを割り当てられるということです。つまり、サーバーの負荷を分散させ、1 セットのサーバーに負荷が集中するのを防ぐことができます。短所は、設定時の作業がより複雑になることです。

異なるゾーンのサブドメインを設定するのは、1 つのゾーンに複数のドメインを含めるのよりも複雑です。これは、さまざまなゾーンにあるクライアントが他のゾーンの DNS 情報を得る方法を指定しなければならないからです。

ネットワークを複数のドメインに分ける場合、ドメインを階層化します。必ず最上位のドメインがあって、その下に 1 つまたは複数のサブドメインがあります。サブドメインの下にサブドメインを作ることもできます。しかし、どのサブドメインにも階層構造の中で最上位のドメインから相対的に決まった場所があります。ドメイン名は左から右に読んでいくと、階層内におけるドメインの位置を示していることがわかります。たとえば、doc.com ドメインは sales.doc.com ドメインの上位にあり、west.sales.doc.com ドメインは sales.doc.com ドメインの下位にあることがわかります。

DNS ゾーンはそのゾーンが含むドメインから階層を取り込みます。ネットワークの最上位ドメインを含むゾーンは最上位のゾーンになります。最上位のドメインの下のサブドメインを 1 つ以上含むゾーンは、ゾーンの階層でいえば最上位のゾーンの下のゾーンになります。 DNS 情報をあるゾーンから別のゾーンへ移動させるということは、このゾーン階層の中を上下に移動させるということです。つまり、各ゾーンでは、すぐ上のゾーンに情報を渡すにはどうするか、すぐ下のゾーンに情報を渡すにはどうするかを専用のデータファイルのレコードに指定しておく必要があります。

複数のゾーンで構成されているネットワークの中で、DNS 情報をあるゾーンから別のゾーンへ正確に転送させるために必要なことを以下に示します。

hosts.rev ファイル。すぐ上のゾーンにある 1 つまたは複数のマスターサーバー名を指し示す PTR レコードが各 hosts.rev ファイルに必要です。上位ゾーンのサーバーを指し示すということを除けば、この種の PTR レコードは、ファイル内のその他の PTR レコードとまったく同じのものです。
hosts ファイルの NS レコード。すぐ下の各ゾーンにあるネームサーバー名を指し示すゾーン NS レコードが各 hosts ファイルに必要です。この種の NS レコードは、その最初のフィールドに下のゾーン名が指定されていなければなりません。 (ゾーン名は、そのゾーンの host ファイルの SOA レコードに指定されています。)
hosts ファイルの A レコード。すぐ下の各ゾーンにあるネームサーバーの IP アドレスを指し示す A レコードが各 hosts ファイルに必要です。この種の A レコードは、その最初のフィールドに下のゾーン名が指定されていなければなりません。ゾーン名は、そのゾーンの host ファイルの SOA レコードに指定されています。

この章のファイル例に、2 つのゾーンを持つネットワークが示してあります。

DNS 名前空間の階層

全世界の DNS 管理ドメインの集合全体は「DNS 名前空間」と呼ばれる階層構造を形成しています。ここでは、名前空間の組織がどのようにローカルドメインやインターネットに影響するのか説明します。

ドメインとサブドメイン

DNS ドメインは、UNIX のファイルシステムと同様、木の根に似た下向きの枝分かれで構成されています。各枝分かれがドメインであり、そこから分かれる各枝が「サブドメイン」です。「ドメイン」と「サブドメイン」は相対的な関係を示します。階層の中で、あるドメインは、その上にあるドメインに対するサブドメインになり、その下にあるサブドメインの親ドメインになります。

図 5–1 ドメインとサブドメイン

この図は、.com のサブドメインである Acme、Ajax、および AAA と、それらのサブドメインにあたる Sales、Manf、QA、および Corp を示しています。

たとえば、図 5–1 において com は Acme、Ajax、AAA の各ドメインの親ドメインです。あるいは、これらのドメインは com ドメインのサブドメインということもできます。このように考えると、Ajax ドメインは 4 つのサブドメイン (Sales、Manf、QA、Corp) の親ドメインになっています。

あるドメインには、1 つの親 (または最上位) ドメインと、(存在する場合) その下のサブドメインが含まれます。ドメインの名前は、最下位 (階層の底) のサブドメインから始まり、最後がルートドメインとなっています。

DNS のメール配信への影響について

DNS は、名前のアドレス解決で説明しているように、名前からアドレス (またはその逆のアドレスから名前) のマッピングを行う他に、インターネット上でメールを配信する sendmail や POP といったメール配信エージェントの役にも立っています。

インターネット上でメールを配信するのに、DNS は「メール交換レコード」(MX レコード) を用います。ほとんどの組織は、その組織内にあるホストに宛てられたインターネットから来るメールを直接配信することを許可しません。そのかわりに、１台の中央メールホスト (またはメールホストの集合) を使用して、入ってくるメールメッセージを途中で止めて宛先に振り分けます。

メール交換レコードで、ドメイン内の各マシンにサービスを提供しているメールホストが識別されるため、メール交換レコードには遠隔組織の DNS ドメイン名と、その IP アドレスまたは対応するメールホストのホスト名のいずれかが列挙されています。

DNS の構成ファイルとデータファイル

DNS のネームサーバーには、in.named デーモンに加えて、named.conf という構成ファイル、resolv.conf というリゾルバファイル、4 種類のゾーンデータファイルがあります。

DNS データファイルの名前

内部で一貫性が取れていれば、ゾーンデータファイルには何でも好きな名前を付けることができます。このため、異なるサイトで作業をしようとする場合や DNS 関連のマニュアルや本を参照する場合に、混乱するかもしれません。

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

さらに、本書とその他の DNS 関連のマニュアルでは、説明にはファイルの主な役割を表す総称名を使い、コード例には具体的な固有の名前を使っています。たとえば、Solaris のネームサービスに関するマニュアルでは、ファイルの機能や役割を説明する場合は hosts という総称名を使い、コード例では db.doc や db.sales.doc といった名前を使っています。

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

表 5–3 BIND ファイル名の例


Solaris	O'Reilly / その他	カリフォルニア州立大学バークレイ校	ファイルの内容と役割
`/etc/named.conf`	`/etc/named.conf`	`/etc/named.conf`	構成ファイルは、それが実行されるサーバーのタイプ、および「マスター」、「スレーブ」、または「スタブ」として機能するゾーンを指定する。また、セキュリティ、ロギング、およびゾーンに適用されるオプションの細かい細分性を定義する
`/etc/resolv.conf`	`/etc/resolv.conf`	`/etc/resolv.conf`	各クライアント (DNS サーバーを含む) 上に存在するファイル。DNS 情報を探すためにクライアントが照会するサーバーを示す
`named.ca`	`db.cache` `db.root`	`root.cache`	ルートサーバー名とそのアドレスがリストされている
総称名: `hosts` 例: `db.doc db.sales`	総称名: `db.domain` 例: `db.movie` `db.fx`	総称名: `hosts` 例: `ucbhosts`	サーバーがサービスを提供するローカルゾーン内のマシンに関する全データが格納されている
総称名: `hosts.rev` 例: `doc.rev`	総称名: `db.ADDR 例: db.192.249.249 db.192.249.253`	`hosts.rev`	逆マッピング (アドレスから名前) を行うための特殊なドメイン`in-addr.arpa.` のゾーンを指定する
`named.local`	総称名: `db.cache` 例: `db.127.0.0`	`named.local`	ローカルループバックインタフェースまたはローカルホスト用のアドレスを指定する
`$INCLUDE` ファイル	`$INCLUDE` ファイル	`$INCLUDE` ファイル	データファイル内の `$INCLUDE()` 文によって識別されるファイル

注意 –

`named.conf` ファイル

BIND 構成ファイル /etc/named.conf は、サーバーをマスターサーバー、スレーブサーバー、またはキャッシュ専用サーバーとして設定します。また、サーバーが権限を持つゾーンを指定し、どのデータファイルから初期データを取得するかを指定します。

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

アクセス制御リスト(ACL) によるセキュリティ。ACL には、NIS+ ホストが読み取り/書き込み権を持つ IP アドレスの集まりが定義されている
ロギング動作の指定
すべてのゾーンにではなく、ゾーンのセットに対して選択的に適用されるオプション

構成ファイルは、サーバーの起動スクリプト /etc/init.d/inetsvc によってデーモンが起動されるとき、in.named によって読み取られます。構成ファイルにより、他のサーバー (マスター、スレーブまたはキャッシュ専用サーバー) として設定されるか、あるいは初期データを取得する構成ファイルが示されます。

`named.conf` 文

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

named.conf ファイルは、以下の文をサポートします。

表 5–4 named.conf 文


文	説明
`acl`	アクセス制御に使用する、IP アドレスの一致リストを名前を付けて定義する。アドレスの一致リストは、1 つ以上の IP アドレス (ドット形式の 10 進表記) または IP 接頭辞 (ドット形式の 10 進表記の後にスラッシュとネットマスクのビット数が付く) を示す。名前を付けたIP アドレスの一致リストは、他の場所で使用する前に `acl` 文で定義されている必要がある。前方参照は不可。
`include`	`include` 文がある箇所にインクルードファイルを挿入する。 `include` を使用することで、管理しやすいまとまりに構成情報を分割することができる
`key`	特定のネームサーバーでの認証と承認に使用される鍵の ID を指定する。 `server` 文を参照
`logging`	サーバーが記録するログ情報と、ログメッセージの送り先を指定する
`options`	グローバルなサーバー構成のオプションを制御して、他の文に対するデフォルト値を設定する
`server`	遠隔ネームサーバーに関して、指定された構成オプションを設定する。すべてのサーバーに対してではなく、サーバーごとに選択的にオプションを適用する
`zone`	ゾーンを定義する。すべてのゾーンに対してではなく、ゾーンごとに選択的にオプションを適用する

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

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;
         };
};

`named.ca` ファイル

named.ca ファイルによって、ルートサーバー名が確立され、そのアドレスが列挙されます。ネットワークがインターネットに接続されている場合は、named.ca には、インターネットのネームサーバーが表示されます。接続されていなければ、ローカルネットワークのルートドメインネームサーバーが表示されます。 in.named デーモンは、サーバーの 1 つに接続できるまで、サーバーのリストを一巡します。そして、そのサーバーから現在のルートサーバーのリストを入手します。デーモンは、このリストを named.ca の更新のために用います。

`named.ca` ファイルの設定

ルートサーバー名は NS レコードに、アドレスは A レコードに示されています。この named.ca ファイルを使用するルートサーバーごとに、NS レコードと A レコードを追加する必要があります。

named.ca ファイルの入手方法または作成方法は、ネットワークがインターネットに接続されているかどうかによって異なります。

インターネット `named.ca` ファイル

ネットワークがインターネットに接続されている場合は、InterNIC Registration Service (本書執筆の時点) から次の手段で named.ca ファイルを入手できます。

匿名 FTP。 FTP サイトは ftp.rs.internic.net、ファイルは /domain/named.root です。
Gopher。 Gopher サイトは rs.internic.net です。ファイルは named.root であり、これは「InterNIC Registration Service」メニューの「InterNIC Registration Archives」サブメニューで見つけることができます。

本書で説明した命名規則に従う場合、named.root を /var/named/named.ca に移動します。

例 5–14 インターネット `named.ca` ファイルの例

;
; formerly NS1.ISI.EDU
.                        3600000    NS   B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000    A    128.9.0.107
;
; formerly C.PSI.NET
.                        3600000    NS   C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000    A    192.33.4.12
;
; formerly TERP.UMD.EDU
.                        3600000    NS   D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000    A    128.8.10.90
;
; formerly NS.NASA.GOV
;.                       3600000    NS   E.ROOT-SERVERS.NET.
 
E.ROOT-SERVERS.NET.      3600000    A    192.203.230.10
;
; formerly NS.ISC.ORG
.                        3600000    NS   F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000    A    192.5.5.21
;
; formerly NS.NIC.DDN.MIL
.                        3600000    NS   G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000    A    192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
.                        3600000    NS   H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000    A    128.63.2.53
;
; formerly NIC.NORDU.NET
.                        3600000    NS   I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000    A    192.36.148.17
;
; temporarily housed at NSI (InterNIC)
.                        3600000    NS   J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.      3600000    A    198.41.0.10
;
; temporarily housed at NSI (InterNIC)
.                        3600000    NS   K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.      3600000    A    198.41.0.11
;
; temporarily housed at ISI (IANA)
.                        3600000    NS   L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.      3600000    A    198.32.64.12
;
; temporarily housed at ISI (IANA)
.                        3600000    NS   M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.      3600000    A    198.32.65.12
; End of File

非インターネット `named.ca` ファイル

ネットワークがインターネットに接続されていない場合は、独自の named.ca ファイルを作成する必要があります。そのためには、サーバーのどれか 1 つをルートサーバーとし、DNS サーバーごとにそのルートサーバーを指す named.ca ファイルを作成します。

たとえば、private というドメインで ourroot というマシンを非インターネットルートサーバーとして指定する場合を想定します。 ourroot の IP アドレスが 192.1.1.10 であるとすると、 named.ca ファイルには次の行を書き込みます。

ourroot.private.  999999  IN  A  192.1.1.10

キャッシュファイルも SOA レコード、各ドメインおよびサブドメインの NS レコード、各サーバーの A レコードを必要とします。

たとえば、ourroot の他に、ourmaster と ourslave という 2 つの DNS ネームサーバーがあるとします。その場合、DNS サーバー上の named.ca ファイルはすべて次のようになります。

例 5–15 `named.ca` ファイル (非インターネット) の例

;
@    IN    SOA  ourroot.private.   hermit.ourroot.private  (    
                 1997071401       ;  serial number (YYYYMMDD##)
                 10800            ;  refresh after 3 hours
                 3600             ;  retry after 1 hour
                 604800           ;  expire after 1 week
                 86400 )          ;  minimum TTL of 1 day
;
ourroot.private.      999999     IN    A    192.1.1.10
;
private.                         IN    NS   ourmaster.private.
1.1.192.in-addr.arpa             IN    NS   ourmaster.private.
 
ourprivate.private.              IN    A    192.1.1.1
;
private.                         IN    NS   ourslave.private.
1.1.192.in-addr.arpa             IN    NS   ourslave.private.
ourslave.private.            IN    A    192.1.1.2

`hosts` ファイル

hosts ファイルには、ローカルゾーン内のマシンに関するすべてのデータが含まれています。このファイル名は、構成ファイル内で指定します。 /etc/hosts との混同を避けるために、hosts 以外の名前を付けます。たとえば、これらのファイルに db.domain パターンを使用して名前を付けることができます。この命名方法により、doc.com と sales.doc.com ドメインのホストファイルは db.doc と db.sales になります。

`hosts` ファイルの設定

hosts ファイルには、ゾーン内にある各マシンの全データが収められています。ゾーンが複数のドメインにまたがっている場合は、そのゾーンを構成する全ドメインの全マシンがそのゾーンのホストファイルに列挙されます。 hosts ファイルの設定を参照してください。

注 –

hosts という名前はファイルの役割や内容を表す総称名です。ただし、この総称名をそのまま使うと /etc/hosts と紛らわしいので、この種のファイルは hosts 以外の名前にします。ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts ファイルを置き、各ゾーンの hosts ファイルには一意の名前を付けなければなりません。たとえば、DNS ドメイン内に doc.com と sales.doc.com という 2 つのゾーンがある場合は、1 つの hosts ファイルを db.doc、もう 1 つを sales.db.doc という名前にするとよいでしょう。

各ゾーンには個別の、一意の名前を持つ hosts ファイルが必要です。複数のゾーンが存在する場合は、各ゾーンの hosts ファイルには他のゾーンのマスター (マスター、スレーブ) サーバーに関する情報も含める必要があります。詳細については、例 5–16 を参照してください。

例 5–16 `hosts` ファイルの例

$TTL 5h
;
; SOA rec
doc.com.  IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                 1997071401       ;  serial number (YYYYMMDD##)
                      10800       ;  refresh every 3 hours
                      10800       ;  retry every 3 hours
                      604800      ;  expire after a week
                      86400 )     ;  TTL of 1 day
; Name Servers
doc.com.                   IN  NS  sirius.doc.com.
sales.doc.com.             IN  NS  altair.sales.doc.com.
; Addresses
localhost.                 IN  A  127.0.0.1
 
sirius                    IN  A  192.168.6.1
rigel                     IN  A  192.168.6.112
antares                   IN  A  192.168.6.90
polaris                   IN  A  192.168.6.101
procyon                   IN  A  192.168.6.79
tauceti                   IN  A  123.45.6.69
altair.sales.doc.com.     IN  A   111.22.3.4
; aliases
durvasa                   IN  CNAME sirius.doc.com.
dnsmastr                  IN  CNAME sirius.doc.com.
dnssales                  IN  CNAME altair.sales.doc.com.

hosts ファイルは通常、次の要素で構成されています。

明示的な TTL (生存期間) セットを持たない、ファイル内の全レコードのデフォルト TTL
1 つの SOA (権限の開始) レコード
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する
A (アドレス) レコード。ゾーン内の各ホストに必要
CNAME (正規名) レコード。ゾーン内の各ホストのエイリアスに必要
1 つまたは複数の MX (メール交換) レコード

`hosts.rev` ファイル

hosts.rev ファイルで、逆 (アドレスから名前) マッピングを行うための特別な in-addr.arpa. ドメインのゾーンを指定します。このファイル名は、構成ファイル内で指定します。

`hosts.rev` ファイルの設定

hosts.rev は逆マッピングを設定するファイルです。

注 –

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

例 5–17 `hosts.rev` ファイルの例

$TTL 5h
; SOA rec
6.45.123.in-addr.arpa.  IN SOA sirius.doc.com. sysop.centauri.doc.com. (
                 1997071401       ;  serial number (YYYYMMDD##)
                      10800       ;  refresh every 3 hours
                      10800       ;  retry every 3 hours
                      604800      ;  expire after a week
                      86400 )     ;  TTL of 1 day
; Name Servers
6.45.123.in-addr.arpa.   IN  NS  sirius.doc.com.
1                        IN  PTR sirius.doc.com.

hosts.rev ファイルは、次の要素で構成されています。

明示的な TTL (生存期間) セットを持たない、ファイル内の全レコードのデフォルト TTL
1 つの SOA (権限の開始) レコード
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する

サーバー名は省略形では指定できない
PTR レコード。ゾーン内の各ホストに 1 つ必要。

マシン名は完全指定する必要がある

(これらのリソースレコードの詳細については、リソースレコードのタイプを参照してください。)

`named.local` ファイル

named.local ファイルではローカルループバックインタフェースのアドレスまたはローカルホストをネットワークアドレス 127.0.0.1 で指定します。このファイル名は、構成ファイル内で指定します。他のファイルと同様、このマニュアルで使われていない名前を付けることもできます。

`named.local` ファイルの設定

named.local ファイルは、ネームサーバーのローカルループバックインタフェースを設定します。

例 5–18 `named.local` ファイルの例

$TTL 5h
; SOA rec
0.0.127.in-addr.arpa. IN SOA sirius.doc.com sysop.centauri.doc.com (
                          1997071401       ;  serial number (YYYYMMDD##)            
                           10800           ;  refresh every 3 hours
                           10800           ;  retry every 3 hours
                           604800          ;  expire after a week
                           86400 )         ;  TTL of 1 day
; Name Servers
0.0.127.in-addr.arpa.      IN  NS     sirius.doc.com
1                          IN  PTR  localhost.

named.local ファイルは通常、次の要素で構成されています。

明示的な TTL (生存期間) セットを持たない、ファイル内の全レコードのデフォルト TTL
1 つの SOA (権限の開始) レコード

SOA レコードは、ゾーンの始まりを示す。named.local データファイルが置かれるホストの名前を含む
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する

サーバー名およびドメイン名は完全指定する必要がある
1 つの PTR レコード。localhost に必要

`$INCLUDE` ファイル

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

たとえば、データファイルに次のような行が含まれているとします。

$INCLUDE /etc/named/data/mailboxes

この行によって、/etc/named/data/mailboxes ファイルがその時点で読み込まれます。この例では、/etc/named/data/mailboxes が、$INCLUDE ファイルです。 $INCLUDE ファイルは、必要に応じて、必要な数だけ使用します。

データファイルのリソースレコード書式

DNS のデーモン in.named によって使用されるすべてのデータファイルは標準リソースレコード書式で書かれます。各 DNS データファイルは、必ずリソースレコードを含む必要があります。ここでは、DNS データファイルと各ファイルに含む必要があるリソースレコードについて説明します。

標準リソースレコード書式

標準リソースレコード書式では、データファイルの各行は、「リソースレコード」(RR) と呼ばれます。リソースレコードには空白で区切られた次のようなフィールドがあります。

namettlclassrecord-typerecord-specific-data

フィールドの順は常に同じですが、最初の 2 行は任意指定 (カッコ付きで示す) です。また、最後は record-type フィールドによって変化します。

`name` フィールド

最初のフィールドは、そのレコードに適用するドメイン名のフィールドです。 RR でこのフィールドが空白のままであれば、デフォルトとして直前の RR の name フィールドの値が用いられます。

ゾーンファイルのドメイン名は、ドットで終わる完全指定名でも、相対名でもかまいません。相対名の場合、現在のドメインが付加されます。

`ttl` フィールド

2 番目のフィールドは、任意指定の有効期限フィールドです。このフィールドでは、データを破棄する前にデータベース内にデータをキャッシュしておく時間 (秒)、すなわちサーバーに新しい情報を次回要求するまでの時間を指定します。このフィールドを空白のままにすると、ttl には、権限の開始 (SOA) リソースレコードで指定された最小時間がデフォルトとして用いられます。

ttl の設定値があまりにも小さいと、サーバーはデータ更新のための要求を頻繁に繰り返します。逆に、ttl の設定値があまりにも大きいと、情報の変更がタイムリーに反映されなくなります。

ほとんどの場合、ttl の値は、初期値として 1 日 (86400) から 1 週間 (604800) の間に設定するとよいでしょう。そのあとで、実際の情報の変更の頻度にあわせて ttl の値を適切な値に変更してください。また、ほとんど変化することがないデータと関連しているということで ttl の値を大きく設定していた場合、そのデータが変更されるとわかった時点で、ttl の値を、データの変更が行われるまで小さな値 (3600 - 86400) にし、その後またもとの大きな値に戻すこともできます。

同じ名前、クラス、タイプを持つすべての RR では、ttl は同じ値に設定してください。

`class` フィールド

3 番目のフィールドは、レコードのクラスです。現在のところ、1 つのクラスだけがあります。それは、TCP/IP プロトコルのファミリーであることを示す IN です。

`record-type` フィールド

4 番目のフィールドでは、リソースレコードのタイプを記述します。 RR にはたくさんのタイプがあります。最も一般的に使用されるタイプは、リソースレコードのタイプに説明されています。

`record-specific-data` フィールド

record-specific-data フィールドの内容は、そのリソースレコードのタイプによって異なります。

ネームフィールドとデータフィールドの大文字と小文字の区別は、ネームサーバーに読み込まれたときには保存されていますが、ネームサーバーのデータベースを比較して検索する際には大文字と小文字の区別はしません。ただし、これは将来的には変更される可能性がありますので、大文字と小文字の使用に関しては一貫性を保つように心がけてください。

特殊なリソースレコード文字

次に挙げる文字には特別な意味があります。

表 5–5 特殊なリソースレコード文字


文字	定義
`.`	ネームフィールドで、1 つのドットだけが指定された場合は現在のドメインを指す
`@`	ネームフィールドで、1 つの `@` だけが指定された場合は現在の起点を示す
`..`	2 つのドットがネームフィールドに指定された場合は NULL ドメイン名を表す
`\X`	`X` は数字 (0 - 9) 以外の任意の文字で、\ を付けることによって文字に特別な意味を持たせないようにする。たとえば、`\.` と指定して、ラベルにドット文字を入れることができる
`\DDD`	各 `D` は一桁の数字で、\ を付けることによって `DDD` で表される 10 進数に対応する 8 進数を表現する。結果的に得られる 8 進数は、テキストとみなされ、そのテキストに特別な意味があるかどうかはチェックされない
`()`	データが 1 行に収まらないとき、データをグループ化するのにカッコを使用する。結果的に、カッコの間では行の終わりが認識されない
`;`	セミコロンでコメントが開始する。その行でセミコロン以降は無視される
`*`	アスタリスクはワイルドカードを表す

ほとんどのリソースレコードには、現在の起点があり、名前の最後にドット (.) が付いていなければ、現在の起点が名前に追加されます。この機能は、マシン名などのデータに現在のドメイン名を追加する際には便利ですが、追加したくない場合には、問題を引き起こす可能性があります。データファイルを作成しているドメイン内に名前がない場合は、ピリオドで終わる完全指定名を使用してください。

制御エントリ

データファイルで制御エントリの行だけは標準 RR 書式に従わない行です。制御エントリには、 $INCLUDE() と $ORIGIN() の 2 つのタイプがあります。

`$INCLUDE` エントリ

インクルード行は 1 列目の $INCLUDE で始まり、その後にファイル名 ($INCLUDE ファイル) が続きます。次の例に示すように、この機能は異なるタイプのデータを複数のファイルに分けるのに特に便利です。

$INCLUDE /etc/named/data/mailboxes

この行は、/etc/named/data/mailboxes ファイルを読み込む要求として解釈されます。 $INCLUDE コマンドでは、異なるゾーンまたはツリーにデータは読み込まれません。このコマンドを使用しても、あるゾーンのデータが別々のファイルに格納されるだけです。たとえば、メールボックスのデータはこの機能を使ってホストデータとは別に保存できます。

$INCLUDE の文とファイルは、必要に応じて、必要な数だけ使用できます。

`$ORIGIN()` エントリ

$ORIGIN() コマンドによって、データファイル内の起点を変更できます。この行は 1 列目から始まり、ドメイン名が続きます。これによって、相対ドメイン名 (たとえば、完全指定されていないドメイン名) の現在の起点を指定の名前に変更します。これは、1 つのデータファイルに複数のドメインを入れるのに便利です。

注 –

1 つのデータファイルに複数のゾーンを入れるために $ORIGIN() を使うことはできません。

$ORIGIN() コマンドは、必要に応じて必要な数だけデータファイルで使用できます。 $ORIGIN() 文がない場合、DNS データファイルのデフォルトの起点は、named.conf ファイルの master または slave の各行の 2 番目のフィールドに指定されているドメイン名となります。

リソースレコードのタイプ

表 5–6 一般的に使用されるリソースレコードのタイプ


形式	説明
`SOA`	権限の開始
`NS`	ネームサーバー
`A`	インターネットアドレス (名前からアドレス)
`PTR`	ポインタ (アドレスから名前)
`CNAME`	正規名 (ニックネーム)
`TXT`	テキスト情報
`WKS`	既知サービス
`HINFO`	ホスト情報
`MX`	メール交換

権限の開始レコード (`SOA`)

例 5–19 に権限の開始 (SOA) リソースレコードの構文を示します。

例 5–19 `SOA` レコードの書式

name class SOA origin person-in-charge ( 
    serial number
    refresh
    retry
    expire
    ttl)

SOA レコードは、ゾーンの開始を示します。次の SOA レコードでそのゾーンは終了します。以下に、SOA レコードの各フィールドについて説明します。

`name` フィールド

ゾーン名を指定するフィールドです。ゾーン名の後にはドットを付ける必要があります。たとえば、 doc.com. は正しいですが、doc.com は誤りです。

`class` フィールド

アドレスクラスのフィールドです。たとえば IN はインターネットを示し、最も一般的に用いられるクラスです。

`SOA` フィールド

このリソースレコードのタイプを示します。

`origin` フィールド

このデータファイルが存在するホスト名のフィールドです。ホスト名の後にはドットを付ける必要があります。たとえば、dnsmaster.doc.com. は正しいですが、dnsmaster.doc.com は誤りです。

`person-in-charge` フィールド

ネームサーバーの責任者のメールアドレスのフィールドです。たとえば、kjd.nismaster.doc.com. です。この名前も終わりにドットを付ける必要があります。

`serial` フィールド

データファイルのバージョン番号のフィールドです。データを変更するたびにこの番号を増やしてください。スレーブサーバーは serial フィールドを使って、最後にマスターサーバーからデータファイルをコピーしてから変更があったかどうかを検出します。

`refresh` フィールド

更新が必要かどうかを調べるためにスレーブネームサーバーがマスターネームサーバーをチェックする頻度を秒単位で指定します。たとえば、7200 は 2 時間を意味します。

`retry` フィールド

リフレッシュのためのチェックに失敗した後、スレーブサーバーが再試行する時間を秒単位で指定します。

`expire` フィールド

リフレッシュが頻繁に行われない場合に、データの期限が切れる前に、スレーブネームサーバーがそのデータを使用する上限の時間を秒単位で指定します。

`ttl` フィールド

リソースレコードの time-to-live フィールドで使用されるデフォルトの秒数を指定します。このデフォルト値はリソースレコードで他に ttl が指定されていないときに適用されます。

SOA レコードは、各ゾーンに 1 つだけ指定してください。例 5–20 に、SOA リソースレコードの例を示します。

例 5–20 `SOA` リソースレコードの例

;name class 		SOA 	origin				 person-in-charge
doc.com. IN		SOA	dnsmaster.doc.com. root.nismaster.doc.com. (
							101			;Serial
							7200		;Refresh
							3600		;Retry
							432000		;Expire	
							86400)		;Minimum			 )

ネームサーバー (`NS`)

例 5–21 に、ネームサーバー (NS) リソースレコードの構文を示します。

例 5–21 `NS` レコードの書式

domainname [optional TTL]  class NS name-server-name

ネームサーバーレコードは、対象としているドメインを受け持つサーバーの名前を示します。 name フィールドには、指定したネームサーバーからサービスを受けるドメインを指定します。 name フィールドを指定しない場合は、デフォルトで、最後に指定された名前になります。 NS レコードは、そのドメインのマスターサーバーとスレーブサーバーにそれぞれ 1 つずつ必要です。例 5–22 に、NS リソースレコードの例を示します。

例 5–22 `NS` リソースレコードの例

;domainname    [TTL] 	 class	NS	nameserver
doc.com        90000     IN	NS 	sirius.doc.com.

アドレス (`A`)

例 5–23 に、アドレス (A) リソースレコードの構文を示します。

例 5–23 アドレス (`A`) レコードの書式

	
machinename	[optional TTL] class A	address

A レコードは、対象としているマシンのアドレスを示します。 name フィールドは、ホスト名のフィールドです。address は、IP アドレスです。 A レコードは、マシンの各アドレスに 1 つ必要です。つまり、ルーターやゲートウェイには 2 つ以上のエントリが必要で、IP アドレスを含む個々のエントリが各ネットワークインタフェースに割り当てられます。

例 5–24 アドレスレコードの例

;machinename	[TTL]	class	A	address
sirius		IN		A	123.45.6.1

ホスト情報 (`HINFO`)

例 5–25 に、ホスト情報 (HINFO) リソースレコードの構文を示します。

例 5–25 `HINFO` レコードの書式

[optional name] [optional TTL] 	class	HINFO hardware	OS

HINFO には、ホスト固有のデータが含まれ、ハードウェアとこのホストで動作しているオペレーティング環境を指定します。マシン名や hardware フィールドのエントリに空白を含めるには、エントリを引用符で囲む必要があります。 name フィールドでは、ホスト名を指定します。名前が指定されなければ、in.named での最後のホストがデフォルトになります。 HINFO レコードは、各ホストに 1 つ必要です。例 5–26に、HINFO リソースレコードの例を示します。

例 5–26 `HINFO` リソースレコードの例

;[name]   [TTL] class HINFO   hardware    OS
                IN    HINFO   Sparc-10    UNIX

注意 –

HINFO フィールドにはネットワーク上のマシンについての情報が含まれているので、多くのサイトでは、この情報はセキュリティ上危険であると考えられ、現在はほとんど使われていません。

既知サービス (`WKS`)

例 5–27 に、既知サービス (WKS) リソースレコードの構文を示します。

例 5–27 `WKS` レコードの書式

[Optional name] [TTL]  class WKS address protocol-list-of-services

WKS レコードは、指定されたアドレスの特定のプロトコルでサポートされているよく知られたサービスを示します。サービスのリストとポート番号は、services データベースで指定されたサービスのリストから得られます。 WKS レコードは、各アドレスの各プロトコルに 1 つだけ存在している必要があります。例 5–28 に、WKS リソースレコードの例を示します。

例 5–28 `WKS` リソースレコードの例

;[name]	[TTL]	class	WKS	address 	 protocol-list-of-services
altair		IN	WKS	123.45.6.1	 TCP ( smtp discard rpc
 sftp uucp-path systat daytime
 netstat qotd nntp doc.com )

注意 –

WKS レコードは任意指定です。セキュリティ上の理由から、ほとんどのサイトでは現在この情報は提供していません。

正規名 (`CNAME`)

例 5–29 に、正規名 (CNAME) リソースレコードの構文を示します。

例 5–29 `CNAME` レコードの書式

 nickname [optional TTL] class CNAME	canonical-name

CNAME は、正規名のニックネームまたはエイリアスを示します。ニックネームは一意である必要があります。他のすべてのリソースレコードは、ニックネームではなく正規名と結びつけるようにする必要があります。ニックネームを作成して他のリソースレコードで使用することはしないでください。ニックネームは、マシン名が変更されたけれども古い名前でのアクセスを許可する移行期に特に有用です。また、ニックネームはメールサーバーなど特定の目的で使用するマシンを識別するためにも使用できます。例 5–30に、CNAME リソースレコードの例を示します。

例 5–30 `CNAME` リソースレコードの例

;nickname      [TTL]	class	CNAME	canonical-name
mailhost		IN	CNAME	antares.doc.com

ポインタレコード (`PTR`)

例 5–31 に、PTR リソースレコードの構文を示します。

例 5–31 `PTR` レコードの書式

 special-name	[optional TTL]  class	 PTR-real-name

ポインタレコードを使用すると、特殊な名前でドメイン内の他の場所を指すことができます。次の例では、アドレス (特殊な名前) を実名に変換するために PTR は主に in-addr.arpa. レコードで使用されます。アドレスを解釈するときはドメインが完全指定であれば、指定する必要があるのはマシンの識別番号だけです。 PTR の名前は、ゾーンに対して一意である必要があります。例 5–32の PTR レコードでは、特殊なドメイン in-addr.arpa に対して逆ポインタを設定します。

例 5–32 `PTR` リソースレコードの例

;special name   [TTL]	class	PTR-real-name
1			IN	PTR sirius.doc.com.

メール交換 (`MX`)

例 5–33 に、メール交換 (MX) リソースレコードの構文を示します。

例 5–33 `MX` レコードの書式

name [optional TTL] class	MX preference-value mailer-exchanger

MX リソースレコードは、あるドメインまたはドメイン内の特定のマシンにメールを配信するマシンを指定するために使用します。対象としている名前に対して複数の MX リソースレコードが作成される場合もあります。例 5–34 では、Seismo.CSS.GOV Seismo.CSS.GOV (完全指定のドメイン名) は、Munnari.OZ.AU にメールを配信するメールゲートウェイです。ネットワーク上の他のマシンは、Munnari に直接メールを配信できません。 Seismo と Munnari は、専用接続を持っている場合も、異なるトランスポート媒体を使用している場合もあります。 preference-value フィールドでは、メールプログラムが従う順序を指定します。このフィールドは、単一のマシンにメールを配信する方法が複数ある場合に指定します。値が 0 (ゼロ) は最優先であることを意味します。同じ名前に対して複数の MX リソースレコードがある場合、そのレコードの優先値 (preference-value) は同じであることも、同じでないこともあります。

メールを配信するために、MX レコードでワイルドカードであるアスタリスク ( *) を名前に使うこともできます。あるドメイン宛のメールがすべてリレー経由で配信されるサーバーがネットワーク上にはよくあります。例 5–34 では、foo.com ドメイン内のホスト宛のメールはすべて RELAY.CS.NET. を経由して送られます。これを指定するには、ワイルドカードを用いて MX リソースレコードを作成し、*.foo.com のメール交換が RELAY.CS.NET. により行われることを指定します。アスタリスクは foo.com のどのホストまたはサブドメインにも一致します。ただし、foo.com 自体には一致しません。

例 5–34 `MX` リソースレコードの例

;name	 	[TTL]	class		MX	 preference mailer-exchanger
Munnari.OZ.AU.		IN		MX	 0	Seismo.CSS.GOV.
foo.com.		IN		MX	 10	RELAY.CS.NET.
*.foo.com.		IN		MX	 20	RELAY.CS.NET.

第 6 章 DNS の障害追跡 (参照情報)

この章では、DNS に関する一般的な問題とその解決方法について説明します。

クライアントは名前でマシンを見つけられるが、サーバーは見つけられない

「症状」

DNS クライアントは、IP アドレスかホスト名でマシンを見つけられますが、サーバーは IP アドレスでしか見つけることができません。

「考えられる原因と対策」

サーバーの nsswitch.conf ファイルの hosts 行から DNS を省略したために発生する可能性があります。たとえば、不完全な hosts 行は次のようになります。 hosts:files

DNS の使用時は、各マシンの nsswitch.conf ファイルの hosts レコード内に dns を入れる必要があります。たとえば、

hosts: dns nisplus files

または、

hosts: nisplus dns files

変更が反映されないか、その効果が一定しない

「症状」

マシンやサーバーを追加または削除しても、変更が認識されないか反映されません。あるいは、変更が認識されたり認識されなかったりします。

「考えられる原因」

考えられる最初の原因は、変更を加えた後にマスターサーバー上の SOA のシリアル番号を増やし忘れたことです。新しいSOA 番号がないので、スレーブサーバーはそのデータをマスターサーバーのデータと一致させるためのデータ更新を行いません。このため、古い未変更のデータファイルを使用しています。

この他に考えられる原因は、マスターサーバー上の 1 つ以上のデータファイルの SOA のシリアル番号が、スレーブサーバー上の対応するシリアル番号よりも小さい値に設定されたことです。この状態はたとえば、マスターサーバー上のファイルを削除してから、ある種の入力ファイルを使って最初から作成し直した場合に発生します。

考えられる 3 番目の原因は、主サーバーのデータファイルへの変更を行なった後に、HUP 信号をマスターサーバーに送信し忘れた場合です。

「診断と対策」

まず、変更したデータファイルの SOA のシリアル番号とスレーブサーバー上の対応するファイルをチェックします。

マスターサーバーのファイルの SOA シリアル番号がスレーブサーバーのファイルのシリアル番号と同じかそれ以下の場合は、マスターサーバーのファイルのシリアル番号を増やしてスレーブサーバーのファイルの番号よりも大きくなるようにします。たとえば、両方のファイルの SOA のシリアル番号が 37 の場合は、主サーバーのファイルの番号を 38 に変更します。次回、スレーブサーバーがマスターサーバーをチェックすると、新しいデータがロードされます。マスターサーバーに、スレーブサーバーへのデータ転送を即座に強制するユーティリティがあります。このユーティリティがある場合には、マスターサーバーのチェックを待たずにスレーブサーバーを更新できます。
最新の named nnnn restarted または、named nnn reloading nameserver エントリに対する syslog 出力を確認します。そのエントリのタイムスタンプが、ファイルへの変更を終了した時間よりも前の場合には、サーバーをリブートするか、in.named に DNS データを強制的に再度読み込ませる方法で説明しているように、新しいデータの読み取りを強制します。

DNS クライアントが短縮名を検索できない

「症状」

クライアントは完全指定名は検索できますが、短縮名は検索できません。

「考えられる原因と対策」

クライアントの /etc/resolv.conf ファイルで、ドメイン名の最後にスペースがないかをチェックします。スペースやタブはドメイン名の最後では使用できません。

逆ドメインデータがスレーブサーバーに正しく転送されない

ゾーンのドメイン名の付いたデータは、ゾーンのマスターサーバーからゾーンのスレーブサーバーに正しく転送されますが、逆ドメインデータは転送されません。つまり、スレーブサーバーの host.rev ファイルがマスターサーバーから正しく更新されていません。

「考えられる原因」

スレーブサーバーの構成ファイルの構文エラー

「診断と対策」

スレーブサーバーの構成ファイルを検査します。マスターサーバーの IP アドレスが、ホストデータの場合と同じように、逆ゾーンエントリに対してリストされていることを確認してください。

サーバーが失敗してゾーンが期限切れになる

スレーブサーバーがそのマスターサーバーから更新を得られないときは、「master unreachable」というメッセージがログに記録されます。問題が修正されない場合、スレーブサーバーはゾーンを期限切れにして、クライアントからの要求への応答を停止します。この状況が発生すると、「server failed」というメッセージが表示されます。

「症状」

syslog 内の「Masters for secondary zone domain unreachable」のメッセージが表示される
syslog に「slave zone domain expired」というメッセージが表示される
ユーザーに「*** domain Can't find name: server failed」というメッセージが表示される

問題がスレーブサーバーにある場合、一部のユーザーはマスターサーバーから DNS 情報を獲得できるため問題なく操作できます。

「考えられる原因」

これらの問題に対して考えられる主な原因は 2 つあります。1 つはネットワーク障害であり、もう 1 つはスレーブサーバーの構成ファイル内に指定したマスターサーバーの IP アドレスが間違っていることです。

「診断と対策」

スレーブサーバーの構成ファイルに、マスターサーバーの IP アドレスが正しく設定されているかどうか確認します。次の行をチェックしてください。
zone "someone" { type slave; file "somefile": master [IPaddress; }; };
hosts ファイルで指定したマスターサーバーの IP アドレスが実際の IP アドレスと一致することを確認してください。 IP アドレスが間違っている場合は、それを修正してからスレーブサーバーをリブートします。
マスターサーバーの IP アドレスが正しい場合は、そのアドレスを ping して、マスターサーバーが正しく起動しているかどうかを確認します。たとえば、マスターサーバーを IP アドレス 192.168.0.1 で ping する場合は、次のように入力します。

% ping 192.168.0.1 -n 10
マスターサーバーが ping に応答しない場合は、マスターサーバーが正しく起動しているかどうかを確認します。
マスターサーバーが正しく起動している場合は、ps を使用して、マスターサーバーが in.named を実行しているかどうかを確認します。 in.named を実行していない場合は、リブートします。
マスターサーバーが in.named を正しく実行している場合は、ネットワークに障害が発生している可能性があります。

`rlogin`、`rsh`、`ftp` の問題

「症状」

インターネットで、別のドメインのマシンに rlogin を試みると、パスワードの入力を求められる
インターネットで、別のドメインのマシンに ftp を試みると、アクセスを拒否される
ローカルネットワーク上のマシンに rlogin や rsh を試みると、アクセスを拒否される

「考えられる原因」

ユーザーが作業しているマシンの PTR レコードがマスターサーバーの hosts.rev ファイルにありません。
hosts.rev ファイル内のサブドメインがないか、不正な委託が行われています。

「診断と対策」

該当する hosts.rev ファイルをチェックして、ユーザーのマシン用の PTR レコードが存在することを確認します。たとえば、192.168.0.1 の IP アドレスを持つマシン altair.doc.com で作業をしている場合は、doc.com マスターサーバーの doc.rev ファイルに次のようなエントリを追加する必要があります。

46 	IN	 PTR 	altair.doc.com.

レコードがない場合は、hosts.rev ファイルに追加してからサーバーをリブートするか、in.named に DNS データを強制的に再度読み込ませる方法の指示に従ってデータをロードし直します。

hosts.rev ファイルの NS エントリをチェックおよび修正してから、サーバーをリブートするか、in.named に DNS データを強制的に再度読み込ませる方法の指示に従ってデータをロードし直します。

その他の DNS 構文エラー

「症状」

次のような表現が含まれるコンソールまたは syslog のエラーメッセージは、たいてい DNS データや構成ファイルの構文エラーによるものです。

No such...
Unknown field...
Non-authoritative answer:
Database format error...
illegal または (illegal)
error receiving zone transfer

関連ファイルにスペルや構文のエラーがないかどうかチェックしてください。

一般的な構文エラーは、ドメイン名で後ろに付く点 (ドット) の誤用 (禁じられている場合に使い、必要な場合に使わないなど) に起因します。 DNS サーバーの設定を参照してください。

パート II DNS の設定と管理

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

DNS の基礎

名前のアドレス解決

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

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

DNS 管理ドメイン

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

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

構成ファイル

DNS データファイルの名前

$INCLUDE ファイル

ドメイン名

デフォルトのドメイン名

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

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

resolv.conf ファイル

named.conf ファイル

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

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

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

DNS 階層とインターネット

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

インターネットへの参加

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

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

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

ゾーンと DNS

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

逆マッピング

in-addr.arpa ドメイン

第 4 章 DNS の管理 (手順)

resolv.conf ファイルの設定

例 4–1 DNS サーバー用 resolv.conf ファイルの例

DNS 用ネットワークの構成

DNS クライアントの設定

例 4–2 resolv.conf ファイルの例

DNS サーバーを設定する方法

マスターサーバーを指定する方法

スレーブサーバーを指定する方法

キャッシュ専用 (スタブ) サーバーを指定する方法

例 4–3 キャッシュ専用サーバーのマスター構成ファイルの例

DNS 互換性と +/- 構文

+/- 構文との DNS 互換性を追加する方法

DNS サーバーの設定

サーバーの初期設定を行う方法

インストール結果を確認する方法

サーバーの追加

DNS データファイルの変更

SOA のシリアル番号を変更する方法

in.named に DNS データを強制的に再度読み込ませる方法

クライアントの追加と削除

クライアントの追加

クライアントの削除

クライアントで IPv6 を使用できるようにする

クライアントで IPv6 を使用できるようにする方法

DNS サブドメインの作成

サブドメインの設計

サブドメインの設定

Solaris DNS BIND 8.3.3 の実装

BIND 4.9.x から BIND 8.3.3 に移行する方法

DNS の転送

NIS+ クライアントで DNS 転送機能を使用できるようにする方法

以前の NIS クライアントで DNS 転送機能を使用できるようにする方法

第 5 章 DNS の管理 (参照情報)

DNS の実装の実例

構成ファイルの例

例 5–1 dnsmastr ネームサーバー用構成ファイルの例

例 5–2 dnssales ネームサーバー用構成ファイルの例

例 5–3 dnssecond ネームサーバー用構成ファイルの例

resolv.conf ファイルの例

例 5–4 dnsmastr サーバー用 resolv.conf ファイルの例

例 5–5 dnssales サーバー用 resolv.conf ファイルの例

例 5–6 dnssecond サーバー用 resolv.conf ファイルの例

named.local ファイルの例

例 5–7 マスターサーバー用 named.local ファイルの例

hosts ファイルの例

例 5–8 dnsmastr サーバー用 db.doc ファイルの例

例 5–9 dnssales サーバー用 db.sales ファイルの例

hosts.rev ファイルの例

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

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

`$INCLUDE` ファイル

`resolv.conf` ファイル

`named.conf` ファイル

`in-addr.arpa` ドメイン

`resolv.conf` ファイルの設定

例 4–1 DNS サーバー用 `resolv.conf` ファイルの例

例 4–2 `resolv.conf` ファイルの例

`SOA` のシリアル番号を変更する方法

`in.named` に DNS データを強制的に再度読み込ませる方法

例 5–1 `dnsmastr` ネームサーバー用構成ファイルの例

例 5–2 `dnssales` ネームサーバー用構成ファイルの例

例 5–3 `dnssecond` ネームサーバー用構成ファイルの例

`resolv.conf` ファイルの例

例 5–4 `dnsmastr` サーバー用 `resolv.conf` ファイルの例

例 5–5 `dnssales` サーバー用 `resolv.conf` ファイルの例

例 5–6 `dnssecond` サーバー用 `resolv.conf` ファイルの例

`named.local` ファイルの例

例 5–7 マスターサーバー用 `named.local` ファイルの例

`hosts` ファイルの例

例 5–8 `dnsmastr` サーバー用 `db.doc` ファイルの例

例 5–9 `dnssales` サーバー用 `db.sales` ファイルの例

`hosts.rev` ファイルの例

例 5–10 `dnsmastr` サーバー用 `hosts.rev` ファイルの例

例 5–11 `dnssales` サーバー用 `hosts.rev` ファイルの例

`named.ca` ファイルの例

例 5–12 `named.ca` ファイルの例

単一ゾーンのサブドメインの設定

複数ゾーンのサブドメインの設定

`named.conf` ファイル

`named.conf` 文

`named.ca` ファイル

`named.ca` ファイルの設定

インターネット `named.ca` ファイル

例 5–14 インターネット `named.ca` ファイルの例

非インターネット `named.ca` ファイル

例 5–15 `named.ca` ファイル (非インターネット) の例

`hosts` ファイル

`hosts` ファイルの設定

例 5–16 `hosts` ファイルの例

`hosts.rev` ファイル

`hosts.rev` ファイルの設定

例 5–17 `hosts.rev` ファイルの例

`named.local` ファイル

`named.local` ファイルの設定

例 5–18 `named.local` ファイルの例

`$INCLUDE` ファイル

`name` フィールド

`ttl` フィールド

`class` フィールド

`record-type` フィールド

`record-specific-data` フィールド

`$INCLUDE` エントリ

`$ORIGIN()` エントリ

権限の開始レコード (`SOA`)

例 5–19 `SOA` レコードの書式

`name` フィールド

`class` フィールド

`SOA` フィールド

`origin` フィールド

`person-in-charge` フィールド

`serial` フィールド

`refresh` フィールド

`retry` フィールド

`expire` フィールド

`ttl` フィールド

例 5–20 `SOA` リソースレコードの例

ネームサーバー (`NS`)

例 5–21 `NS` レコードの書式

例 5–22 `NS` リソースレコードの例

アドレス (`A`)

例 5–23 アドレス (`A`) レコードの書式

ホスト情報 (`HINFO`)

例 5–25 `HINFO` レコードの書式

例 5–26 `HINFO` リソースレコードの例

既知サービス (`WKS`)

例 5–27 `WKS` レコードの書式