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

» 2003年06月03日 00時00分 公開
[鶴長鎮一@IT]
前のページへ 1|2|3       

サブドメインの委任

 次に、サブドメインを委任する場合の運用を見ていきましょう。例として、「sales.example.jp」というサブドメインを新設します。sales.example.jpに属するホスト情報は次のとおりです。

dns01.sales.example.jp 192.168.10.60 #sales.example.jpドメインのDNSサーバ
dns02.sales.example.jp 192.168.10.61 #sales.example.jpドメインのDNSサーバ
sv1.sales.example.jp 192.168.10.62
sv2.sales.example.jp 192.168.10.63
mail.sales.example.jp 192.168.10.64 #sales.example.jpドメインのメールサーバ
www.sales.example.jp sv1.sales.example.jpの別名 #sales.example.jpドメインのwwwサーバ

 sales.example.jpドメインのDNSサーバが複数用意されていることに注意しましょう。1台でも運用は可能ですが、ドメイン運営の責任を負うことを考えると複数台設置することが望まれます。

親側の設定

 まず、上位ドメインであるexample.jpをつかさどるDNSサーバに、サブドメインsales.example.jpの問い合わせ先を登録します。サブドメイン側DNSサーバのホスト名は、必ず正規のものを使用します。CNAMEで定義されたホスト名は使用してはいけません(参考:第3回中の「やってはいけないCNAMEの使用方法」)。

sales                   IN   NS   dns01.sales.example.jp.
                        IN   NS   dns02.sales
dns01.sales.example.jp. IN   A    192.168.10.60
dns02.sales             IN   A    192.168.10.61
dns01.example.jp(親)のゾーンファイルexample.zone追加分

 サンプルでは、記述フォーマットを理解していただくために、ホスト名末尾の「.」を省略した場合とFQDNで書いた場合を併用しています。実際に試す際は、タイプミスを防ぐためにも、どちらか一方の書式に統一しましょう。

 なお、先ほど紹介した$ORIGINや$INCLUDEを使ってスマートにまとめることも可能です。

$ORIGIN sales.example.jp.
$INCLUDE sales.example.zone
dns01.example.jp(親)のゾーンファイルexample.zone追加分

@                       IN   NS   dns01.sales.example.jp. (注)
                        IN   NS   dns02
dns01.sales.example.jp. IN   A    192.168.10.60
dns02                   IN   A    192.168.10.61
親の/var/named/sales.example.zoneファイル

注:FQDNを用いた、

sales.example.jp        IN      MX     10 mail

と同等です。

子側の設定

 サブドメインを委任された子の方は、通常どおりゾーンファイルを準備します。

zone "sales.example.jp" {
        type master;
        file "sales.example.zone";
};
dns01sales.example.jp(子) の/etc/named.conf

$ttl 38400
@       IN      SOA     dns01.sales.example.jp. root.sales.
example.jp.  (
                        2003052001
                        10800
                        3600
                        604800
                        38400 )
        IN      NS      dns01.sales.example.jp.
        IN      NS      dns02.sales.example.jp.
        IN      MX      10 mail.sales.example.jp.
dns01   IN      A       192.168.10.60
dns02   IN      A       192.168.10.61
sv1     IN      A       192.168.10.62
sv2     IN      A       192.168.10.63
mail    IN      A       192.168.10.64
www     IN      CNAME   sv1.sales.example.jp.
dns01sales.example.jp(子) の/var/named/etc/sales.example.zone

 子側のDNSをすべて同じように設定するか、ゾーン転送を使用するなどして、どのDNSサーバに問い合わせてもsales.example.jp.の情報を返すようにしておきます。

 子側のDNSサーバは、必ずしも子ゾーン内に設けなければならないと決められているわけではありません。第三者機関に預けたり、別のゾーン内に設置しても構いません。ただし、委任されたDNSでサブドメインを立ち上げたもともとの趣旨を考えると、子ゾーン内で立ち上げるのが妥当です。「IPアドレスが足りなくて、外部のデータセンターにDNSサーバを置くしかない」という方もいるかと思いますが、これと子DNSサーバを子ゾーン内で立ち上げることとは別の問題です。名前空間とIPレイアウトが一致している必要はありません。

図4 DNS名前空間とIPレイアウトが一致しない例 DNS名前空間 図4 DNS名前空間とIPレイアウトが一致しない例 DNS名前空間
図5 DNS名前空間とIPレイアウトが一致しない例 IPアドレス空間 図5 DNS名前空間とIPレイアウトが一致しない例 IPアドレス空間

スタブによる便利な委任管理

 サブドメインの管理を子側に委任しても、NSレコードの変更は親側に依存するため、完全に子に任せるというわけにはいきません。「スタブ」を利用すると、親依存の度合いを少なくすることができます。

 スタブはゾーン転送のサブセットで、子側のゾーン情報をゾーン転送の要領で親側にコピーします。スタブを利用すればNSレコードの変更も子側で行えるため、子から親へのゾーンファイルの同期処理もゾーン転送のそれと同じように行われます。親側は最低限マスターファイルの所在先(IPアドレス)だけを知っていればいいことになります。

zone "sales.example.jp" {
        type stub;
        masters {子ゾーンファイルの所在先IPアドレス;};
        file "sales.example.stub";
};
親DNSサーバの/etc/named.conf

 子側は、先ほどの「サブドメインの委任」と同じように行います。子から親へのゾーンファイル転送が行われれば、子側の/var/log/messagesにその旨が出力されます。

May 20 13:56:28 dns01 named[XXXXX]: zone sales.example.jp/IN: sending notifies (serial 2003052001)
子DNSサーバの/var/log/messages

 うまくいかない場合は、TCPの53番が親と子で疎通できるかなど、第5回を参考に問題に対処しましょう。


 今回は、委任の仕組みをサブドメインの運用を交えながら紹介しました。最近ではドメインも比較的簡単に取得できるようになり、1つのドメインをサブドメイン化するまでもなく、新規ドメインを取得する方法が取られることも少なくないようです。しかし、コストや可用性などを考慮すると、サブドメインでの運用の方が有利です。

 実は、第4回で紹介したように、クラスC未満のIPアドレスが付与された環境では、逆引きDNSをサブドメインで運用することが一般的になっています。第4回でサブドメインの仕組みを消化できなかった方は、理解しやすい正引きでのサブドメイン運用から学んでみるといいでしょう。


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。