ネットワークは大きくなっていくので、ネットワークを複数の 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 ネーミングの設定と構成』を参照してください。