サブドメインの設計

ネットワークをひとつの親ドメインと 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 等は、すでに使用されているのでサブドメイン名として使うことはできません。