---------------------------------------------------------------------
■設定ガイド：ゾーン転送要求への応答を制限するには【BIND編】
株式会社日本レジストリサービス（JPRS）
初版作成 2016/01/12（Tue）
---------------------------------------------------------------------
▼はじめに
本資料は、意図しないゾーン転送を許可する状態になっているBINDの設定を、
簡単なステップで修正する事を目的としています。
ゾーン転送についての技術的な解説は本資料では行いません。手順に沿った
操作で設定を変更し、読者が運用するDNSサーバーが意図しないゾーン転送
を許可する状態ではなくなることを目指しています。
ゾーン転送の設定不備及びそれを利用した情報流出の危険性につきましては、
以下の文書をご参照ください。
■権威DNSサーバーの設定不備による情報流出の危険性と設定の再確認について
<http://jprs.jp/tech/security/2016-01-12-unauthorized-zone-transfer.html>
▼本資料の前提
▽本資料の対象
本資料は、BINDを用いたDNSサーバーを運用している管理者、特にDNSサーバー
を運用しているが普段設定を自分で変更する事がなく、手順の解説が欲しい
と思っている管理者を想定して記載しています。
本資料は現行のBIND 9を対象としていますが、ほぼ同様の作業でBIND 8でも
ゾーン転送要求への応答を制限することは可能です。この対応については文
中、以下のマークで注意点を記載します。
[B8] BIND 8に関する注意点
なお、BIND 8は開発元であるISCのサポートが既に終了しています。JPRSで
は、現在ISCまたはご利用のOSのベンダーによってサポートされている最新
版のBINDの使用を強く推奨します。
▽記載内容について
本資料では、BINDの一般的な設定に対するオペレーションを記載しています。
OSやディストリビューションに依存する点があり操作が不明な場合は、該当
するベンダーのサポート窓口や保守業者にお問い合わせください。
また、具体的な設定内容の詳細については、BIND 9に付属のAdministrator
Reference Manual（ARM）をご参照ください。
▼ゾーン転送要求への応答制限の設定手順
BINDを運用している管理者は、以下の六つの手順を確認の上、適切な設定の
修正を行ってください。これにより、ゾーン転送の設定不備及びそれを利用
した情報流出の危険性を取り除く事が出来ます。
手順1: 事前確認
手順2: 作業の準備
手順3: 設定の確認
手順4: 設定の修正
手順5: 修正の反映
手順6: 修正反映の確認
▽手順1: 事前確認
[説明]
意図しないゾーン転送を許可する状態で動作しているかどうかをチェック
します。
[実施内容]
自ら運用しているDNSサーバー・ゾーンが意図しないゾーン転送を許可す
る状態で動作しているかどうかを、digコマンドを用いて確認します。
※実際の確認では、引数の「@ns1.example.jp」で調査したいDNSサーバー
のホスト名、続く「example.jp」で調査対象のゾーンを指定します。
$ dig +norec @ns1.example.jp example.jp axfr
・ゾーン転送が許可された場合の出力例（ゾーンの内容を表示）：
...
example.jp. 86400 IN SOA ns1.example.jp. root.jprs.co.jp. 1 3600 900 1814400 900
example.jp. 86400 IN NS ns1.example.jp.
example.jp. 86400 IN NS ns2.example.jp.
ns1.example.jp. 86400 IN A 192.0.2.1
ns2.example.jp. 86400 IN A 192.0.2.11
www.example.jp. 86400 IN A 192.0.2.10
example.jp. 86400 IN SOA ns1.example.jp. root.jprs.co.jp. 1 3600 900 1814400 900
...
・ゾーン転送が拒否された場合の出力例：
...
; Transfer failed.
セカンダリサーバー以外でdigコマンドを実行した際にゾーンの内容が表
示された場合、意図しないゾーン転送を許可する状態で動作しています
（*1）。
（*1）上記の例では、ゾーン転送を許可する状態かどうかのみを確認して
います、Transfer failed.と表示される状態であっても、別の相手
にはゾーン転送を許可している可能性があります。
もし、意図しないゾーン転送を許可する状態で動作していると判明した場
合、以下の手順に沿って対策を実施してください。
▽手順2: 作業の準備
[説明]
設定を修正するにあたり必要な情報を確認し、権限などを準備します。
1）設定ファイルの場所の確認
2）対象のDNSサーバーが権威DNSサーバーか、
フルリゾルバー（キャッシュDNSサーバー）かの確認
3）ゾーン転送を許可するIPアドレスのリストの確認
4）BINDのバージョンの確認
5）BIND設定ファイルの編集及び再起動の権限の準備
[実施内容]
1）設定ファイルの場所の確認
BINDの設定は、通常の場合以下のテキストファイルに記載されます。
/etc/named.conf もしくは /usr/local/etc/named.conf
2）対象のDNSサーバーが権威DNSサーバーかフルリゾルバー（キャッシュ
DNSサーバー）か、また、権威DNSサーバーであった場合、プライマリ
サーバーかセカンダリサーバーかの確認
作業対象のサーバーが、DNSのどの機能を担っているかを確認します。
3）ゾーン転送を許可するIPアドレスのリストの確認
運用するゾーンのすべてのセカンダリサーバーのIPアドレスを、事前に
知っておく必要があります。
4）BINDのバージョンの確認
BINDのバージョンはrndcコマンドで確認できます。
$ rndc status
version: 9.10.3-P2 ← バージョン
number of zones: 1
...
--------------------------------------------------------------
[B8] BIND 8のでは、rndcコマンドの代わりにndcコマンドを用います。
$ ndc status
named 8.4.7-REL Mon Apr 15 19:49:23 JST 2013 foo@bar:/tmp/bind/src/bin/named
^^^^^^^^^ バージョン
config (/etc/named.conf) last loaded at age: Tue Apr 16 10:59:46 2013
...
--------------------------------------------------------------
5）BIND設定ファイルの編集及び再起動の権限の準備
設定ファイルの変更後に変更内容を反映させるためには、rndcコマンド
を用います。標準的なコマンドの場所は以下になります。
/usr/sbin/rndc もしくは /usr/local/sbin/rndc
--------------------------------------------------------------
[B8] BIND 8の場合は、rndcコマンドの代わりにndcコマンドを用います。
標準的なコマンドの場所は以下になります。
/usr/sbin/ndc もしくは /usr/local/sbin/ndc
--------------------------------------------------------------
なお、設定ファイルの編集及び変更内容の反映にはroot権限が必要な場
合があります。
▽手順3: 設定の確認
[説明]
設定ファイル（named.conf）の中で、ゾーン転送の許可に関連するオプショ
ンを設定します。
[実施内容]
設定ファイルを開き、以下のオプションが記載されている場所と内容を確
認します。
・allow-transfer
★もしallow-transferオプションの設定がされていない場合デフォルト設
定値のanyが適用され、すべてのゾーン転送を許可する設定になってし
まうことに特に注意が必要です。
options {
// allow-transferオプションの設定例
// すべてのゾーンについて、192.0.2.11からのみゾーン転送を許可
allow-transfer { 192.0.2.11; };
};
zone "example.jp" IN {
type master;
// allow-transferオプションの設定例
// example.jpゾーンについて、192.0.2.11からのみゾーン転送を許可
allow-transfer { 192.0.2.11; };
};
▽手順4: 設定の修正
[説明]
設定ファイルを修正します。本資料で設定する内容は以下の通りです。
A）プライマリサーバーであった場合、セカンダリサーバーのIPアドレス
のみ、ゾーン転送を許可します。
B）セカンダリサーバーまたはフルリゾルバーであった場合、すべてのゾー
ン転送要求を拒否します。
[実施内容]
設定ファイルのallow-transferオプションの部分を、以下のように編集し
ます（*2）。allow-transferオプションがない場合、新規に追加します。
編集の前に、設定ファイルのバックアップをとるようにしてください。
（*2）ファイルの変更にはroot権限が必要な場合があります。その場合、
su、sudoコマンドなどにより、root権限を入手したうえで作業して
ください。
A）プライマリサーバーであった場合、セカンダリサーバーのIPアドレス
のみ、ゾーン転送を許可します。
設定例を以下に示します。実際の設定では {} 内の「192.0.2.11」と
「198.51.100.1」でセカンダリサーバーのIPアドレスを指定します。
options {
// allow-transferオプションの設定例
// 指定したIPアドレスからのゾーン転送のみ許可
allow-transfer { 192.0.2.11; 198.51.100.1; };
};
権威DNSサーバーがIPv6でサービスを提供している場合、
allow-transferオプションでIPv6アドレスも併せて指定します。
options {
// allow-transferオプションの設定例
// 指定したIPアドレスからのゾーン転送のみ許可
// IPv6アドレスも併せて指定
allow-transfer { 192.0.2.11; 198.51.100.1;
2001:db8:1::1; 2001:db8:2::1; };
};
運用するゾーンによりセカンダリサーバーが異なる場合は、ゾーンご
とにゾーン転送を許可するIPアドレスを指定します。
設定例を以下に示します。実際の設定では「example.jp」
「example2.jp」で設定対象のゾーンを、「192.0.2.10」
「198.51.100.10」「192.0.2.20」「203.0.113.20」で、
各セカンダリサーバーのIPアドレスを指定します。
options {
// allow-transferオプションの設定例
// ゾーンごとにゾーン転送を許可するため、
// グローバルオプションではすべてのゾーン転送を拒否する
allow-transfer { none; };
};
zone "example.jp" IN {
type master;
// allow-transferオプションの設定例
// example.jpゾーンについて、
// 指定したIPアドレスからのゾーン転送のみ許可
allow-transfer { 192.0.2.10; 198.51.100.10; };
};
zone "example2.jp" IN {
type master;
// allow-transferオプションの設定例
// example2.jpゾーンについて、
// 指定したIPアドレスからのゾーン転送のみ許可
allow-transfer { 192.0.2.20; 203.0.113.20; };
};
権威DNSサーバーがIPv6でサービスを提供している場合、
allow-transferオプションでゾーン転送を許可するIPv6アドレスも
併せて指定します。
options {
// allow-transferオプションの設定例
// ゾーンごとにゾーン転送を許可するため、
// グローバルオプションではすべてのゾーン転送を拒否する
allow-transfer { none; };
};
zone "example.jp" IN {
type master;
// allow-transferオプションの設定例
// example.jpゾーンについて、
// 指定したIPアドレスからのゾーン転送のみ許可
// IPv6アドレスも併せて指定
allow-transfer { 192.0.2.10; 198.51.100.10;
2001:db8:1::10; 2001:db8:2::10; };
};
zone "example2.jp" IN {
type master;
// allow-transferオプションの設定例
// example2.jpゾーンについて、
// 指定したIPアドレスからのゾーン転送のみ許可
// IPv6アドレスも併せて指定
allow-transfer { 192.0.2.20; 203.0.113.20; };
2001:db8:1::20; 2001:db8:2::20; };
};
B）セカンダリサーバーまたはフルリゾルバーとして運用している場合、
すべてのゾーン転送要求を拒否します。
options {
// allow-transferオプションの設定例
// すべてのゾーン転送要求を拒否
allow-transfer { none; };
};
▽手順5: 修正の反映
[説明]
修正した設定を反映させます。
[実施内容]
rndcコマンドで変更した設定を反映させます（*3）。なお、事前に
named-checkconfコマンドでエラーがないことを確認しておくとより安全
です。
（*3）コマンドの実行にはroot権限が必要な場合があります。その場合、
su、sudoコマンドなどにより、root権限を入手したうえで作業して
ください。
$ named-checkconf
$ rndc reload
------------------------------------------------------------------
[B8] BIND 8の場合は、rndcコマンドの代わりにndcコマンドを用います。
また、named-checkconfコマンドはBIND 9で提供されたものであるた
め、存在しません。
$ ndc reload
------------------------------------------------------------------
サーバーを再起動してよい場合、再起動を行う事でも設定は反映されます。
▽手順6: 修正反映の確認
[説明]
修正が正しく反映されたことを、digコマンドを用いて確認します。
[実施内容]
事前確認と同様、digコマンドを用いて再確認を実行します。
※実際の確認では、引数の「@ns1.example.jp」で調査したいDNSサーバー
のホスト名、続く「example.jp」で調査対象のゾーンを指定します。
$ dig +norec @ns1.example.jp example.jp axfr
1）意図しないゾーン転送を許可していないこと
セカンダリサーバー以外でdigコマンドを実行した際に、以下の出力例
のようにゾーン転送が拒否されることを確認します。
・ゾーン転送が拒否された場合の出力例：
...
; Transfer failed.
もし、確認結果がゾーンの内容が表示される状態のままである場合、以
下の確認を行ったうえで、再度手順に従って作業を実施してください。
・設定ファイルの場所が正しいか
・設定の修正内容は正しいか
・修正の反映が正しく出来ているか
2）セカンダリサーバーにゾーン転送を許可していること
セカンダリサーバーでdigコマンドを実行した際に、以下の出力例のよ
うにゾーン転送が許可されることを確認します。
・ゾーン転送が許可された場合の出力例（ゾーンの内容を表示）：
...
example.jp. 86400 IN SOA ns1.example.jp. root.jprs.co.jp. 1 3600 900 1814400 900
example.jp. 86400 IN NS ns1.example.jp.
example.jp. 86400 IN NS ns2.example.jp.
ns1.example.jp. 86400 IN A 192.0.2.1
ns2.example.jp. 86400 IN A 192.0.2.11
www.example.jp. 86400 IN A 192.0.2.10
example.jp. 86400 IN SOA ns1.example.jp. root.jprs.co.jp. 1 3600 900 1814400 900
...
セカンダリサーバーにゾーン転送が許可されていることは、運用するゾー
ンの内容の変更が反映されることでも確認できます。
▼連絡先
本資料に関するお問い合わせは <dnstech-info@jprs.jp> までご連絡ください。
---------------------------------------------------------------------
▼更新履歴
2016/01/12 11:00 初版作成
株式会社日本レジストリサービス Copyright©2001-2024 Japan Registry Services Co., Ltd.