(1/3)DNSサーバを運営する場合は、スレーブ・サーバ(セカンダリ・サーバ)で冗長化する必要がある。その際に検討すべきはマスター−スレーブ間のゾーン転送とそのセキュリティである。});規模の大小を問わず、ゾーンサーバは複数台で運用する必要があります。冗長化や負荷分散などさまざまな理由が挙げられますが、何よりドメインを取得してDNSサーバを運用するのであれば、サービスの品質を低下させないという自覚を持つ必要があります。今回はスレーブ・サーバの運用と、そこで使用されるゾーン転送およびそのセキュリティについて見ていきます。スレーブ・サーバとセカンダリ・サーバ本稿では、「マスター・サーバ」のゾーンデータを取得してDNS問い合わせに応答するサーバを「スレーブ・サーバ」と呼んでいます。資料によっては、同様の意味で「プライマリ・サーバ」「セカンダリ・サーバ」が用いられる場合があり、その際「スレーブ・サーバ」はDNS問い合わせを他サーバへ転送し、自身はDNS再帰検索を行わないサーバを指す場合があります。本連載ではオリジナルとなるゾーンデータを所有するサーバを「マスター・サーバ」、ゾーンデータをマスター・サーバから複製して使用するサーバを「スレーブ・サーバ」で統一しています。基本的なスレーブ・サーバの構築ゾーンサーバを複数用意した際、それぞれのサーバで異なるゾーンデータを保持していては、DNS問い合わせごとに異なる応答をしてしまう可能性があります。そこでゾーンデータの一貫性を維持するため、次のような手法でマスター・サーバのゾーンデータを各スレーブ・サーバに反映させます。重要なのはマスター・サーバに保存されたゾーンデータをスレーブ・サーバに反映させることであり、その手法は限定されません。どちらのサーバに問い合わせるのかはクライアント次第であり、ほとんどがNSレコードに指定されたDNSサーバをラウンドロビンで検出します。クライアントにとってはマスターもスレーブも働きに大きな違いはなく(注)、単にゾーンファイルのオリジナル/コピーによって2者の関係が位置付けられているにすぎません。Answer」が返ってきます。Answer」を返します。Transfer)の利用ゾーン転送は最もオーソドックスな手法です。スレーブはマスターのゾーンデータが更新されていることを確認すると、ゾーンデータのダウンロードと再構築を行って、更新されたゾーンデータを有効にします。その際、マスター・サーバ更新の有無はゾーンデータのSOAレコード中のSerialで判定します。Serialの値が大きくなっていれば更新されたと見なし、ゾーン転送(AXFR)を開始します。ゾーン転送の基本的な動作そのほかにも、SOAにはゾーン転送に重要な値を記述します。すべての基礎、マスター・ゾーンサーバの設定で紹介したexample.zoneファイルは次のようになっていました。メール/Webサーバを効率的に動かすゾーン設定参照)を用いています。増加していればゾーン転送を開始します。西暦(4けた)+月(2けた)+日(2けた)+インクリメント値(2けた)が使用されることが多く、32bit値で格納されるため最大値は「4294967295」になります。この値を超えるとゾーンデータの読み込みに失敗するため、注意が必要です。(2)リフレッシュ間隔マスターのゾーンデータの更新確認を行う間隔を指定します。間隔が長過ぎると更新にタイムラグが発生し、短過ぎると頻繁にSOA問い合わせが発生するため、大抵は数時間程度に設定します。(3)リトライ間隔ゾーン転送に失敗した場合、「リトライ間隔」分の間を置き、再度ゾーン転送を試みます。通常は「リフレッシュ間隔」より短い値を指定します。(4)ゾーンの有効期限マスターとのゾーン転送が滞ってしまい、スレーブに保存されたデータが「ゾーンの有効期限」を過ぎた場合は、そのゾーンに対する問い合わせ要求に返答しなくなります。古い内容で返答するより、返答そのものをしない方がいいという考えに基づいています。多くの場合は1週間程度を指定しますが、マスターとの接続状況によっては長めに取ることもあります。(5)ネガティブキャッシュTTLゾーン転送には無関係なため、ここでは省略します。第2回を参照してください。第2回で使用しているexample.jpを例に、マスター/スレーブそれぞれの設定を見ていきましょう。本来、ゾーン転送を許可するホストやセキュリティを考慮した設定をマスター側のnamed.confに加える必要がありますが、マスター/スレーブの働きを理解することに専念するため、その点については後述します。実運用に際しては、後半のセキュリティ対策も施しておきましょう。スレーブ・サーバのnamed.confは次のようにします。"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などで中身を確認できます。startパッケージ付属の起動スクリプトを使用する場合ゾーン転送がうまく行われない場合は、次の点を確認します。TCPの53番ポートが経路の途中でフィルタリングされていないかゾーン転送はUDPではなくTCPを利用します。マスターとスレーブの間にファイアウォールが設置されていたり、iptablesやipchainsでフィルタを掛けている場合は、該当ポートを開放します。マスターでゾーン転送の制限を掛けていないかここまでの説明ではBIND自体のアクセス制限の方法は紹介していませんが、後述のアクセス制限を掛けている場合は、いったん制限を解除します。デバッグに当たっては、実際にスレーブのnamedを起動しなくてもdigコマンドでゾーン転送が実施されるかどうか、確認することができます。axfr以上の見直しで解決しない場合は、/var/log/messagesに出力される詳細なエラーを頼りに問題点を特定しましょう。9.2.2がリリースされました。CA-2002-19:http://www.cert.org/advisories/CA-2002-19.html)、CERTCA-2002-23:http://www.cert.org/advisories/CA-2002-23.html)を修正しています。9の改ざんチェックとインストールを参考に上書きインストールしましょう。9の対象を9.2.1から9.2.2に変更しています。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。