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

第 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 オペレーティング環境には、リゾルバを構成している動的ライブラリ関数が含まれています。

第 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 転送機能を使用できるようにする方法

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

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

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

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

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