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

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

» 2003年05月10日 00時00分 公開
[鶴長鎮一@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 ゾーン転送の基本的な動作 図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


       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。