スレーブ・サーバのゾーン転送とセキュリティ：実用 BIND 9で作るDNSサーバ（5）（2/3 ページ）
DNSサーバを運営する場合は、スレーブ・サーバ（セカンダリ・サーバ）で冗長化する必要がある。その際に検討すべきはマスター−スレーブ間のゾーン転送とそのセキュリティである。（編集局）
マスター／スレーブの同期
ゾーン転送の強制実行（DNS NOTIFYの使用）
ここまでに紹介したゾーン転送の方法では、スレーブがきっかけを作る必要があります。つまり、マスター・サーバのデータを更新しても、スレーブからゾーン転送要求が行われるまでタイムラグが発生してしまいます。
更新頻度によってはSOA中の「リフレッシュ間隔」で調整できますが、ゾーンファイルが頻繁に更新される場合は、タイムラグを最小限に抑えられる別の手法が必要です。それがBIND 9の「DNS NOTIFY」です。DNS NOTIFYは、マスターのゾーンファイルが更新されたことを検知すると、スレーブ・サーバに更新通知を送ります。スレーブは更新通知元がマスター・サーバか否かを確認し、ゾーン転送を開始します。
DNS NOTIFYを実装する前に、BIND管理コマンドrndcについて触れておきます。
rndcはBIND 8のndcに相当するもので、namedに関する制御やステータス確認を行います。旧来のプロセス間通信を廃止してTCPのみの接続に切り替え、遠隔操作機能の拡充を図るなど多くの改修が行われています。rndcについては回を改めて紹介します。ここでは、rndcのインストールと簡単な使用方法の紹介にとどめます。
rndcコマンド自体はBIND 9と同時にインストールされており、
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
などとすれば使用可能です（注）。
rndcの使用に際してconfファイルを生成する必要がありますが、BIND 9には設定ファイルの作成を支援するrndc-confgenコマンドが用意されています。これを以下のように実行します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
実行の後、/etc/rndc.conf後半の
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
から末尾までを、コメント文字（#）を解除したうえでnamed.confに追加します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
修正した/etc/named.confを有効にするため、namedデーモンを止めて再起動します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
以上の作業が完了したら、試しに
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
を実行し、正しく実行されているか確認します。
話をDNS NOTIFYに戻します。DNS NOTIFYを使用するうえで特に設定の追加が必要となることはありませんが、スレーブ・サーバがNSレコードで指定されていない場合は注意が必要です。次のようにマスター側のnamed.confの対象ゾーンの記述に「also-notify」を追加します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（1）デフォルトで有効になっているため指定は不要。無効にする場合は「no」を指定
（2）複数台指定の場合は「;」で区切る
（3）optionsセンテンスでも記入可能
（4）notify、also-notifyともにoptionsステートメントで指定されたものより、ゾーンセンテンスで指定されたものが優先される
試しにゾーンファイルを編集してSOAのシリアル番号を上げ、その後rndcを使ってゾーン情報の再読み込みを行います。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
すると、間髪を入れず、スレーブ側でゾーン転送が開始されます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
うまくいかない場合は、NOTIFYがスレーブに送られているかtcpdumpコマンド（# tcpdump -X port 53）などを利用して確認します。送られていないようならマスター側の設定を、送られているようならスレーブ側の設定を見直します。
前述したように、スレーブ側はマスターとして登録されたホストのIPからのみNOTIFYを受け付けます。もし、マスター側がバーチャルドメインの利用などで複数のネットワークインターフェイス（IPエイリアスを含む）を持っている場合は、スレーブで指定されているマスターのIPと、マスター側のNOTIFYを送信しているIPが同一か確認しましょう。
rsyncを利用したゾーンファイルの転送
「ゾーンデータの更新検知→ゾーンデータの複製→ゾーンデータの再読み込み」が実施できるのはゾーン転送だけではありません。皆さんもよくご存じのrsyncやrdistなどのリモートファイル同期ツールを利用することも可能なのです。
「ゾーン転送で十分ではないか」と思われる方も多いと思いますが、BINDを運用している方の中には、たびたび報告されるゾーン転送の脆弱性に嫌気が差し、ゾーン転送を無効化してこれらのツールを利用する方もいます。rsyncやrdistは差分アップデートを備えており、効率のいい転送が行えます。さらにsshを利用することで、よりセキュアに操作できます。
ゾーン転送を切り捨てた時点で、スレーブ・サーバをslaveで立ち上げることは無意味になります。マスター・サーバと同様に、スレーブ・サーバをmasterとして立ち上げます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
マスター・サーバからスレーブ・サーバに対して、rsyncでファイルコピーを行うには次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
| -a | アーカイブモード |
|---|---|
| -b | バックアップファイルを「~」の付いた名前で作成 |
| -u | より新しければ更新しない |
| -v | 実行過程を詳細表示 |
| -z | zlibを利用して圧縮転送を行う |
| -e | ssh バージョン1を利用する場合は「ssh1」を指定 |
ユーザー名には、スレーブ・サーバの/var/named/に書き込み権限を持つユーザーを指定します。逆に、スレーブからマスターのファイルをダウンロードする際は、引数の順序を逆にします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記のコマンドラインを、/var/named/に書き込み権限を持つユーザーで実行します。お互いのサーバでsshが使え、rsyncがコマンドパスに入っているかどうかに注意してください。
コピーが完了したらrndcを使い、ゾーンデータの再読み込みを行います。スレーブ（注）側で再読み込みを行わせるのは、通常どおり
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
を実行します。
マスターからスレーブのrndcをリモート実行するには次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
なお、reloadではゾーンファイルのタイムスタンプが重要になります。マスターとスレーブで時刻の設定にズレがないように、ntpdateなどで内部時計を合わせておきましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ここまでの操作を自動化させるには、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については、回を改めて説明します。
ここで1つ留意いただきたいのは、BIND 9のゾーン転送は差分転送がデフォルトだという点です。スレーブからの差分ゾーン転送要求（IXFR）があることが前提のため、ほとんど問題になることはありませんが、次のようにnamed.confで無効化することができます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
Copyright © ITmedia, Inc. All Rights Reserved.