ゾーン転送が失敗する原因とは？AXFR・IXFRトラブルの確認ポイントを解説
KoAN
目次
ゾーン転送が失敗する原因
DNSサーバを冗長化する際、プライマリDNS（マスターDNS）とセカンダリーDNS（スレーブDNS）を構成することは一般的です。
そして、その構成を支える重要な仕組みがゾーン転送です。
しかし実際の運用では、「セカンダリーDNSへ反映されない」「SOAシリアルが更新されない」といったトラブルが頻繁に発生します。
これらの多くはゾーン転送設定の問題です。
本記事ではAXFR・IXFRの仕組みから、ゾーン転送失敗時の確認ポイントまで実務目線で解説します。
ゾーン転送とは
ゾーン転送とは、プライマリDNSからセカンダリーDNSへゾーン情報をコピーする仕組みです。
DNSサーバの冗長化に欠かせません。
Primary DNS
↓
Zone Transfer
↓
Secondary DNS
この仕組みによって複数のDNSサーバが同じ情報を保持できます。
なぜ必要なのか
DNSサーバが1台だけの場合です。
DNS停止
↓
名前解決不可
セカンダリーDNSが存在すればサービス継続が可能です。
AXFRとは
AXFR（Full Zone Transfer）はゾーン全体を転送する方式です。
example.com
↓
全レコード転送
初回同期時に利用されます。
IXFRとは
IXFR（Incremental Zone Transfer）は差分転送です。
変更箇所のみ転送
ネットワーク負荷を削減できます。
ゾーン転送の流れ
一般的な処理です。
Primary DNS
↓
SOA確認
↓
シリアル比較
↓
転送開始
↓
同期完了
シリアル番号が重要な役割を持っています。
SOAシリアル番号とは
ゾーン更新番号です。
2026060901
変更時には増加させる必要があります。
最も多い原因① シリアル番号更新忘れ
実務で最も多いトラブルです。
ゾーンを変更します。
www IN A 192.168.60.20
↓
www IN A 192.168.60.50
しかしSOAシリアルを変更していません。
セカンダリーDNSは更新を認識できません。
確認方法
$ dig @ns1.example.com SOA example.com
$ dig @ns2.example.com SOA example.comシリアル番号を比較します。
最も多い原因② allow-transfer未設定
BINDでは明示的に許可する必要があります。
allow-transfer {
192.168.60.11;
};設定が無い場合は転送拒否されます。
ログ例
transfer denied
典型的なエラーです。
最も多い原因③ IPアドレス誤り
allow-transferに誤ったIPを登録しています。
allow-transfer {
192.168.60.12;
};実際のセカンダリーDNSは別IPです。
最も多い原因④ ファイアウォール
TCP53が閉じている場合です。
DNS問い合わせはUDP53が有名ですが、ゾーン転送はTCP53を利用します。
確認方法
$ firewall-cmd --list-servicesDNS通信が許可されているか確認します。
TCP53確認
$ ss -ltn | grep :53TCP53待受を確認します。
最も多い原因⑤ セカンダリー設定ミス
slave設定を確認します。
zone "example.com" {
type slave;
masters {
192.168.60.10;
};
file "slaves/example.com.zone";
};masters指定が正しいか確認します。
最も多い原因⑥ notify未送信
BINDは通常NOTIFYを送信します。
Primary DNS
↓
NOTIFY
↓
Secondary DNS
これが失敗すると反映が遅れます。
手動通知
rndc notify example.com即座に通知できます。
最も多い原因⑦ DNSサーバ停止
セカンダリーDNS自体が停止している場合です。
systemctl status named双方確認します。
最も多い原因⑧ SELinux制限
Rocky Linuxでは発生することがあります。
確認します。
$ getenforce
監査ログも確認します。
$ ausearch -m avcゾーン転送テスト
手動で確認できます。
$ dig @192.168.60.10 example.com AXFR正常ならゾーン全体が表示されます。
正常な結果
example.com. SOA ...
example.com. NS ...
www A ...
mail A ...
全レコードが表示されます。
拒否された場合
Transfer failed.
allow-transferや通信設定を確認します。
ログ確認方法
プライマリDNSです。
# journalctl -u named転送要求を確認できます。
転送成功ログ例
transfer of 'example.com/IN':
AXFR ended
正常に完了しています。
転送失敗ログ例
transfer of 'example.com/IN':
failed
原因調査が必要です。
実務でよくある障害事例
Webサーバ移行時です。
Primary DNS
↓
新IP
Secondary DNS
↓
旧IP
利用者によって接続先が変わります。
シリアル比較が重要
障害調査時は必ず確認します。
dig SOA
最初に見るべき項目です。
実務での確認手順
SOA確認
↓
シリアル比較
↓
allow-transfer確認
↓
TCP53確認
↓
AXFRテスト
↓
ログ確認
この順番で調査すると効率的です。
実務でよくある原因ランキング
- シリアル番号更新忘れ
- allow-transfer未設定
- ファイアウォール設定ミス
- masters設定ミス
- NOTIFY未送信
- DNSサーバ停止
- SELinux制限
実務で覚えておきたいポイント
- ゾーン転送はDNS冗長化の基本
- AXFRは全転送
- IXFRは差分転送
- SOAシリアルが最重要
- ゾーン転送はTCP53を利用する
- dig AXFRで確認できる
まとめ
ゾーン転送はプライマリDNSとセカンダリーDNSを同期する重要な仕組みです。
しかし、シリアル番号更新忘れやallow-transfer設定ミスなどにより同期が失敗することがあります。
障害調査ではSOAシリアル比較、AXFRテスト、ログ確認を行うことで原因を特定しやすくなります。
DNS運用では「セカンダリーDNSが本当に最新情報を持っているか」を定期的に確認することが重要です。
