サブドメインの運用と委任：実用 BIND 9で作るDNSサーバ（6）（1/3 ページ）

　前回は、分散システムの重要な概念の1つである「ゾーン転送」を紹介しました。今回は、ドメインの分散管理に大変重要な役割を果たす「委任」の仕組みとそれを使ったサブドメインの運用について解説します。

委任の概念とサブドメインの必要性

　DNSは、「ドメインツリー」と呼ばれる図1のようなトップダウンの木構造を成しています。example.jpドメインを取得した場合、example.jpゾーン情報を持つDNSサーバのアドレスやホスト名を、jpゾーンを管理する上位DNSサーバに登録する必要があります。

図1　ドメインツリーと委任

　こうすることで、jpゾーンを管理するDNSサーバは、example.jpドメインのホスト情報までは知らなくても、どのDNSサーバに問い合わせれば答えが得られるかを指し示すことができます。問い合わせを行うリゾルバは、問い合わせ先DNSを変更して再度ホスト情報の問い合わせを行います。

図2　名前解決までの流れ

　ゾーン情報（例ではexample.jp）を持つDNSサーバのアドレスやホスト名を、その上位ドメイン（例ではjp）のゾーン情報を管理するDNSサーバに登録する手順こそが「委任」（delegation）です。

　上位ドメインを管理する側（以降「親」）は、その下位ドメイン（以下「子」）のゾーン情報をすべて持たず、子のゾーン情報が得られるDNSサーバのみを把握しています。つまり、「子ゾーンに関する情報は××DNSサーバに聞いてくれ」と、権限を委譲するわけです。これにより、親サーバが子ゾーンの情報であふれることなく、また子サーバはゾーン情報の変更のたびに親に変更を依頼する必要から解放されます。

　親と子は相対的な関係です。取得した自ドメインを親とし、独自に子ドメインを作成することも可能です。この場合は、「サブドメイン」といった方が一般的でしょう。会社や団体などの組織であれば、部署や部門でサブドメインを分割するのが一般的ですが、まずサブドメイン導入の是非を確認するといいでしょう。

　個人や小規模のコミュニティであれば、サブドメインの必要性はほとんどないでしょう。サブドメイン化し、ゾーン情報を分散化させなければならないほどホストを抱えているわけでもなく、各部門で管理できるドメインが必要になるという事態になる可能性もまれです。サブドメインが必要になるのは、ゾーン情報を分散化させる必要が生じるほどホスト情報がある場合や、組織的なしがらみで自由度の高いドメインを各内部組織に渡す必要がある場合です。サブドメイン化すれば、管理対象のホストはサブドメイン側で管理されるので、ホスト情報の更新頻度も軽減されます。また、親のゾーン情報も小規模になります。

　注意しなければならないのは、サーバ側の負荷は削減されても、親ドメインの管理者にはより厳格な運用が要求されるということです。親ドメインの管理者はサブドメインのゾーン情報をケアしなくてもいい分、サブドメインが正しく運用されているか、各サブドメイン管理者に対して十分に周知する必要があります。ホスト名の命名規則を作成・徹底するのもいいでしょう。