Dynamic DNSの基礎とnsupdateコマンド：実用 BIND 9で作るDNSサーバ（7）（1/3 ページ）

　従来、ゾーン情報を更新するにはローカル環境でファイルを編集する必要があるほか、DHCPなどで動的に付与されたIPアドレスを迅速に反映させる手段も提供されていませんでした。BIND 9には、ゾーンレコードの遠隔更新やnamedプロセスの再起動を必要としない動的反映が実装されました。それが「Dynamic DNS」です。

　Dynamic DNSは、RFC 2136（http://rfc-jp.nic.ad.jp/cgi-bin/direct.cgi?keyword=2136&language=eng&x=10&y=16）（注）でも「DNS Update」として提唱されており、Windowsをはじめ多くのプラットフォームで更新方法が提供されています。DHCPサーバと組み合わせることで、より利便性の高いサービスを利用することもできます。

　今回はBIND 9付属のnsupdateコマンドを使う方法を紹介し、次回ではDHCPやPPPなどの動的なIPアドレス付与サービスと組み合わせた例を紹介します。

Dynamic DNSの仕組み

Dynamic DNSの基本的な動作

　まず、単純な例でDynamic DNSの仕組みを見ていきましょう。ここでは、BIND 9に付属しているnsupdateコマンドによる更新を例にします。nsupdateの使用法やBINDの準備については後述します。

図1　Dynamic DNSの動作の仕組み

　nsupdateは、変更先DNSを見つけるために、登録しようとしているドメイン情報（host100.example.jp）に対するSOAを問い合わせ、DNS名を取得します。NSレコードではなくSOA中のDNS名が使用されることに注意しましょう（注）。

　更新先を見つけると、サーバに対して更新を要求します。更新要求を受けたサーバ（ゾーンサーバA）は要求元が許可されたものか否かを判断した後、リクエストに応じてメモリにロードされているゾーン情報に反映します。ローカルディスク上のゾーンファイル（example.zone）の書き換えは、ジャーナルファイルを基に一定の間隔で行います。こうしたバッファリングメカニズムを用いることで、過渡的に発生するようなupdate要求に対応できます。

マスター／スレーブで構成されたDynamic DNS

　DNSサーバが複数台存在する場合はどうなるでしょうか？ nsupdateは、どのサーバに対してupdateを行うかを個別に指定できますが、通常はSOAレコード中のDNS名を基にupdate先を決定します。SOA中のDNS名が不適切であったり、正引きできない状況で正しく機能しないのはもちろん、スレーブ・ゾーンサーバ側のアドレスが返ってくる可能性もあります。

図2　マスター／スレーブで構成された例

　このような場合、update要求を受けたスレーブ・ゾーンサーバはマスター・ゾーンサーバに要求を転送します。その際、スレーブ・ゾーンサーバは要求元（クライアントC）がforward許可されたものかどうかを確認し、許可されているもののみ転送します。

　転送を受けたマスター・ゾーンサーバは、転送元であるスレーブ・ゾーンサーバがupdate許可されたものであればDNS Updateを実施します。マスター・ゾーンサーバは、クライアントがupdate許可されたものかどうかではなく、スレーブ・ゾーンサーバがupdate許可されているかどうかのみを確認します。そのため、スレーブ・ゾーンサーバ側での転送許可が重要な役割を持つことに注意しましょう。

　update要求の転送を受けたマスター・ゾーンサーバは、ゾーン情報に反映させてjnl（ジャーナル）ファイルを作成します。更新差分がゾーンファイルに同期された後もjnlファイルは消去されず、マスター／スレーブ間の差分ゾーン転送に再利用されます。第5回で、Dynamic DNSの頻繁なゾーン情報書き換えにも対応できるように差分ゾーン転送が利用されると説明しました。jnlファイルの利用方法に代表されるように、差分ゾーン転送とDynamic DNSは大変密接な関係があることが分かります。