この章では、DNS の管理方法を説明します。 詳しくは、Cricket Liu、Paul Albitz 著『DNS and Bind』(O'Reilly, 1992) と『Name Server Operations Guide for BIND』, University of California, Berkeley をお読みください。
DNS 関連のファイルで作業する際、ドメイン名の終わりにつけるドットに関しては以下に述べるルールに従ってください。
hosts、hosts.rev、named.ca、 named.local の各データファイル内のドメイン名には sales.doc.com.のように終わりにドットを付ける
named.boot または resolv.conf ファイルのドメイン名には sales.doc.com のように終わりにドットを付けない
マスター DNS サーバー内の DNS データファイルのひとつに対して、ホストの追加および削除、またはそれ以外の何らかの変更、あるいは DNS データファイルの修正を行なったときには、以下のことも行なってください。
副サーバーがそのデータを変更するように、SOA リソースレコードのシリアル番号を変更します (「SOA のシリアル番号の変更」を参照)。
データファイルを再度読み込み、内部データベースを更新するためにマスターサーバーの in.named に情報を与えます (「in.named に DNS データを強制的に再読み込みさせる」を参照)。
すべての DNS データベースファイルには権限の開始 (SOA) リソースレコードがあります。DNS データベースのデータを変更したときはいつでも、SOA シリアル番号を 1 増加させる必要があります。
たとえば、データファイルの SOA のシリアル番号が現在 101 で、ファイルのデータに変更を加えたなら、シリアル番号を 101 から 102 に変更する必要があります。SOA のシリアル番号を変更しないと、ドメインの副サーバーは、新しい情報でデータベースファイルのコピーを更新しません。その結果主サーバーと副サーバーは同期しなくなります。
一般的な SOA レコードの例である hosts ファイルは以下のとおりです。
; 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.boot を再び読み込み、データベースを再度読み込むには、以下のとおり入力します。
# 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 123.45.6.112
主サーバーの hosts ファイルに rigel のためのオプションのレコードを追加します。
オプションのレコードには以下のものがあります。
エイリアス (CNAME)
メール交換 (MX)
よく知られたサービス (WKS)
ホスト情報 (HINFO)
hosts.rev ファイルに rigel のための PTR レコードを追加します。
主サーバーの hosts ファイルと hosts.rev ファイルの SOA シリアル番号を増やします。
サーバーのデータを再ロードします。
サーバーをリブートするか、または以下のとおり入力します。
# kill -HUP `cat /etc/named.pid`
これらの手順は、『Solaris ネーミングの設定と構成』で詳しく説明されています。
DNS ドメインからマシンを取り除く場合は次のように実行します。
削除するマシンの nsswitch.conf ファイルの hosts の行から dns を削除します。
マシンの /etc/resolv.conf ファイルを削除します。
主サーバーの hosts ファイルと hosts.rev ファイルからそのマシンのレコードを削除します。
CNAME レコードがそのマシンにあるなら、その CNAME のレコードも hosts ファイルから削除される必要があります。
削除されるマシンによってサポートされていたサービスの代替を設定します。
マシンが主サーバー、メールホスト、その他必要なプロセスまたはサービスのホストである場合、そのマシンが行なっていたサービスを他のマシンで実行できるように設定する必要があります。
ネットワークに主サーバーや副サーバーを追加できます。DNS サーバーを追加するには、以下のとおりにしてください。
DNS クライアントとしてサーバーを設定します。
詳細は、「マシンの追加」を参照してください。
サーバーのブートファイルを設定します。
サーバーの named.ca ファイルを設定します。
サーバーの hosts ファイルを設定します。
サーバーの hosts.rev ファイルを設定します。
サーバーの named.local ファイルを設定します。
サーバーを初期化します。
サーバーをテストします。
以上の手順については、『Solaris ネーミングの設定と構成』に詳しい説明があります。
ネットワークは大きくなっていくので、ネットワークを複数の DNS サブドメインに分割すると便利です (DNS のドメインの階層と構造については、「DNS 名前空間について」を参照)。
ネットワークを親ドメインとひとつ以上のサブドメインに分割すると、負担が複数のドメインに分散して、各 DNS サーバーの負荷は減ります。この方法で、ネットワークのパフォーマンスを改善できます。たとえば、ネットワークに 900 台のマシンがあり、すべてがひとつのドメインにあるとします。この場合、1 台の主サーバー、1 台以上の副サーバーとキャッシュオンリーサーバーからなる DNS のサーバーの集合は 900 台のマシンをサポートしなければなりません。もし、このネットワークを、各ドメインが 300 台ずつの、1 つの親ドメインと 2 つのサブドメインに分割すると、主サーバーと副サーバーの組は 3 つとなり、それぞれは 300 台だけを担当することになります。
ネットワークを、物理的または組織的な構成に合うように、複数のドメインに分割することによって、DNS ドメイン名は、どこに対象とするマシンがあるか、電子メールのアドレスが組織のどこにあたるのかを指し示すことになります。たとえば、 rigel@alameda.doc.com は、マシン rigel は Alameda というサイトにあることを意味し、電子メールのアドレス barnum@sales.doc.com は、ユーザーの barnum が Sales の部署の者であることを意味します。
ネットワークを複数のドメインに分けると、すべてをひとつのドメインに置く場合よりも設定作業が増えます。また、ドメインを互いにつなぐ委託データを保持しなければなりません。一方で、複数のドメインを持つと、各ドメインの保守をそれぞれの管理者またはチームに分散させることができます。
ネットワークをひとつの親ドメインと 1 つ以上のサブドメインに分割する前に考慮しておくべきポイントをここで述べます。
「サブドメインの数」
作成するサブドメインが多ければ、それだけ初期設定の作業が増え、運用時の親ドメインでの管理者の調整作業も増えます。多くのサブドメインがあれば、親ドメインのサーバーのために委任される作業もその分増加します。一方で、ドメインの数が少ないということは各ドメインが大きいということを意味し、ドメインが大きければ、それをサポートするためにサーバーのスピードやメモリーが余計必要だということです。
「ネットワークの分割方法」
ネットワークはどのようにでも複数のドメインに分割できます。最も一般的な方法が 3 つあります。まず、組織の構成によるもので、各部署 (営業、研究開発、製造、など) に別々のサブドメインを持つ方法です。次に、地理的なもので、各サイトに別々のサブドメインを持つ方法です。最後に、ネットワークの構造によるもので、大きなネットワーク構成要素ごとに別々のドメインを持つ方法です。ドメインの構造が、統一されていて、論理的で、明確であれば、管理も利用もより簡単になります。
「将来に対する考慮」
もっとも問題が多いのは、時間の経過とともに、新しいサイトや部が増えて、サブドメインが無計画に追加されて大きくなったドメインです。可能な限り、将来のドメインの拡大を見越してドメインの階層を設計してください。安定性も考慮に入れてください。最も安定しているものを基礎として、サブドメインが分けられているのがベストです。たとえば、地理的なサイトは比較的安定しているけれども、部や課が頻繁に再編成されるなら、サブドメインは組織よりも地理的な位置に基づいて決定すべきです。一方、組織は比較的安定しているが、サイトが頻繁に追加されたり、変更されたりする場合は、サブドメインは組織に基づいて決定してください。
「広域ネットワーク (WAN) とのリンク」
ネットワークがモデムまたは専用回線で接続された複数のサイトに広がっている場合、広域ネットワーク (WAN) のリンクにドメインが広がっていないなら、パフォーマンスと信頼性は高くなります。WAN のリンクは連続的なネットワーク接続より遅く、失敗に終わる傾向があります。サーバーが、WAN のリンク経由だけで接続できるマシンをサポートしなければならないときは、より遅いリンクを経由するトラフィックファネリングが増加することになります。この場合、もしひとつのサイトで停電や何か他の問題が起こった場合には、相手のサイトのマシンにも影響を及ぼしてしまうかもしれません。(同様のパフォーマンスと信頼性の配慮は 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 ファイルを各マシンにインストールする必要があります。これらのファイルについては、『Solaris ネーミングの設定と構成』を参照してください。
正しく設定されたブートファイルと DNS データファイルをサブドメインの主マスターサーバーにインストールします。
各サーバーに以下のファイルをインストールします (詳細は、『Solaris ネーミングの設定と構成』を参照)。
/etc/named.boot.
/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 レコードを古いドメインサーバーのホストファイルから削除します。また、同じマシンの PTR レコードを古いドメインサーバーの hosts.rev ファイルから削除します。移動するマシンのオプションの HINFO レコードと WKS レコードも、削除する必要があります。
もし、既存のドメインを分割しているなら、新しいサブドメイン名を、親ドメインのマスターサーバーのホストファイル内の CNAME レコードに追加します。
たとえば、aldebaran というマシンをファックスサーバーとして使っているとします。また親ドメインのサーバーのホストファイル内の CNAME レコードが次のとおりであるとします。
faxserver IN CNAME aldebaran
新しい faxserver の CNAME レコードを aldebaran に対して、新しいサブドメインのマスターサーバーにあるホストファイル内に作成するのに加えて、下記のように aldebaran のサブドメインが含まれるように、親ドメインのホストファイル内の CNAME レコードも変更する必要があります。
faxserver IN CNAME aldebaran.manf.doc.com
新しいサブドメインのサーバーの NS レコードを、親ドメインのホストファイルに追加します。
たとえば、親ドメインは doc.com で、manf.doc.com という新しいサブドメインを作成しているとします。また、この時 rigel というマシンを manf のマスターサーバーとして aldebaran を副マスターサーバーとして指定するとします。すると、以下に示すレコードを aldebaran の主マスターサーバーのホストファイルに追加することになります。
manf.doc.com 99999 IN NS rigel.manf.doc.com 99999 IN NS aldebaran.manf.doc.com
新しいサブドメインのサーバーの A レコードを、親ドメインのホストファイルに追加します。
引き続き上の例で考えると、以下に示すレコードを doc.com の主マスターサーバーのホストファイルに追加することになります。
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 を実行する代わりに、リブートもできます。詳細は、『Solaris ネーミングの設定と構成』を参照してください。
DNS の問題解決とエラーメッセージに関しては、付録 A 「問題と解決方法」
と付録 B 「エラーメッセージ」 を参照してください。