DNSループ構成の危険性｜フォワーダ設定ミスで発生する名前解決障害を理解する
KoAN
目次
DNSループ構成の危険性
DNSサーバを構築する際、複数のDNSサーバを連携させることは珍しくありません。
企業ネットワークではフォワーダを利用した構成や、複数拠点間でDNSを連携する構成がよく採用されています。
しかし設定を誤ると、DNS問い合わせが無限に循環する「DNSループ」が発生することがあります。
DNSループは単なる設定ミスではなく、名前解決不能やDNSサーバの高負荷を引き起こす重大な障害です。
本記事ではDNSループの仕組みや発生原因、確認方法、対策について解説します。
DNSループとは
DNSループとは、DNS問い合わせが複数のDNSサーバ間で循環し続ける状態です。
例えばDNSサーバAとDNSサーバBが存在するとします。
DNS-A
↓
DNS-B
↓
DNS-A
↓
DNS-B
問い合わせが終了せず、同じDNSサーバ間を往復し続けます。
なぜ発生するのか
最も多い原因はフォワーダ設定ミスです。
例えば次の構成です。
DNS-A
forwarders {
192.168.60.20;
}
DNS-B
forwarders {
192.168.60.10;
}お互いをフォワーダに設定しています。
これがDNSループの典型例です。
問い合わせの流れ
利用者が問い合わせます。
www.example.com
DNS-Aへ到達します。
Client
↓
DNS-A
DNS-AはDNS-Bへ転送します。
DNS-A
↓
DNS-B
DNS-BはDNS-Aへ転送します。
DNS-B
↓
DNS-A
以後繰り返されます。
企業ネットワークでの発生例
本社と支社にDNSサーバがある構成です。
本社DNS
↓
支社DNS
↓
本社DNS
相互フォワーダ設定によって発生することがあります。
Active Directory環境の例
Windows DNSでも発生します。
ドメインコントローラ同士で誤設定すると次のようになります。
DC1 DNS
↓
DC2 DNS
↓
DC1 DNS
名前解決が失敗します。
実際の症状
利用者からは次のように見えます。
- Webサイトが開けない
- メール送信できない
- 名前解決が遅い
- 断続的に接続できない
DNS障害として認識されます。
DNSサーバ側の症状
サーバ側では次のような現象が発生します。
- CPU使用率上昇
- 問い合わせ数急増
- ログ大量出力
- 応答遅延
大規模環境では深刻な障害になります。
BINDログに現れる例
ログ確認を行います。
$ journalctl -u named
次のようなメッセージが見られることがあります。
query failed
recursion quota exceeded再帰問い合わせ異常が発生しています。
digで確認する
まず名前解決を確認します。
$ dig www.example.com応答時間が異常に長い場合があります。
SERVFAILが発生する
典型的な症状です。
status: SERVFAIL
問い合わせ処理に失敗しています。
tcpdumpで確認する
パケットを確認します。
$ tcpdump -ni any port 53同じ問い合わせが繰り返されている場合があります。
構成図で見る正常例
正常なフォワーダ構成です。
Client
↓
社内DNS
↓
8.8.8.8
問い合わせ経路が一方向です。
構成図で見る異常例
DNS-A
↓
DNS-B
↓
DNS-A
↓
DNS-B
循環しています。
フォワーダ設定確認
BINDではnamed.confを確認します。
forwarders {
8.8.8.8;
1.1.1.1;
};
相互参照になっていないか確認します。
再帰問い合わせの確認
キャッシュDNSでは通常有効です。
recursion yes;
意図しないDNSサーバへ転送していないか確認します。
複数拠点構成での注意点
本社と支社でDNSを運用する場合です。
誤った例です。
本社DNS → 支社DNS
支社DNS → 本社DNS
ループになる可能性があります。
クラウド環境での発生例
AWSやAzureでも発生することがあります。
オンプレDNSとクラウドDNSを連携する際は注意が必要です。
DNSキャッシュが原因で見えにくい
一時的に正常に見えることがあります。
キャッシュが残っているためです。
障害調査を難しくする要因になります。
対策① フォワーダ経路を整理する
最も重要です。
Client
↓
Internal DNS
↓
Public DNS
一方向にします。
対策② ネットワーク構成図を作る
DNSサーバ間の関係を可視化します。
実務では非常に効果があります。
対策③ 定期監査
設定変更時に確認します。
- forwarders
- recursion
- 条件付きフォワーダ
- DNS委任
を確認します。
対策④ digで経路確認
問い合わせ先を明示します。
dig @192.168.60.10 www.example.com
dig @192.168.60.20 www.example.com
応答内容を比較します。
実務でよくある原因ランキング
- 相互フォワーダ設定
- 複数拠点DNS設計ミス
- クラウド連携設定ミス
- Active Directory DNS設定ミス
- 条件付きフォワーダ誤設定
実務で覚えておきたいポイント
- DNSループは問い合わせが循環する障害
- フォワーダ設定ミスが最大の原因
- SERVFAILが発生することが多い
- tcpdumpで確認できる
- 相互参照構成を避ける
- DNS経路を図で管理する
まとめ
DNSループはフォワーダ設定や複数DNSサーバ構成の設計ミスによって発生する障害です。
問い合わせが循環することで名前解決不能や高負荷状態を引き起こし、企業システムへ大きな影響を与える可能性があります。
特に複数拠点やクラウド連携環境では発生しやすいため、DNS経路を明確に設計することが重要です。
DNS運用では「問い合わせがどこへ転送されるか」を常に意識することが安定運用につながります。
