スレーブ・サーバのゾーン転送とセキュリティ：実用 BIND 9で作るDNSサーバ（5）（1/3 ページ）
DNSサーバを運営する場合は、スレーブ・サーバ（セカンダリ・サーバ）で冗長化する必要がある。その際に検討すべきはマスター−スレーブ間のゾーン転送とそのセキュリティである。（編集局）
規模の大小を問わず、ゾーンサーバは複数台で運用する必要があります。冗長化や負荷分散などさまざまな理由が挙げられますが、何よりドメインを取得してDNSサーバを運用するのであれば、サービスの品質を低下させないという自覚を持つ必要があります。
今回はスレーブ・サーバの運用と、そこで使用されるゾーン転送およびそのセキュリティについて見ていきます。
コラム スレーブ・サーバとセカンダリ・サーバ
本稿では、「マスター・サーバ」のゾーンデータを取得してDNS問い合わせに応答するサーバを「スレーブ・サーバ」と呼んでいます。
資料によっては、同様の意味で「プライマリ・サーバ」「セカンダリ・サーバ」が用いられる場合があり、その際「スレーブ・サーバ」はDNS問い合わせを他サーバへ転送し、自身はDNS再帰検索を行わないサーバを指す場合があります。本連載ではオリジナルとなるゾーンデータを所有するサーバを「マスター・サーバ」、ゾーンデータをマスター・サーバから複製して使用するサーバを「スレーブ・サーバ」で統一しています。
基本的なスレーブ・サーバの構築
ゾーンサーバを複数用意した際、それぞれのサーバで異なるゾーンデータを保持していては、DNS問い合わせごとに異なる応答をしてしまう可能性があります。そこでゾーンデータの一貫性を維持するため、次のような手法でマスター・サーバのゾーンデータを各スレーブ・サーバに反映させます。
- ゾーン転送（DNS AXFR：DNS Zone Transfer）の利用
- scp、rsync、destなどのリモートファイルコピーツールの利用
重要なのはマスター・サーバに保存されたゾーンデータをスレーブ・サーバに反映させることであり、その手法は限定されません。
どちらのサーバに問い合わせるのかはクライアント次第であり、ほとんどがNSレコードに指定されたDNSサーバをラウンドロビンで検出します。クライアントにとってはマスターもスレーブも働きに大きな違いはなく（注）、単にゾーンファイルのオリジナル／コピーによって2者の関係が位置付けられているにすぎません。
ゾーン転送（DNS AXFR：DNS Zone Transfer）の利用
ゾーン転送は最もオーソドックスな手法です。スレーブはマスターのゾーンデータが更新されていることを確認すると、ゾーンデータのダウンロードと再構築を行って、更新されたゾーンデータを有効にします。その際、マスター・サーバ更新の有無はゾーンデータのSOAレコード中のSerialで判定します。Serialの値が大きくなっていれば更新されたと見なし、ゾーン転送（AXFR）を開始します。
そのほかにも、SOAにはゾーン転送に重要な値を記述します。第2回 すべての基礎、マスター・ゾーンサーバの設定で紹介したexample.zoneファイルは次のようになっていました。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
第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は次のようにします。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
マスターから取得したゾーンファイルのコピーを（4）、（5）で指定したファイル名で「/var/named」に作成するため、/var/namedディレクトリをnamed（注）オーナーとグループで書き込めるように用意しておくことお忘れなく。
（4）では、typeを「slave」と指定し、「master」で指定されたサーバからゾーン転送を行い、ゾーンデータを「file」で指定されたファイル名で保存します。ファイル名の命名規則に決まりはありませんが、筆者は「bak」拡張子を付けてほかのファイルと区別できるようにしています。ゾーン情報をマスターから再構築し直したい場合、bak拡張子が付いたファイルだけをまとめて削除し、手動でゾーン転送を行えば目的を達することができます。
それでは、マスター・サーバのnamedデーモンを起動後、スレーブ側のnamedを起動し、ゾーン転送が行われるかを確認します。つまり、/var/namedディレクトリ下に、指定したファイル名でファイルが作成されるかを確認します。
なお、作成されたファイルはmoreなどで中身を確認できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ゾーン転送がうまく行われない場合は、次の点を確認します。
- TCPの53番ポートが経路の途中でフィルタリングされていないか
ゾーン転送はUDPではなくTCPを利用します。マスターとスレーブの間にファイアウォールが設置されていたり、iptablesやipchainsでフィルタを掛けている場合は、該当ポートを開放します。
- マスターでゾーン転送の制限を掛けていないか
ここまでの説明ではBIND自体のアクセス制限の方法は紹介していませんが、後述のアクセス制限を掛けている場合は、いったん制限を解除します。
デバッグに当たっては、実際にスレーブのnamedを起動しなくてもdigコマンドでゾーン転送が実施されるかどうか、確認することができます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
以上の見直しで解決しない場合は、/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
Copyright © ITmedia, Inc. All Rights Reserved.