スレーブ・サーバのゾーン転送とセキュリティ：実用 BIND 9で作るDNSサーバ（5）（2/3 ページ）

[鶴長鎮一，＠IT]

マスター／スレーブの同期

ゾーン転送の強制実行（DNS NOTIFYの使用）

　ここまでに紹介したゾーン転送の方法では、スレーブがきっかけを作る必要があります。つまり、マスター・サーバのデータを更新しても、スレーブからゾーン転送要求が行われるまでタイムラグが発生してしまいます。

　更新頻度によってはSOA中の「リフレッシュ間隔」で調整できますが、ゾーンファイルが頻繁に更新される場合は、タイムラグを最小限に抑えられる別の手法が必要です。それがBIND 9の「DNS NOTIFY」です。DNS NOTIFYは、マスターのゾーンファイルが更新されたことを検知すると、スレーブ・サーバに更新通知を送ります。スレーブは更新通知元がマスター・サーバか否かを確認し、ゾーン転送を開始します。

図2　DNS NOTIFYの仕組み

　DNS NOTIFYを実装する前に、BIND管理コマンドrndcについて触れておきます。

　rndcはBIND 8のndcに相当するもので、namedに関する制御やステータス確認を行います。旧来のプロセス間通信を廃止してTCPのみの接続に切り替え、遠隔操作機能の拡充を図るなど多くの改修が行われています。rndcについては回を改めて紹介します。ここでは、rndcのインストールと簡単な使用方法の紹介にとどめます。

　rndcコマンド自体はBIND 9と同時にインストールされており、

# /usr/local/sbin/rndc

などとすれば使用可能です（注）。

注：rpmなどの場合は/usr/sbin/rndc。

　rndcの使用に際してconfファイルを生成する必要がありますが、BIND 9には設定ファイルの作成を支援するrndc-confgenコマンドが用意されています。これを以下のように実行します。

# /usr/local/sbin/rndc-confgen > /etc/rndc.conf

注：ファイルパスは環境に応じて適宜変更してください。

　実行の後、/etc/rndc.conf後半の

# Use with the following in named.conf

から末尾までを、コメント文字（#）を解除したうえでnamed.confに追加します。

key "rndc-key" {       algorithm hmac-md5;       secret "○○××○×○×○"; }; controls {       inet 127.0.0.1 port 953               allow { 127.0.0.1; } keys { "rndc-key"; }; };

/etc/named.conf（追加部分のみ）

　修正した/etc/named.confを有効にするため、namedデーモンを止めて再起動します。

# /bin/ps -aef | grep named named  プロセス番号   1  0 00:07 ?    00:00:00 /usr/local/sbin/named -u named # kill プロセス番号 # /usr/local/sbin/named -u named

直接再起動する場合

# /etc/init.d/named restart

パッケージ付属の起動スクリプトを使用する場合

　以上の作業が完了したら、試しに

# /usr/local/sbin/rndc status

を実行し、正しく実行されているか確認します。

　話をDNS NOTIFYに戻します。DNS NOTIFYを使用するうえで特に設定の追加が必要となることはありませんが、スレーブ・サーバがNSレコードで指定されていない場合は注意が必要です。次のようにマスター側のnamed.confの対象ゾーンの記述に「also-notify」を追加します。

zone "example.jp" {         type master;         file "example.zone";         notify yes; （1）         also-notify { NOTIFYを行うサーバのIP 1; NOTIFYを行うサーバのIP 2;}; （2） }; （3） options { （省略）         notify yes;         also-notify { NOTIFYを行うサーバのIP 1; NOTIFYを行うサーバのIP 2;}; }; （4）

マスター側のnamed.confの対象のゾーン

（1）デフォルトで有効になっているため指定は不要。無効にする場合は「no」を指定
（2）複数台指定の場合は「;」で区切る
（3）optionsセンテンスでも記入可能
（4）notify、also-notifyともにoptionsステートメントで指定されたものより、ゾーンセンテンスで指定されたものが優先される

　試しにゾーンファイルを編集してSOAのシリアル番号を上げ、その後rndcを使ってゾーン情報の再読み込みを行います。

# /usr/local/sbin/rndc reload

注：ファイルパスは環境に応じて適宜変更してください。

　すると、間髪を入れず、スレーブ側でゾーン転送が開始されます。

Apr 23 01:35:15 スレーブ・サーバ named[XXXX]: zone example.jp/IN: transferred serial 新しいシリアル番号 Apr 23 01:35:15 スレーブ・サーバ named[XXXX]: transfer of 'example.jp/IN' from マスター・サーバのIP#53: end of transfer Apr 23 01:35:15 スレーブ・サーバ named[XXXX]: zone example.jp/IN: sending notifies (serial 新しいシリアル番号)

/var/log/messageのログ

　うまくいかない場合は、NOTIFYがスレーブに送られているかtcpdumpコマンド（# tcpdump -X port 53）などを利用して確認します。送られていないようならマスター側の設定を、送られているようならスレーブ側の設定を見直します。

　前述したように、スレーブ側はマスターとして登録されたホストのIPからのみNOTIFYを受け付けます。もし、マスター側がバーチャルドメインの利用などで複数のネットワークインターフェイス（IPエイリアスを含む）を持っている場合は、スレーブで指定されているマスターのIPと、マスター側のNOTIFYを送信しているIPが同一か確認しましょう。

rsyncを利用したゾーンファイルの転送

　「ゾーンデータの更新検知→ゾーンデータの複製→ゾーンデータの再読み込み」が実施できるのはゾーン転送だけではありません。皆さんもよくご存じのrsyncやrdistなどのリモートファイル同期ツールを利用することも可能なのです。

　「ゾーン転送で十分ではないか」と思われる方も多いと思いますが、BINDを運用している方の中には、たびたび報告されるゾーン転送の脆弱性に嫌気が差し、ゾーン転送を無効化してこれらのツールを利用する方もいます。rsyncやrdistは差分アップデートを備えており、効率のいい転送が行えます。さらにsshを利用することで、よりセキュアに操作できます。

　ゾーン転送を切り捨てた時点で、スレーブ・サーバをslaveで立ち上げることは無意味になります。マスター・サーバと同様に、スレーブ・サーバをmasterとして立ち上げます。

zone "example.jp" {         type master;         file "example.zone"; };

named.confの一部。スレーブ・サーバのnamed.confを元に戻す

　マスター・サーバからスレーブ・サーバに対して、rsyncでファイルコピーを行うには次のようにします。

$ rsync -azb -e ssh /var/named/example.zone ユーザー名@スレーブ・サーバIP:/var/named/example.zone.bak

-a	アーカイブモード
-b	バックアップファイルを「~」の付いた名前で作成
-u	より新しければ更新しない
-v	実行過程を詳細表示
-z	zlibを利用して圧縮転送を行う
-e	ssh バージョン1を利用する場合は「ssh1」を指定

　ユーザー名には、スレーブ・サーバの/var/named/に書き込み権限を持つユーザーを指定します。逆に、スレーブからマスターのファイルをダウンロードする際は、引数の順序を逆にします。

$ rsync -auzb -e ssh ユーザー名@マスター・サーバIP:/var/named/example.zone /var/named/example.zone.bak

　上記のコマンドラインを、/var/named/に書き込み権限を持つユーザーで実行します。お互いのサーバでsshが使え、rsyncがコマンドパスに入っているかどうかに注意してください。

　コピーが完了したらrndcを使い、ゾーンデータの再読み込みを行います。スレーブ（注）側で再読み込みを行わせるのは、通常どおり

# /usr/local/sbin/rndc reload

を実行します。

注：「マスター」と「スレーブ」を区別するのは、どちらのデータがよりオリジナルかという点に帰結します。

　マスターからスレーブのrndcをリモート実行するには次のようにします。

$ ssh ユーザー名@スレーブ・サーバIP '/usr/local/sbin/rndc reload'

注：ファイルパスは環境に応じて適宜書き換えてください。ユーザー名は、スレーブにおいてsshが実行でき、rndcの実行権を持つユーザーである必要があります。

　なお、reloadではゾーンファイルのタイムスタンプが重要になります。マスターとスレーブで時刻の設定にズレがないように、ntpdateなどで内部時計を合わせておきましょう。

# ntpdate time.nist.gov

　ここまでの操作を自動化させるには、sshのパスワード入力をssh-agentなどで省略したうえでスクリプトにまとめ、crontabで周期的に実行させる必要があり、単純な作業ではありません。ただし、ゾーンファイルの更新が頻繁でないのであれば、ここで紹介した手動によるアップデートの方が実用的です。

　rdistでも同様のことが行えます。また、scpを応用する方法も考えられますが、rsyncが使える環境ならrsyncを使用することをお勧めします。

差分ゾーン転送

　BIND 9にはDynamic DNS（DNS Update）が実装されています。また、それにかかわる重要な機能も充実しています。

　Dynamic DNSでは頻繁にゾーンデータが書き換えられることが予想されるため、そのたびにNOTIFYが通知されてゾーン転送が行われていたのでは、マスター・サーバに多大な負荷が発生します。ゾーン転送で使われるのは、UDPに比べ高コストなTCPです。Dynamic DNSで数行の修正が加えられただけで、ファイルの全転送（AXFR）が実施されるのは非常に無駄です。

　そこで、差分転送（DNS IXFR：Incremental Zone Transfer）を利用します……と、Dynamic DNSは大変興味深い機能ですがここではこれ以上言及しません。Dynamic DNSについては、回を改めて説明します。

図3　差分ゾーン転送の仕組み

　ここで1つ留意いただきたいのは、BIND 9のゾーン転送は差分転送がデフォルトだという点です。スレーブからの差分ゾーン転送要求（IXFR）があることが前提のため、ほとんど問題になることはありませんが、次のようにnamed.confで無効化することができます。

options { （省略）         request-ixfr no;　←追加 };

/etc/named.conf（一部）