Tweet

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

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

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

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

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

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

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

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

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

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

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

　第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は次のようにします。

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

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

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

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

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

• TCPの53番ポートが経路の途中でフィルタリングされていないか
  ゾーン転送はUDPではなくTCPを利用します。マスターとスレーブの間にファイアウォールが設置されていたり、iptablesやipchainsでフィルタを掛けている場合は、該当ポートを開放します。
  
  
• マスターでゾーン転送の制限を掛けていないか
  ここまでの説明ではBIND自体のアクセス制限の方法は紹介していませんが、後述のアクセス制限を掛けている場合は、いったん制限を解除します。

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

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

1/3

Index 実用 BIND 9で作るDNSサーバ 　第5回 スレーブ・サーバのゾーン転送とセキュリティ

Page 1 基本的なスレーブ・サーバの構築 　ゾーン転送（DNS AXFR：DNS Zone Transfer）の利用 　 Page 2 マスター／スレーブの同期 　ゾーン転送の強制実行（DNS NOTIFYの使用） 　rsyncを利用したゾーンファイルの転送 　差分ゾーン転送 　 Page 3 ゾーン転送のセキュリティ対策 　使わせないのが基本 　TSIGの利用

連載 実用 BIND 9で作るDNSサーバ

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード