この章では、DNS (Domain Name System) の管理方法について説明します。
この章の内容は次のとおりです。
ここでは、doc.com ドメインのサーバーで使用する簡単な 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 docs.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 サーバーを設定する前に、クライアントを設定します。
スーパーユーザーになります。
/etc/resolv.conf ファイルを作成します。
次に、doc.com ドメインのクライアント (非サーバー) マシン用の簡単な resolv.conf ファイルの例を示します。
; Sample resolv.conf file for the machine polaris domain doc.com ; try local name server nameserver 10.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 10.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+ の場合は、次の手順に従います。
/etc/nsswitch.conf ファイルをオープンします。
DNS は、ホスト情報のソースとして、「唯一の」ソースとしても「追加の」ソースとしても使用できます。hosts を見つけ、次のように DNS を使用します。
hosts: files dns |
または、
hosts: nis dns [NOTFOUND=return] files |
または、
hosts: dns nis [NOTFOUND=return] files |
NIS クライアントの場合は、上記の指定をしないでください。この指定をすると、名前を見つけることができない場合に 2 度 DNS から検索することになります。
ホスト情報のソースとして DNS を指定します。
ファイルを保存してリブートします。
スーパーユーザーになります。
サーバーを DNS クライアントとして設定します。これには、サーバーの resolv.conf ファイルの設定も含まれます。詳細については、DNS クライアントの設定を参照してください。
起動ファイルを設定します。詳細については、起動ファイルの例を参照してください。
データファイルを設定します。次の 4 つのデータファイルを設定する必要があります。
named.ca
hosts
hosts.rev
named.local
サーバーの初期設定を行います。詳細については、サーバーの初期設定を行う方法を参照してください。
サーバーをテストします。詳細については、インストール結果を確認する方法を参照してください。
DNS の最も一般的な役割は、ローカルなネットワークをインターネットに接続することです。インターネットに接続するためには、親ドメインの管理者にネットワークの IP アドレスを登録してもらう必要があります。管理者は、ネットワークの地理的な位置と親ドメインの種類によって異なります。ドメイン管理者にネットワークを登録してもらう方法については、本書では説明をしていません。
マスターサーバーには、次の 2 つの種類があります。
「ゾーンマスターサーバー」。各ゾーンには、そのゾーンの「マスター」サーバーが 1 つあります。ゾーンのマスターサーバーは、そのゾーンの「正規」サーバーです。
「ゾーンスレーブサーバー」。 ゾーンには、1 つ以上の「スレーブ」マスターサーバーがあります。「スレーブ」マスターサーバーは、その DNS データをゾーンのマスターサーバーから入手します。
サーバーをある特定のゾーンのマスターサーバーに指定する場合は、そのサーバーの named.boot ファイルに 3 つのマスターレコードを作成します。
ゾーンの「マスター」レコードを作成します。
このレコードは、サーバーをゾーンのマスターサーバーとして指定し、正規の hosts ファイルの場所をサーバーに示します。この「マスター」レコードは、次の 3 つのフィールドで構成されます。
第 1 フィールド - サーバーを「マスター」サーバーとして指定する
第 2 フィールド - 「マスター」サーバーが機能するゾーンを指定する
次に示す起動ファイルの行は、あるサーバーを doc.com ゾーンで「マスター」サーバーとして使い、正規の hosts ファイルとして db.doc を使うことを示すものです。
master doc.com db.doc |
このレコードは、そのサーバーを逆アドレスマッピング (つまり、doc.com の逆アドレスドメイン) の「マスター」サーバーとして使うことを指定し、正規の hosts ファイルの場所を示すものです。この「マスター」レコードは、次の 3 つのフィールドで構成されます。第 1 フィールドではサーバーを「マスター」サーバーとして指定します。第 2 フィールドでは対象のゾーンを指定します。第 3 フィールドでは hosts.rev ファイルを指定します。
あるゾーンにおける逆アドレスドメインは、そのゾーンにおける IP アドレスを逆にならべ、最後に in-addr.arpa を配したものです。たとえば、doc.com ゾーンの IP アドレスが 10.0.0. だとすると、逆アドレスドメインは 0.0.10.in-addr.arpa になります。
次に示す起動ファイルの行は、そのサーバーを doc.com ゾーンの逆アドレスドメインで「マスター」サーバーとして使い、正規の hosts ファイルとして doc.rev を使うことを示すものです。
master 0.0.10.in-addr.arpa doc.rev |
ローカルループバックインタフェースまたはホストの逆アドレス関連の「マスター」レコードを作成します。
このレコードは、そのサーバーをループバックホストの「マスター」サーバーとして使うことを指定し、正規の hosts ファイルの場所を示すものです。この「マスター」レコードは、次の 3 つのフィールドで構成されます。第 1 フィールドではサーバーを「マスター」サーバーとして指定します。第 2 フィールドではループバックホストの逆アドレスを指定します。第 3 フィールドでは hosts ファイルを指定します。
ループバックホストは常に、0.0.10.in-addr.arpa といった書式で識別されます。
次に示す起動ファイルの行は、そのサーバーをループバックホストの逆アドレスドメインで「マスター」サーバーとして使い、正規の hosts ファイルとして named.local を使うことを示すものです。
master 0.0.10.in-addr.arpa named.local |
「スレーブ」サーバーは、ゾーンに関するデータのコピーを保持しています。 マスターサーバーはそのデータをスレーブサーバーに送り、権限を任せます。クライアントは、DNS 情報をスレーブサーバーに照会できます。スレーブサーバーを使用することによって、負荷が複数のマシンに分散され、応答時間を短縮することができます。スレーブサーバーは、マスターサーバーがクラッシュしたときのバックアップも提供します。
in.named の起動時に、デーモンは所定のゾーンに関するすべてのデータをマスターサーバーに要求します。その後、マスターサーバーがデータベースを更新する必要があるかどうかを調べるため、スレーブサーバーはマスターサーバーを定期的にチェックします。最新のゾーンデータベースをマスターサーバーからスレーブサーバーに送信するプロセスを「ゾーン転送」と呼びます。このため、スレーブサーバー上のデータファイルを変更するのではなく、ゾーンのマスターサーバー上のデータファイルを変更します。その後、スレーブサーバーのファイルがマスターサーバーから更新されます。
サーバーを所定のゾーンのスレーブサーバーに指定する場合は、そのサーバーの named.boot ファイルに「スレーブ」レコードを作成します。別々のレコードで、サーバーをそのゾーン、逆アドレスドメイン、およびループバックホストのスレーブサーバーとして指定できます。
この「スレーブ」レコードは、次の3 つのフィールドで構成されます。
第 1 フィールド - サーバーを「スレーブ」サーバーとして指定する
第 2 フィールド - 対象のゾーンを指定する
第 3 フィールド - そのゾーンのマスターサーバーの IP アドレスを指定する。スレーブサーバーはマスターサーバーから正規データを取得する
「スレーブ」レコードでは、必須フィールドに続けて 1 つまたは複数の任意指定のフィールドを設けることができます。任意指定のフィールドには次の種類があります。
「スレーブサーバー」
マスターサーバーの IP アドレスに続けて、他のスレーブサーバーの IP アドレスを指定できます。この指定により、スレーブサーバーがデータを入手できるソースが増えます。一方、状況によっては、スレーブサーバーの IP アドレスを指定することで、パフォーマンスが低下することも考えられます (IP アドレスがマルチホームマスターサーバーの別のネットワークアドレスである場合を除く)。
「バックアップファイル」
マスターサーバーおよび任意指定のスレーブサーバーの IP アドレスに続けて、バックアップ用 hosts ファイルの名前を指定します。バックアップファイル名が存在する場合、スレーブサーバーはそのファイルからデータをロードし、続いてマスターサーバーおよび任意指定のスレーブサーバーをチェックしてバックアップファイルのデータが最新のものであるかどうかを確認します。バックアップファイルが最新ではない場合、マスターサーバーから受け取った情報に基づいてファイルが更新されます。
次に示す起動ファイルの行は、サーバーを doc.com ゾーンとその逆アドレスドメインのスレーブサーバーとして使うことを示します。さらに、そのスレーブサーバーが IP アドレス 172.16.0.1 のマスターサーバーから正規データを受け取り、サーバー 172.16.0.2 をゾーンデータのスレーブ情報源として使い、最初に doc.com.backup ファイルからデータをロードすることを示します。
slave doc.com 129.146.168.119 192.146.168.38 doc.com.bakup slave 4.0.32.128.in-addr.arpa 129.146.168.119 |
上記のサンプル起動ファイル行は、サーバー dnsslave (IP アドレス 192.146.168.38 の sirius マシンのエイリアス) の起動ファイルに対応しています。
1 台のサーバーは、1 つまたは複数のゾーンのマスターサーバーとして機能でき、さらに 1 つまたは複数のゾーンのスレーブサーバーとしても機能できます。起動ファイル内のエントリの組み合わせによって、サーバーがマスターサーバーになるかスレーブサーバーになるかが決まります。
DNS データのキャッシュを保持するという意味では、すべてのサーバーが キャッシュサーバーであるといえます。キャッシュ専用 (スタブ) サーバーは、in-addr.arpa. ドメイン以外のどのゾーンのマスターサーバーでもないサーバーです。
キャッシュ専用サーバーは正規データは一切保持しません。キャッシュ専用サーバーは、in.named ファイルにリストされているホストに必要な情報を問い合わせることで照会を行います。つまり、キャッシュ専用サーバーは照会を行いますが、正規データそのものは一切保持しません。
次に、キャッシュ専用サーバーの起動ファイルの例を示します。
; ; Sample named.boot file for caching-only name server ; ; type domain source file or host ; directory /var/named cache . named.ca master 0.0.127.in-addr.arpa named.local |
サーバーをキャッシュ専用サーバーとして指定するための行は特に必要ありません。起動ファイル内に slave または master など、権限に関する行がないということが、キャッシュ専用サーバーであると判断する根拠になります。
ただし、以下が必要です。
起動ファイルの directory 行
起動ファイルの master 0.0.127.in-addr.arpa 行
起動ファイルの cache . named.ca 行
この節では、マスターネームサービスとして NIS または NIS+ を使用する場合に、+/- 構文を使用する方法について説明します。
スーパーユーザーになります。
/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 ファイルが更新されたかどうかをチェックしないものがあります。このため、マシンをリブートして、これらの関数が最新情報を保持するようにする必要があります。
サーバーの初期設定を行う場合は、次の手順に従います。
スーパーユーザーになります。
前出の節の説明に従って、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 ファイルに正しく設定されていない可能性があります。
インターネットに接続されているネットワークの場合、遠隔ドメイン名を検索します。インターネットに接続されていないネットワークの場合は、他のゾーンにサブドメインがあれば、その名前を検索します。
たとえば、インターネット上の遠隔ドメイン名 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 データファイルを修正する場合は、常に以下の操作も実行してください。
スレーブサーバーがそのデータを変更するように、SOA リソースレコードのシリアル番号を変更します (SOA のシリアル番号を変更する方法を参照)。
データファイルを再度読み込んで内部データベースを更新するようにマスターサーバーの in.named に情報を与えます (in.named に DNS データを強制的に再度読み込ませる方法 を参照)。
すべての DNS データベースファイルには権限の開始 (SOA) リソースレコードがあります。DNS データベースのデータを変更したときは必ず、SOA シリアル番号を 1 増加させる必要があります。
たとえば、データファイルの SOA のシリアル番号が現在 101 で、ファイルのデータに変更を加えた場合は、シリアル番号を 101 から 102 に変更する必要があります。SOA のシリアル番号を変更しないと、ドメインのスレーブサーバーは新しい情報でデータベースファイルのコピーを更新しません。その結果、マスターサーバーとスレーブサーバーが同期しなくなります。
hosts ファイル例の一般的な SOA レコードは、以下のとおりです。
; 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 が無事起動すると、デーモンはそのプロセス ID を /etc/named.pid ファイルに書き込みます。in.named で named.conf を再び読み込み、データベースを再度読み込ませる場合は、次の手順に従います。
この操作によって、以前のキャッシュはすべて削除され、キャッシュの処理が再スタートします。
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 ファイルから削除する必要があります。
削除されるマシンによってサポートされていたサービスの代替を設定します。
マシンがマスターサーバーまたは必要なプロセスまたはサービスのホストである場合、これらのサービス実行する別のマシンを設定する必要があります。
スーパーユーザーになります。
/etc/nsswitch.conf ファイルを編集します。
新しい ipnodes ソースを追加して、ネームサービス (LDAP など) を指定します。
ipnodes: ldap [NOTFOUND=return] files |
ipnodes は、デフォルトでは files です。IPv4 から IPv6 への変更中すべてのネームサービスが IPv6 のアドレスを認識できるわけではないので、 デフォルトの files を使用してください。デフォルトを使用しない場合は、アドレスの解決中に不必要な遅延が生じることがあります。
ファイルを保存して、マシンをリブートします。
nscd デーモンはこの情報をキャッシュに保存するため、マシンをリブートする必要があります。
ネットワークは大きくなっていくので、ネットワークを複数の 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 で、manf.doc.com という新しいサブドメインを作成しているとします。また、このとき rigel というマシンを manf のマスターサーバーとして指定し、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 |
サブドメインのサーバー上の named を起動します。
# /usr/sbin/in.named
コマンド行から in.named を実行する代わりに、リブートします。in.named と DNS ネームサーバーを参照してください。
Solaris オペレーティング環境では、コンパイル版の Berkeley Internet Name Domain (BIND) 8.3.3 を提供します。このバージョンの BIND には、BIND バージョン 8.3.4 に組み込まれるセキュリティ上の修正が含まれています。コンパイルにあたっては、より多くのサイトのニーズを満たすように各種オプションを設定しました。このコンパイル済みの BIND が要件に合わない場合は、公開されているソースコードから独自にコンパイルすることができます。
Solaris オペレーティング環境で提供される BIND バージョンのコンパイルでは、以下の選択が行われました。
「デフォルトのドメイン名」。DNS ドメイン名が /etc/resolv.conf 内または LOCALDOMAIN
環境変数で設定されていない場合、libresolv() は DNS ドメイン名を NIS または NIS+ ドメイン名から引用します。
「ユーティリティスクリプト」。BIND のユーティリティスクリプトは、今回の Solaris リリースには含まれていません。
「テストプログラム」。BIND のテストプログラムである dnsquery および host は、今回の Solaris リリースには含まれていません。これらのテストプログラムの目的は、nslookup と nstest の目的と同様であるためです。
Solaris 9 リリースでは、named.boot ファイルは無視されます。
スーパーユーザーになります。
DNS 構成ファイルを変換します。
Korn シェルスクリプト /usr/sbin/named-bootconf を実行し、BIND 4.9.x の named.boot ファイルを BIND 8.3.3 の named.conf ファイルに変換します。
nsswitch.conf ファイルは、クライアントの DNS 転送とインターネットへのアクセスを管理します。NIS クライアントには、転送機能が含まれています。NIS+ クライアントにはこの機能がありません。次の手順を参照してください。
この NIS 実装では、該当するサーバー上に /etc/resolv.conf ファイルが存在する場合は、ypstart が -d オプションで「自動的に」 ypserv デーモンを起動して DNS に要求を転送します。DNS への転送を停止する場合は、/usr/lib/netsvc/yp/ypstart スクリプトを編集して、-d オプションを ypserv コマンドから削除してください。その後マシンをリブートする必要があります。
スーパーユーザーになります。
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.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 オペレーティング環境には、リゾルバを構成している動的ライブラリ関数が含まれています。