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

DHCP環境などで威力を発揮するDynamic DNS。今回は、nsupdateコマンドを使ってBIND 9におけるDynamic DNSの動作と使い方を紹介する。（編集局）

[鶴長鎮一，＠IT]

　従来、ゾーン情報を更新するにはローカル環境でファイルを編集する必要があるほか、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サーバと組み合わせることで、より利便性の高いサービスを利用することもできます。

注：日本語訳はhttp://www5d.biglobe.ne.jp/~stssk/rfc2136j.html。

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

Dynamic DNSの仕組み

Dynamic DNSの基本的な動作

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

図1　Dynamic DNSの動作の仕組み

1．host100.example.jpのSOAを問い合わせ
2．host100.example.jpのSOAを返答
3．nsupdateはSOAレコードからDNS Aを見つけ、updateを要求
4、要求元（クライアント）がupdate許可されたものであれば、host100.example.jpを登録

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

注：SOAに正しくサーバ名を記述しており、それに対する正引きも登録していれば問題ありません。しかし、「localhost.」などと記述していると、クライアントは自分自身を更新サーバと誤認識します。

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

$TTL 86400 @            IN      SOA dns.example.jp. root.example.jp. ( #SOA中のDNS名が使用される                      2002122001 ; serial                      3600       ; refresh 1hr                      900        ; retry 15min                      604800     ; expire 1w                      86400      ; min 24hr ) dns          IN      A      192.168.10.1    #DNS名に対して正しく正引きされている必要がある

example.zone（第2回）より

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

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

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

1．host100.example.jpのSOA問い合わせ
2．host100.example.jpのSOAを返答（DNSサーバが複数あると、どのDNSサーバのSOAを返すか予測できない）
3．nsupdateはSOAレコードからDNS Aを見つけ、updateを要求
4．要求元（クライアントC）がforward許可されたものであれば、update要求をforwarding
5．転送元（スレーブ・ゾーンサーバA）がupdate許可されたものであれば、host100.example.jpを登録
6．ジャーナルファイルを基に差分ゾーン転送

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

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

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