原文出處 http://www.atmarkit.co.jp/flinux/rensai/bind907/bind907c.html
■TSIG（Transaction Signature）の利用
TSIGは、すでに第5回で登場しています。第5回ではゾーン転送時のセキュアな手段として紹介しましたが、ここでも威力を発揮します。
設定作業は第5回と同じように行います。まず、dnssec-keygenコマンドで共有鍵を作成します。作業するのは、マスター・ゾーンサーバ側、nsupdateを実施するクライアント側のどちらでも構いません。
# /usr/sbin/dnssec-keygen -a HMAC-MD5 -b 512 -n HOST example.jp
Kexample.jp.+157+01798.key
Kexample.jp.+157+01798.private
注：コマンドパスおよびexample.jpは、環境に応じて書き換えてください。
「key」「private」といった拡張子を見ると、公開鍵暗号方式が使用されているように思えますが、ここではHMAC-MD5を使用しており、2つのファイルの中に記載されるパスフレーズは同じものです。以下のnamed.confの設定ではKexample.jp.+157+01798.keyから鍵を抽出していますが、Kexample.jp.+157+01798.privateを使っても同じになります。
$ more Kexample.jp.+157+01798.key
example.jp. IN KEY 512 3 157 1GPx/sFNPz40U/NuspDqo……（略）
次に、生成されたファイルから共有鍵（上の赤字の個所）を抜き出し、named.confに埋め込みます。
key "example.jp" {
algorithm hmac-md5;
secret "1GPx/sFNPz40U/NuspDqo……（略）";
};
zone "example.jp" {
type master;
file "example.zone";
allow-update{
key example.jp;
};
};
/etc/named.conf
named.confの変更を有効にするために、namedプロセスの再起動やrndcコマンドでreloadを実行しましょう。
次に、nsupdateを行うクライアント側の設定です。先ほど作成したファイルのうち、どちらか1つをクライアント側にコピーしておきます。
$ /usr/bin/nsupdate -k ./Kexample.jp.+157+24115.key
注：コマンドパスおよび鍵ファイルへのパスは環境に応じて書き換えてください。
前述のとおり、公開鍵／秘密鍵のような区別がないため、.privateファイルでも同じようにnsupdateを実行できます。
$ /usr/bin/nsupdate -k ./Kexample.jp.+157+24115.private
これで、「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を利用すればレコードの種類ごとにセキュリィティポリシーを設定できます。
key "example.jp" {
（省略）
};
zone "example.jp" {
type master;
file "example.zone";
update-policy{
grant example.jp wildcard *.example.jp. A;
};
};
named.conf
update-policyには、次のような指定を行います。
grant keyの名前 nameタイプ name (type) 許可する場合
deny keyの名前 nameタイプ name (type) 許可しない場合
nameタイプには、次のものを使用します。
name 更新を行うFQDNホスト名がnameと同じ場合
subdomain 更新を行うFQDNホスト名がnameをドメインの一部に持つとき
wildcard 更新を行うFQDNホスト名がnameのワイルドカード指定にマッチする場合
self 更新を行うFQDNホスト名が「keyの名前」と同じ場合（後ろのname指定は無視されるが、省略はできない）
例に使用した、
grant example.jp wildcard *.example.jp. A;
は、「example.jp.」にマッチするFQDNホスト名のupdateで、かつAレコードを登録する場合のみ許可されることになります。この設定であれば、MXが書き換えられて見当外れのサーバにメールが配送されたり、NSが書き換えられてしまうなどのトラブルを未然に防ぐことができます。仮に、CNAMEやMXなどのAレコード以外の登録を行おうとすると、
Jul 2 04:31:31 host named[XXX]: client 127.0.0.1#1046: updating zone 'example.jp/IN': update failed: rejected by secure update (REFUSED)
のような警告が/var/log/messagesに記録されます。
■jnlファイルとトラブルの対処法
大変便利なupdateですが、ゾーンファイルを直接編集する際は、特に注意が必要です。BIND 9のDynamic DNSはupdate要求をjnlファイルにいったん蓄えるため、すぐにディスク上のゾーンファイルに反映させません。
namedプロセスが不意に停止しても、jnlファイルがあれば反映されていない情報も再度同期を試みます。しかし、手動でゾーンファイルを編集してしまうと、差分情報であるjnlファイルとの整合性が取れなくなり、/var/log/messagesに次のような警告が記録されます。
Jul 2 01:57:43 host named[XXXXX]: zone example.co.jp/IN: journal rollforward failed: journal out of sync with zone
こうなってしまった場合は更新差分の反映をあきらめてjnlファイルを削除し、再度namedを起動します。
沒有留言:
張貼留言