検索
連載

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

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

Share
Tweet
LINE
Hatena
前のページへ |       

Dynamic DNSの動作確認とセキュリティ対策

/var/log/messagesの確認

 デバッグ情報を表示させることで、リアルタイムにupdateの正否を確認できますが、サーバ側の/var/log/messagesでも状況を把握できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 ログを確認していると、named起動時に次のような行が記録されている場合があります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 これは、IPアドレスを基にした規制では不十分であるという警告です。これに対しては、TSIGを用います。

TSIG(Transaction Signature)の利用

 TSIGは、すでに第5回で登場しています。第5回ではゾーン転送時のセキュアな手段として紹介しましたが、ここでも威力を発揮します。

 設定作業は第5回と同じように行います。まず、dnssec-keygenコマンドで共有鍵を作成します。作業するのは、マスター・ゾーンサーバ側、nsupdateを実施するクライアント側のどちらでも構いません。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 「key」「private」といった拡張子を見ると、公開鍵暗号方式が使用されているように思えますが、ここではHMAC-MD5を使用しており、2つのファイルの中に記載されるパスフレーズは同じものです。以下のnamed.confの設定ではKexample.jp.+157+01798.keyから鍵を抽出していますが、Kexample.jp.+157+01798.privateを使っても同じになります。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 次に、生成されたファイルから共有鍵(上の赤字の個所)を抜き出し、named.confに埋め込みます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 named.confの変更を有効にするために、namedプロセスの再起動やrndcコマンドでreloadを実行しましょう。

 次に、nsupdateを行うクライアント側の設定です。先ほど作成したファイルのうち、どちらか1つをクライアント側にコピーしておきます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 前述のとおり、公開鍵/秘密鍵のような区別がないため、.privateファイルでも同じようにnsupdateを実行できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 これで、「allows updates by IP address, which is insecure」と/var/log/messagesに警告が表示されることはなくなります。残念なのは、TSIG署名とIP ACLによる制限でand条件を掛けられないことです。TSIG署名かIP ACLどちらかの条件を満たせばupdateが可能なため、「TSIG署名かつIP ACL」のような制限を掛けることはできません。

update-policyの利用

 BIND 9では、allow-updateだけではなくupdate-policyを利用することができます。allow-updateはゾーンそのものの許可の有無を設定するものでしたが、「Aレコードだけupdateさせたい」「MXレコードは変えさせない」など、update-policyを利用すればレコードの種類ごとにセキュリィティポリシーを設定できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 update-policyには、次のような指定を行います。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 nameタイプには、次のものを使用します。

name 更新を行うFQDNホスト名がnameと同じ場合
subdomain 更新を行うFQDNホスト名がnameをドメインの一部に持つとき
wildcard 更新を行うFQDNホスト名がnameのワイルドカード指定にマッチする場合
self 更新を行うFQDNホスト名が「keyの名前」と同じ場合(後ろのname指定は無視されるが、省略はできない)

 例に使用した、

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

は、「example.jp.」にマッチするFQDNホスト名のupdateで、かつAレコードを登録する場合のみ許可されることになります。この設定であれば、MXが書き換えられて見当外れのサーバにメールが配送されたり、NSが書き換えられてしまうなどのトラブルを未然に防ぐことができます。仮に、CNAMEやMXなどのAレコード以外の登録を行おうとすると、

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

のような警告が/var/log/messagesに記録されます。

jnlファイルとトラブルの対処法

 大変便利なupdateですが、ゾーンファイルを直接編集する際は、特に注意が必要です。BIND 9のDynamic DNSはupdate要求をjnlファイルにいったん蓄えるため、すぐにディスク上のゾーンファイルに反映させません。

 namedプロセスが不意に停止しても、jnlファイルがあれば反映されていない情報も再度同期を試みます。しかし、手動でゾーンファイルを編集してしまうと、差分情報であるjnlファイルとの整合性が取れなくなり、/var/log/messagesに次のような警告が記録されます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

 こうなってしまった場合は更新差分の反映をあきらめてjnlファイルを削除し、再度namedを起動します。


 今回は、BIND 9付属のnsupdateを使ってDynamic DNSの使い方を紹介しました。次回は、DHCPなどの動的IP割り当てサービスとの連携方法や、簡単なスクリプトを使った自家製Dynamic DNSサーバを構築します。


前のページへ |       

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る