連載
» 2003年07月08日 00時00分 UPDATE

実用 BIND 9で作るDNSサーバ(7):Dynamic DNSの基礎とnsupdateコマンド (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サーバと組み合わせることで、より利便性の高いサービスを利用することもできます。


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

Dynamic DNSの仕組み

Dynamic DNSの基本的な動作

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

図1 Dynamic DNSの動作の仕組み 図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 マスター/スレーブで構成された例 図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は大変密接な関係があることが分かります。

       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

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

メールマガジン登録

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