サブドメインの設計

次に、ネットワークを 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 などは、サブドメイン名として使うことはできません。