DNSの「全裸」を晒すな：ゾーン転送（AXFR）のリスクと現場の診断術
深夜3時、アラートが鳴り響く。原因はDNSのキャッシュポイズニングやサービス停止ではなく、もっと「静かで致命的な」情報漏洩だった――。
大規模データセンターで運用をしていると、若手から「なぜか外部から内部ネットワークの構成情報が丸見えになっている」と青ざめた顔で相談されることがよくある。その原因の多くは、DNSサーバの設定ミス、特に「ゾーン転送（AXFR）」の権限管理の甘さにある。
今回は、エンジニアなら知っておくべき「DNSゾーン転送の仕組み」と、それを悪用した攻撃、そして現場で即座に脆弱性を診断する dig コマンドの作法について解説しよう。
—
ゾーン転送（AXFR/IXFR）の通信フローを理解する
ゾーン転送とは、プライマリDNSサーバが持つレコード情報を、セカンダリDNSサーバへ丸ごとコピーする仕組みだ。
- AXFR (Asynchronous Full Transfer): ゾーン全体をまるごと転送する。初期同期や障害復旧時に使われる。
- IXFR (Incremental Transfer): 変更があった差分だけを転送する。効率化のための仕組みだ。
本来、これは「許可されたセカンダリDNS」との間でのみ行われるべき神聖な通信だ。しかし、設定を誤れば、世界中の誰からでも「あなたのドメインの全レコードをください」という要求（AXFRリクエスト）が通ってしまう。これが、いわゆる「ゾーン転送の許可（Zone Transfer Leak）」というやつだ。
—
dig を使った現場の診断手法
まずは自分の管理下にあるDNSサーバが、不用意に門戸を開いていないか確認しよう。診断は至ってシンプルだ。以下のコマンドを叩いてみてほしい。
# ターゲットのドメインに対し、ゾーン転送を要求する
# AXFRが許可されていれば、全レコードが流れてくる
dig axfr @ns1.example.com example.com現場の視点：何が起きれば「アウト」なのか
このコマンドを打った時、もしレコードがズラズラと画面に流れてきたなら、即座にその設定を修正する必要がある。攻撃者はこのコマンド一つで、あなたの社内インフラの内部IPアドレス、ホスト名、メールサーバの優先度、さらにはVPNゲートウェイの場所まで、地図を広げるように把握できてしまうからだ。
—
設定の不備：BINDの「やらかしがちな」例
多くの環境で利用されているBINDの設定ファイル（named.conf）を見てみよう。ここをどう書くかで、セキュリティレベルが決まる。
// 悪い例：誰からのAXFR要求も許可してしまう設定
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { any; }; // ここが最大の過ち！
};このように allow-transfer { any; }; と書くのは、家の玄関の鍵を開けっ放しにして「泥棒さん、どうぞ」と言っているようなものだ。
正しい設定：信頼できるIPのみを許可する
実務では、必ずセカンダリDNSのIPアドレスをホワイトリストとして記述する。
// 良い例：特定のIPアドレス（セカンダリDNS等）のみに限定する
acl "secondary-dns" {
192.0.2.5; // セカンダリDNSのIPをここに記述
};
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { "secondary-dns"; }; // これで安心
};—
プログラムからDNS情報を取得する場合の注意点
Web API設計やインフラ自動化の文脈では、dig コマンドをシェルスクリプトで叩くのではなく、Pythonの dnspython ライブラリなどを使って自動監視を組むのがスマートだ。
import dns.zone
import dns.query
# ゾーン転送の可否をプログラム的にチェックするスニペット
try:
# ゾーン転送を試みる（AXFR）
zone = dns.zone.from_xfr(dns.query.xfr('192.0.2.1', 'example.com'))
print("警告：ゾーン転送が許可されています！")
except Exception as e:
# 許可されていない場合は例外が発生するので、基本はここでキャッチ
print("安全です：ゾーン転送は拒否されました。")—
最後に：なぜこれが「障害」なのか
DNSのゾーン転送漏れは、システムがダウンするわけではない。しかし、インフラ構成情報という「一番守るべき地図」を外部に晒す行為は、将来的な大規模攻撃の踏み台になることを意味する。
「動いているから大丈夫」ではない。ネットワークエンジニアとしての真価は、こうした「見えない脆弱性」をCLIで一つずつ潰していく泥臭い積み重ねにある。
明日オフィスに着いたら、まず自社のドメインを dig axfr してみよう。もし何も返ってこないなら、君のインフラは一つ、強固になっているはずだ。それが、プロの仕事というものだ。
コメント