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

DNSサーバを運営する場合は、スレーブ・サーバ（セカンダリ・サーバ）で冗長化する必要がある。その際に検討すべきはマスター−スレーブ間のゾーン転送とそのセキュリティである。（編集局）

[鶴長鎮一，＠IT]

　規模の大小を問わず、ゾーンサーバは複数台で運用する必要があります。冗長化や負荷分散などさまざまな理由が挙げられますが、何よりドメインを取得してDNSサーバを運用するのであれば、サービスの品質を低下させないという自覚を持つ必要があります。

　今回はスレーブ・サーバの運用と、そこで使用されるゾーン転送およびそのセキュリティについて見ていきます。

コラム　スレーブ・サーバとセカンダリ・サーバ

　本稿では、「マスター・サーバ」のゾーンデータを取得してDNS問い合わせに応答するサーバを「スレーブ・サーバ」と呼んでいます。

　資料によっては、同様の意味で「プライマリ・サーバ」「セカンダリ・サーバ」が用いられる場合があり、その際「スレーブ・サーバ」はDNS問い合わせを他サーバへ転送し、自身はDNS再帰検索を行わないサーバを指す場合があります。本連載ではオリジナルとなるゾーンデータを所有するサーバを「マスター・サーバ」、ゾーンデータをマスター・サーバから複製して使用するサーバを「スレーブ・サーバ」で統一しています。

基本的なスレーブ・サーバの構築

　ゾーンサーバを複数用意した際、それぞれのサーバで異なるゾーンデータを保持していては、DNS問い合わせごとに異なる応答をしてしまう可能性があります。そこでゾーンデータの一貫性を維持するため、次のような手法でマスター・サーバのゾーンデータを各スレーブ・サーバに反映させます。

• ゾーン転送（DNS AXFR：DNS Zone Transfer）の利用
• scp、rsync、destなどのリモートファイルコピーツールの利用

　重要なのはマスター・サーバに保存されたゾーンデータをスレーブ・サーバに反映させることであり、その手法は限定されません。

　どちらのサーバに問い合わせるのかはクライアント次第であり、ほとんどがNSレコードに指定されたDNSサーバをラウンドロビンで検出します。クライアントにとってはマスターもスレーブも働きに大きな違いはなく（注）、単にゾーンファイルのオリジナル／コピーによって2者の関係が位置付けられているにすぎません。

注：digなどでDNS問い合わせを行った場合、スレーブからも「Authorized Answer」が返ってきます。キャッシュサーバは「Non-Authorized Answer」を返します。

ゾーン転送（DNS AXFR：DNS Zone Transfer）の利用

　ゾーン転送は最もオーソドックスな手法です。スレーブはマスターのゾーンデータが更新されていることを確認すると、ゾーンデータのダウンロードと再構築を行って、更新されたゾーンデータを有効にします。その際、マスター・サーバ更新の有無はゾーンデータのSOAレコード中のSerialで判定します。Serialの値が大きくなっていれば更新されたと見なし、ゾーン転送（AXFR）を開始します。

図1　ゾーン転送の基本的な動作

　そのほかにも、SOAにはゾーン転送に重要な値を記述します。第2回　すべての基礎、マスター・ゾーンサーバの設定で紹介したexample.zoneファイルは次のようになっていました。

$TTL 86400 @            IN      SOA dns.example.jp. root.example.jp. (                      2003042001 ; serial　（1）                      1h         ; refresh 1hr　（2）                      15m        ; retry 15min　（3）                      1w         ; expire 1w　（4）                      1d         ; min TTL 24hr　（5） )              IN      NS     dns.example.jp. dns          IN      A      192.168.10.1 （省略）

　第2回では、すべての値を秒換算して記述しましたが、今回は感覚的に分かりやすい単位（第3回　メール／Webサーバを効率的に動かすゾーン設定参照）を用いています。

（1）シリアル番号
増加していればゾーン転送を開始します。西暦（4けた）＋月（2けた）＋日（2けた）＋インクリメント値（2けた）が使用されることが多く、32bit値で格納されるため最大値は「4294967295」になります。この値を超えるとゾーンデータの読み込みに失敗するため、注意が必要です。
（2）リフレッシュ間隔
マスターのゾーンデータの更新確認を行う間隔を指定します。間隔が長過ぎると更新にタイムラグが発生し、短過ぎると頻繁にSOA問い合わせが発生するため、大抵は数時間程度に設定します。
（3）リトライ間隔
ゾーン転送に失敗した場合、「リトライ間隔」分の間を置き、再度ゾーン転送を試みます。通常は「リフレッシュ間隔」より短い値を指定します。
（4）ゾーンの有効期限
マスターとのゾーン転送が滞ってしまい、スレーブに保存されたデータが「ゾーンの有効期限」を過ぎた場合は、そのゾーンに対する問い合わせ要求に返答しなくなります。古い内容で返答するより、返答そのものをしない方がいいという考えに基づいています。多くの場合は1週間程度を指定しますが、マスターとの接続状況によっては長めに取ることもあります。
（5）ネガティブキャッシュTTL
ゾーン転送には無関係なため、ここでは省略します。第2回を参照してください。

　では、第2回で使用しているexample.jpを例に、マスター／スレーブそれぞれの設定を見ていきましょう。

　本来、ゾーン転送を許可するホストやセキュリティを考慮した設定をマスター側のnamed.confに加える必要がありますが、マスター／スレーブの働きを理解することに専念するため、その点については後述します。実運用に際しては、後半のセキュリティ対策も施しておきましょう。

　スレーブ・サーバのnamed.confは次のようにします。

options {         directory "/var/named";         pid-file "/var/run/named/named.pid";         recursion yes; }; zone "." {         type hint;         file "named.ca";　（1） }; zone "localhost" {         type master;         file "local.zone";　（2） }; zone "0.0.127.in-addr.arpa" {         type master;         file "local.rev";　（3） }; zone "example.jp" {　（4）         type slave;         masters {                 マスター・サーバのIPアドレス;         };         file "example.zone.bak"; }; zone "10.168.192.in-addr.arpa" {　（5）         type slave;         masters {                 マスター・サーバのIPアドレス;         };         file "example.rev.bak"; };

注：スレーブ・サーバでも、（1）named.ca、（2）local.zone、（3）local.revはマスター・サーバと同じように設定する必要があります。

　マスターから取得したゾーンファイルのコピーを（4）、（5）で指定したファイル名で「/var/named」に作成するため、/var/namedディレクトリをnamed（注）オーナーとグループで書き込めるように用意しておくことお忘れなく。

注：namedデーモンをnamedユーザーで起動することを前提にしています。

　（4）では、typeを「slave」と指定し、「master」で指定されたサーバからゾーン転送を行い、ゾーンデータを「file」で指定されたファイル名で保存します。ファイル名の命名規則に決まりはありませんが、筆者は「bak」拡張子を付けてほかのファイルと区別できるようにしています。ゾーン情報をマスターから再構築し直したい場合、bak拡張子が付いたファイルだけをまとめて削除し、手動でゾーン転送を行えば目的を達することができます。

　それでは、マスター・サーバのnamedデーモンを起動後、スレーブ側のnamedを起動し、ゾーン転送が行われるかを確認します。つまり、/var/namedディレクトリ下に、指定したファイル名でファイルが作成されるかを確認します。

　なお、作成されたファイルはmoreなどで中身を確認できます。

# /usr/local/sbin/named -u named

直接起動する場合

# /etc/init.d/named start

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

　ゾーン転送がうまく行われない場合は、次の点を確認します。

• TCPの53番ポートが経路の途中でフィルタリングされていないか

ゾーン転送はUDPではなくTCPを利用します。マスターとスレーブの間にファイアウォールが設置されていたり、iptablesやipchainsでフィルタを掛けている場合は、該当ポートを開放します。

• マスターでゾーン転送の制限を掛けていないか

ここまでの説明ではBIND自体のアクセス制限の方法は紹介していませんが、後述のアクセス制限を掛けている場合は、いったん制限を解除します。

　デバッグに当たっては、実際にスレーブのnamedを起動しなくてもdigコマンドでゾーン転送が実施されるかどうか、確認することができます。

$ dig @マスターサーバのIPアドレス example.jp axfr

　以上の見直しで解決しない場合は、/var/log/messagesに出力される詳細なエラーを頼りに問題点を特定しましょう。

コラム　BIND 9.2.2リリース

　2003年3月3日にBIND 9.2.2がリリースされました。このバージョンは、バージョン9.2.0および9.2.1で発見された脆弱性の原因となるバグを修正し、攻撃可能な2つのセキュリティ問題（CERT CA-2002-19：http://www.cert.org/advisories/CA-2002-19.html）、CERT

CA-2002-23：http://www.cert.org/advisories/CA-2002-23.html）を修正しています。下記のファイルをダウンロードし、第1回　BIND 9の改ざんチェックとインストールを参考に上書きインストールしましょう。

　なお、本稿以降ではBIND 9の対象を9.2.1から9.2.2に変更しています。

BIND 9.2.2のソース
ftp://ftp.isc.org/isc/bind9/9.2.2/bind-9.2.2.tar.gz

BIND 9.2.2のPGP Signature
ftp://ftp.isc.org/isc/bind9/9.2.2/bind-9.2.2.tar.gz.asc