【ITニュース解説】Zone Transfer Controls Need an ACL Test, Not a Comment Review

インターネットの基盤であるDNS（Domain Name System）は、私たちがウェブサイトにアクセスする際に、ドメイン名（例: example.com）をコンピュータが理解できるIPアドレス（例: 192.0.2.1）に変換する役割を担う、いわばインターネットの住所録だ。この住所録の情報は「ゾーン」という単位で管理されており、各ゾーンは特定のドメインに関するすべてのレコード（WebサーバーのIPアドレス、メールサーバーの情報など）を含んでいる。

このゾーンの情報を、あるDNSサーバーから別のDNSサーバーへ丸ごとコピーする仕組みを「ゾーン転送」と呼ぶ。これは、主にプライマリ（主）DNSサーバーが管理する最新のゾーン情報を、セカンダリ（副）DNSサーバーに複製し、負荷分散や冗長性を確保するために非常に重要な機能だ。しかし、このゾーン転送は、適切に管理されないと重大なセキュリティリスクとなる。もし、悪意のある第三者がゾーン転送によってゾーンの全レコードを入手できてしまうと、ネットワークの構成、利用しているサービス、サーバーの具体的な情報などが筒抜けになり、その情報が悪用される可能性があるため、不特定多数のインターネットユーザーにゾーン転送を許可することは絶対に避けなければならない。

このゾーン転送を制御するための設定が、広く利用されているDNSサーバーソフトウェアであるBINDでは、「allow-transfer」というステートメントによって行われる。この設定は、どのホスト（IPアドレスやネットワーク）からのゾーン転送要求を許可するかを指定するものだ。allow-transferの設定は、BINDの設定ファイル内で、「ゾーン」（特定のドメインにのみ適用）、「ビュー」（クライアントのIPアドレスなどによって異なる応答をする設定群）、「グローバルオプション」（サーバー全体に適用）のいずれかのレベルで指定できる。重要なのは、これらの設定には優先順位があり、より限定的な範囲（ゾーンレベル）での設定が、より広範な設定（グローバルオプションレベル）を上書きするということだ。そのため、ゾーン転送のセキュリティを確認する際には、設定ファイル全体を、この優先順位のルールに従って確認する必要があり、ファイルの一番上にある設定だけを見て判断してはいけない。

また、BINDのバージョンによってallow-transferのデフォルトの動作が異なる可能性がある点も注意が必要だ。例えば、最新のBINDバージョンでは、明示的にallow-transfer ACL（Access Control List：アクセス制御リスト）を設定しない限り、ゾーン転送は無効になるよう変更されている場合がある。しかし、古いバージョンでは、明示的な設定がない場合に転送が許可されてしまうケースも存在するため、利用しているBINDのバージョンに対応する公式マニュアルを必ず確認し、そのバージョンにおける正しい設定方法とデフォルト動作を把握することが極めて重要となる。安易に「設定していないから安全だろう」と仮定してはいけない。

allow-transferで指定するACLは、具体的にセカンダリDNSサーバーのIPアドレスや、そのサーバー群が属する限定されたネットワーク範囲を記述すべきだ。「内部のみ」といったコメントを記述するだけでは、それは単なるメモに過ぎず、具体的なアクセス制御のポリシーにはならない。このようなコメントがある場合でも、本当にそのゾーンがパブリックな情報を含むべきではないのか、そしてそのACLが具体的かつ適切に設定されているかを厳しく確認する必要がある。

設定が完了したら、それが意図通りに機能しているかをテストすることが不可欠だ。digコマンドとAXFRオプションを使って、実際にゾーン転送を試すことで確認できる。例えば、「dig @192.0.2.53 example.com AXFR」のようなコマンドで、対象のDNSサーバー（@の後ろにIPアドレス）に対して、特定のゾーン（example.com）のゾーン転送を要求する。このテストは二つの側面から行う必要がある。まず、ゾーン転送を許可すべき正当なセカンダリサーバーから転送が成功することを確認する。次に、許可されていない任意のクライアント、特に管理ネットワークの外部や、インターネットに露出する可能性のあるアドレスクラスから転送を試み、その要求が確実に拒否されることを確認する。自身のPCからのテストで転送が拒否されたとしても、それは外部からのアクセスが保護されていることを証明しないため、外部からのテストは必須となる。

BINDの「ビュー」機能を利用しているサーバーの場合、クライアントのソースIPアドレスや宛先IPアドレスによって異なるゾーン情報を提供することがあるため、それぞれのビューに対して上記と同じテストを繰り返す必要がある。あるビューからの転送が拒否されても、別のビューからは許可されてしまう可能性も考慮に入れなければならない。

また、allow-transferルールを変更した後は、それがゾーン同期に悪影響を与えていないかを確認する。設定を厳しくしすぎると、正当なセカンダリサーバーとのゾーン同期が失敗し、情報が古くなる可能性がある。セカンダリサーバーのログを確認し、転送失敗のエラーが出ていないか、セカンダリサーバーにコピーされたゾーンのシリアル番号がプライマリサーバーのものと一致しているか、そしてレコードセットが最新の状態であるかを検証する。管理用のホストからdigコマンドでゾーン転送が成功したとしても、それは実際のセカンダリサーバーが正しく更新されていることを保証するものではない。

DNSSEC（DNS Security Extensions）で署名されたゾーンを扱っている場合は、ゾーン転送に意図したレコードがすべて含まれているか、そして署名に用いられるキー（鍵）などの機密情報が、診断ログなどに誤って露出していないかを確認する必要がある。設定ファイルやキー素材へのアクセスは、最小限の権限を持つユーザーにのみ許可し、厳重に管理することが重要だ。ゾーン転送のポリシーはゾーン内のレコードのセキュリティを守るが、サーバー自体の設定ミスや、ソフトウェアの脆弱性に対するパッチ適用不足といった、より広範なセキュリティ問題からはサーバーを守ることはできない。

これらのテストは一度行ったら終わりではなく、その証拠を詳細に記録し続けることが大切だ。具体的には、適用されている有効な設定内容、BINDのバージョン、テストを実行したソースIPアドレス、実行したコマンドとそれに対するサーバーの応答、テスト日時、そして設定変更後にサーバーのリロードが必要だったか否かなどを記録する。もしACLがテンプレートによって管理されている場合は、最終的にサーバーに適用された具体的な設定内容（レンダリングされた出力）も記録しておくことで、将来のレビュー者がサーバーに何が届いたかを正確に把握できるようになる。

ゾーンが追加されたり、別のサーバーに移動したり、ドメインの移管（デリゲーション変更）によって新しい外部のDNSサーバーが内部のセカンダリサーバーのように見えたりする場合など、サーバー環境に変化があった際には、必ずallow-transferのルールを再レビューする必要がある。古いACL設定が残っていると、すでに組織に属していない古いホストに誤ってゾーン転送のアクセス権を与えてしまったり、逆に正当な新しいセカンダリサーバーへのゾーン転送をブロックしてしまったりする可能性があるからだ。ゾーン転送のセキュリティは、一度設定したら終わりではなく、継続的な監視とレビューが必要な領域である。最終的に、許可されたセカンダリサーバーからの転送が成功し、無関係なネットワークからの転送が失敗し、かつ転送されたゾーンコンテンツが最新であることを示す一連のテスト結果を、ACLのレビューに添付することで、その設定が正しく機能していることの明確な証拠とすることができる。