DNSサーバーの重要設定「allow-query」「allow-recursion」「allow-transfer」の徹底解説
以下の記事では、DNSサーバの設定でよく登場する allow-query、allow-recursion、allow-transfer の3つのディレクティブについて、なるべく詳細に、かつ分かりやすく解説します。DNSの基本からそれぞれのディレクティブの機能・違い・設定方法などを網羅的に解説し、実際の運用シーンでどのように使い分けるべきかも含めて説明します。
- 記事の構成は以下の通りです:
- DNSの基礎知識
- DNSサーバにおけるアクセス制御の重要性
- allow-query とは
- allow-recursion とは
- allow-transfer とは
- 3つのディレクティブの比較表
- 設定例 (BINDを想定)
- 運用での注意点とベストプラクティス
- よくある質問 (FAQ)
- まとめ
1. DNSの基礎知識
1-1. DNSの役割
DNS (Domain Name System) は、ドメイン名とIPアドレスを相互に変換する仕組みを提供するシステムです。たとえば、ウェブブラウザに www.example.com と入力すると、実際には 93.184.216.34 などのIPアドレスへの変換が行われ、そのIPアドレスを使ってサーバへアクセスします。もしDNSが存在しなければ、人間にとって覚えやすいドメイン名とマシンが理解できるIPアドレスの対応を管理することが非常に困難となります。
1-2. DNSサーバの種類
DNSサーバには役割によって以下のような種類があります。
-
権威DNSサーバ (Authoritative DNS Server)
- 特定のゾーンのデータ(例: example.com ゾーン)を正確に保持し、問い合わせがあった場合に正しい情報を返すサーバです。
- プライマリ(マスター)サーバ、セカンダリ(スレーブ)サーバに分かれ、プライマリからセカンダリへゾーン転送が行われます。
-
キャッシュDNSサーバ (Caching DNS Server / リカーシブサーバ)
- ユーザからの問い合わせを代理で解決し、結果をキャッシュに保持する役割をもつサーバです。
- 自分が権威を持たないゾーンの問い合わせに対しては、外部のDNSをたどって最終的な解決を試みます(リカーシブ・クエリ)。
-
フォワーダ (Forwarder)
- 外部問い合わせ時に特定のサーバに対して問い合わせを一任(フォワード)するDNSサーバです。
- 自身で再帰問い合わせをせず、フォワーダ先のDNSサーバが再帰問い合わせを行う場合もある。
1-3. ゾーン転送(Zone Transfer)とは
ゾーン転送は、プライマリDNSサーバからセカンダリDNSサーバへのゾーンデータのコピー作業を指します。これにより、セカンダリサーバはプライマリと同じ情報を持ち、可用性や冗長性を高めることができます。
BINDなどのDNSサーバでは、ゾーン転送を許可する相手を指定するために allow-transfer ディレクティブを用います。
2. DNSサーバにおけるアクセス制御の重要性
DNSはインターネットの根幹を支える重要なインフラです。そのため、DNSサーバの設定を誤ると、以下のようなリスクが発生します。
-
不必要な問い合わせへの応答
- 意図しない第三者からの問い合わせに応答してしまうと、情報漏洩やDNSアンプリフィケーション攻撃の踏み台になる可能性があります。
-
情報漏洩
- ゾーン情報が外部にまるごと流出すると、組織のネットワーク構成などが把握され、セキュリティ上のリスクが高まります。
-
キャッシュの悪用
- DNSキャッシュポイズニングの脆弱性を利用されたり、リカーシブ機能を使われて不要なトラフィックが増えたりするリスクが高まります。
-
権威DNSサーバの負荷増大
- 通常、権威DNSサーバは自ゾーンへの問い合わせに対してのみ権威ある回答を行うことが目的ですが、設定によってはリカーシブ問い合わせまで処理してしまい、余分な負荷がかかることがあります。
これらのリスクを回避するためには、適切なアクセス制御が不可欠です。このアクセス制御を実装する主なディレクティブが allow-query、allow-recursion、allow-transfer です。
3. allow-query とは
3-1. 概要
allow-query は、DNSサーバが「どのホスト(クライアント)からのDNSクエリ(問い合わせ)に対して回答を返すか」を指定するためのディレクティブです。
具体的には、named.conf (BINDの場合)のゾーン定義やオプションセクションなどで以下のように指定します。
options {
...
allow-query { any; };
...
};
この場合、全てのアドレスからの問い合わせに対して応答を許可する設定となります。
3-2. 役割
DNSサーバには、ゾーン情報に対する 権威回答 を行う権威DNSサーバとしての機能と、外部への問い合わせを行い キャッシュ回答 を行うキャッシュDNSサーバとしての機能がある場合があります。
allow-query は、主に以下の役割を担います。
-
権威回答の制御
- 指定ゾーンに対する問い合わせをどのクライアントに許可するかを設定します。
-
キャッシュ回答の制御 (※混同に注意)
- 権威サーバとキャッシュサーバの両方の機能を兼ねている場合、
allow-queryでキャッシュへの問い合わせも制限することがあります。ただし、キャッシュ回答にはallow-recursionの設定も影響するため、後述の allow-recursion と合わせて考える必要があります。
- 権威サーバとキャッシュサーバの両方の機能を兼ねている場合、
3-3. 運用上の注意
- 権威サーバを外部公開している場合は、基本的に外部からのゾーンに対する問い合わせ(権威回答)を許可する必要があります。そのため、
allow-queryを必要以上に厳しくしすぎると、正当なDNSクエリをブロックしてしまい、名前解決ができなくなる可能性があります。 - 内部向けゾーン(例:
internal.example.com) など、機密性の高い情報を含むゾーンに対しては、アクセスを制限したほうが安全です。たとえば、社内ネットワークセグメントのIPアドレスだけを許可する設定にするなどが挙げられます。
4. allow-recursion とは
4-1. 概要
allow-recursion は、「どのホストからの問い合わせに対して再帰的な名前解決(リカーシブ・クエリ)を行うか」を制御するディレクティブです。
DNSサーバは再帰問い合わせ(リカーシブ・クエリ)を受け付けると、必要に応じて上位のDNSサーバに問い合わせたり、別の権威DNSサーバに問い合わせたりして最終的な回答を取得します。
この再帰問い合わせ機能を外部にむやみに公開すると、DNSアンプリフィケーション攻撃 の踏み台となる恐れがあり、セキュリティリスクが高まります。
4-2. allow-recursionの役割と設定例
たとえば、BINDの設定例は以下のようになります。
options {
recursion yes; // 再帰問い合わせを有効にする
allow-recursion { 192.168.0.0/24; 127.0.0.1; };
...
};
上記の設定では、192.168.0.x のサブネットおよび 127.0.0.1 (localhost) からの問い合わせに対してのみ、リカーシブ・クエリを許可することになります。
もし外部に対しては権威回答だけ行いたい場合は、外部アドレスは allow-recursion に含めないようにします。
4-3. 運用シーンでの活用
-
内部向けキャッシュDNSサーバ
社内ネットワーク内のクライアントは、この内部DNSサーバに問い合わせることで、インターネット上の名前解決を一括で行います。外部からの不要なリカーシブ問い合わせは受け付けないように設定するのが一般的です。 -
外部公開権威サーバ
外部からのリカーシブ問い合わせを受ける必要がない(むしろ受けると危険)ので、allow-recursionの設定を厳しく制限するか、そもそもrecursion no;としてリカーシブ機能をオフにすることが推奨されます。
4-4. キャッシュポイズニングとの関係
キャッシュポイズニング は、悪意ある第三者がDNSサーバのキャッシュに誤った情報を注入する攻撃です。
外部にリカーシブ機能を開放していると、そのDNSサーバへの攻撃の窓口が増え、キャッシュポイズニングリスクが高まります。よって、必要最小限のクライアントにのみリカーシブ問い合わせを許可することが重要です。
5. allow-transfer とは
5-1. 概要
allow-transfer は、ゾーン転送(AXFR/IXFR) をどのホストに対して許可するかを制御するディレクティブです。
ゾーン転送とは、前述の通りプライマリDNSサーバからセカンダリDNSサーバへゾーンデータをコピーする仕組みですが、もし誰にでもゾーン転送を許可すると、外部の第三者が簡単にゾーン情報を取得できてしまいます。これはセキュリティリスクとなり得ます。
5-2. 設定例
zone "example.com" IN {
type master;
file "example.com.zone";
allow-transfer { 192.168.0.2; 203.0.113.10; };
};
この設定例では、example.com のゾーン情報をセカンダリサーバとして 192.168.0.2 と 203.0.113.10 にだけ転送することを許可しています。
5-3. リスクと運用上の注意
-
情報漏洩
ゾーンファイルには組織内部で使うホスト名やサブドメイン情報、メールサーバのホスト名など、潜在的に機密性の高いデータが含まれます。ゾーン転送を無制限に許可すると、攻撃者に組織の内部構造を把握されるリスクが大きくなります。 -
正当なセカンダリサーバのみを許可
企業や組織内で運用しているDNSサーバにおいては、セカンダリサーバのIPアドレスを明示的に指定することで、不要なゾーン転送を防ぎます。 -
hidden master構成
一部の運用形態では、外部公開するDNSサーバはセカンダリのみとし、マスターサーバ(プライマリ)は外部から見えないネットワークに置くことで、ゾーン転送リスクを低減させる方法もあります。
6. 3つのディレクティブの比較表
ここまで述べた3つのディレクティブ(allow-query, allow-recursion, allow-transfer)の主な違いをまとめると、以下のようになります。
| ディレクティブ | 意味 | 設定対象 | 代表的な使い所 |
|---|---|---|---|
| allow-query | 「問い合わせを受け付けるかどうか」を制御 | 権威サーバのゾーン、またはグローバル | - 外部からの権威回答を許可する - 内部ゾーンを内部だけに限定する |
| allow-recursion | 「再帰問い合わせを受け付けるかどうか」を制御 | キャッシュサーバ(リカーシブ)としての機能 | - 内部ネットワークだけ再帰を許可 - 外部からは再帰を拒否 |
| allow-transfer | 「ゾーン転送を許可するかどうか」を制御 | 権威サーバのゾーン | - セカンダリサーバだけにゾーン転送を許可 - 情報漏洩防止 |
7. 設定例 (BINDを想定)
以下に、BIND 9を想定した設定例を示します。環境によってディレクティブの配置場所( options { ... }; や ゾーンセクションなど )が異なることもありますが、大枠としての設定イメージを掴んでいただければと思います。
7-1. 全体像
options {
// 再帰問い合わせの有効／無効を指定
recursion yes;
// 再帰問い合わせを許可するクライアント
allow-recursion { 192.168.0.0/24; 127.0.0.1; };
// クエリへの応答を許可するクライアント
// （オプションセクションで一括指定する場合）
allow-query { any; };
};
zone "example.com" IN {
type master;
file "/var/named/example.com.zone";
// このゾーンに対するクエリの許可設定を個別に行う場合
// allow-query { 203.0.113.0/24; };
// ゾーン転送の許可
allow-transfer { 192.168.0.2; 203.0.113.10; };
};
7-2. ポイント
-
recursion yes;とallow-recursion { ... };のセット-
recursion yes;として再帰機能を有効にしつつ、外部からの不必要な問い合わせを受け付けないようにallow-recursionを指定する。
-
-
allow-queryの使い所- 外部公開サーバとして動作させる場合は、権威ゾーンに対して外部からのクエリを受け付ける必要があるため
allow-query { any; };とすることが多い。 - ただし内部ゾーンなど、公開したくないゾーンに対しては社内セグメントやVPN経由のみ許可するように IPアドレス制限を行う。
- 外部公開サーバとして動作させる場合は、権威ゾーンに対して外部からのクエリを受け付ける必要があるため
-
allow-transferでの制限- ゾーン転送はセカンダリサーバとして使っているIPだけを厳格に指定する。
- 指定しないと、誰でも
dig axfr example.comでゾーン情報を取得できてしまう恐れがある。
8. 運用での注意点とベストプラクティス
8-1. 内部と外部でDNSを分離する (Split DNS)
-
内部向けDNSサーバ
- 社内ネットワーク向けにリカーシブ機能を提供し、内部ゾーンを管理する。
-
allow-recursionは内部アドレスのみ許可。 - 機密性の高いゾーンファイルは内部用のみの権威サーバで管理。
-
外部向けDNSサーバ
- インターネットからの問い合わせに対しては、権威回答のみを返す。
-
recursion no;または外部IPについてはallow-recursionを指定しない(拒否する)。 -
allow-transferも必要最小限のセカンダリIPに限定。
これにより、外部には不要な情報を晒さず、内部ユーザにのみ必要な機能を提供できます。これを一般に Split DNS と呼びます。
8-2. DNSSECとの併用
DNSレコードの正当性を保証する仕組みとして DNSSEC (DNS Security Extensions) があります。
allow-query や allow-recursion でクライアントを制限することは、DNSSECとは直接の関係はありませんが、外部向け権威サーバを運用する場合はDNSSECの導入も合わせて検討することで、セキュリティをさらに高められます。
8-3. ログの活用
-
クエリログ (querylog)
不審なアクセスがあった場合にすぐ対処できるよう、クエリログを適切に記録し監視することが大切です。ただしクエリログは大量に発生するので、システム負荷とのバランスを考慮しましょう。 -
ゾーン転送ログ
不要なゾーン転送が試みられていないか、ログを確認しておくことも有効です。
8-4. バージョン情報の隠蔽
BINDの場合、デフォルト設定では version.bind などの特別なクエリを投げることでバージョン情報が取得できるケースがあります。攻撃者が脆弱性を探す手がかりになる可能性があるため、version オプションなどでBINDのバージョンを隠す設定も推奨されます。
options {
...
version "not disclosed";
};
9. よくある質問 (FAQ)
Q1. allow-query と allow-recursion の違いが分かりません
- allow-query は「そのサーバが権威を持つゾーンに対する問い合わせ」への回答の可否を制御します。
- allow-recursion は「サーバが権威を持たないゾーンについても、代理で解決(再帰)して回答を返すかどうか」を制御します。
Q2. 内部DNSサーバでも allow-query { any; }; にしていいですか？
- 内部DNSサーバは原則として社内ネットワーク内からしかアクセスされないので、
allow-query { 192.168.0.0/24; 127.0.0.1; };のように制限をかけておくのがベターです。全世界に開放する必要はありません。
Q3. allow-transfer を設定しないとゾーン転送はどうなりますか？
- BINDのバージョンやデフォルト設定にもよりますが、古い設定だと全てのホストからのAXFRリクエストが通ってしまう場合があります。バージョンによってはデフォルトで
none;になるものもありますが、いずれにせよ明示的に設定しておくのが安全です。
Q4. allow-query と zone "example.com" { allow-query{}; }; の優先度は？
- ゾーンごとに設定した
allow-queryの指定が優先されます。 -
options { ... };内の設定はグローバルデフォルトとして適用され、ゾーンごとの設定がより具体的な設定として上書きします。
Q5. allow-recursion を設定しているのに再帰が効かない
-
recursion yes;を忘れていたり、forward only;の指定が影響している可能性があります。DNS構成を再確認し、再帰のフローが想定どおりになっているかをチェックしましょう。
10. まとめ
DNSサーバの運用においては、権威回答 と リカーシブ回答 の両面を正しく制御することが欠かせません。
そのために必要となる主な設定が allow-query, allow-recursion, allow-transfer の3つです。まとめると以下のようになります。
-
allow-query
- 権威ゾーンに対して「どのクライアントからの問い合わせを受け付けるか」を制御する。
-
allow-recursion
- 「どのクライアントに再帰問い合わせを提供するか」を制御する。
- 外部に開放してしまうとDNSアンプリフィケーション攻撃の踏み台になる恐れがあるため、内部ネットワークのみに制限するのが一般的。
-
allow-transfer
- ゾーン転送を許可するクライアント(セカンダリサーバ)を指定する。
- ゾーン情報が外部に漏れることを防ぐためにも、正当なセカンダリサーバのみを指定するのが必須。
これらを適切に設定し、かつ Split DNS やログ監視、DNSSECの導入など総合的なセキュリティ対策を行うことで、安全かつ効率的なDNSサーバ運用を実現できます。
補足: 簡易的な図解
以下に、内部DNSサーバと外部DNSサーバを分離した典型的な構成イメージを示します。(ASCIIアート風)
+--------------------------+
| インターネット |
+-----------+--------------+
|
| (allow-query for example.com)
v
[外部DNSサーバ]
recursion no;
allow-query { any; };
allow-recursion { none; };
allow-transfer { セカンダリのIP }; <- 外部のセカンダリサーバ用
|
| (権威回答のみ)
v
----------------------------------------
(FW/境界)
----------------------------------------
^
| (allow-recursion from internal)
|
[内部DNSサーバ]
recursion yes;
allow-recursion { 192.168.0.0/24 };
allow-query { 192.168.0.0/24 };
allow-transfer { 内部セカンダリのIP };
^
|
内部ネットワーク
- 外部DNSサーバは権威回答に特化し、再帰問い合わせや不要な転送をシャットアウト。
- 内部DNSサーバは社内クライアントの代理リゾルバとして機能。外部への問い合わせは内部DNSサーバが実施(フォワードか再帰かは環境次第)。
参考文献・情報源
- BIND 9 Administrator Reference Manual (ISC)
- 日本ネットワークインフォメーションセンター (JPNIC)
- RIPE NCC DNS関連ガイド
- 各種DNSセキュリティベストプラクティス文書
上記で述べたように、DNSサーバの設定では allow-query, allow-recursion, allow-transfer が重要な3本柱となります。
適切に制限・運用することで、セキュリティリスクを大きく軽減できるだけでなく、不要なトラフィックを抑えてサーバ負荷を低減することにもつながります。ぜひ、自身の運用ポリシーやネットワーク構成に合わせて最適な設定を行ってみてください。
Discussion