【実例で学ぶ】DNS関連トラブル集：BIND/namedでよくあるミスと解決策

DNSサーバーの運用は、一見シンプルに見えて落とし穴が多い領域です。ゾーンファイルの構文ミス、権威サーバー間の同期不良、chroot環境でのパス問題など、経験者でも躓くポイントが多数存在します。

本記事では、実際に発生したDNS関連トラブルを7つのケースとしてまとめました。症状・原因・解決策を具体的に解説しているので、同様の問題が発生した際のトラブルシューティングガイドとしてご活用ください。

この記事で扱うトラブル

AレコードにドメインをにIPアドレスではなくドメイン名を指定
ゾーンファイル変更が反映されない
権威サーバー間でゾーン同期が不完全
ゾーンファイルが見つからない（chroot環境）
named-checkzoneコマンドの誤用
namedが起動しているがクエリに応答しない
権威サーバーに到達できない

1. AレコードにIPアドレスではなくドメイン名を指定

症状

namedの再起動時にサービスが停止する

原因

ゾーンファイルで以下のような誤った設定をしていた：

www.example.jp. IN A example.jp.

AレコードにはIPアドレスを指定する必要があるが、別のドメイン名を指定していたためBINDが構文エラーで停止。

解決策

1. AレコードにはIPアドレスを直接指定する

www.example.jp. IN A 192.0.2.1

2. 別のドメイン名を指すにはCNAMEレコードを使用する

www.example.jp. IN CNAME example.jp.

2. ゾーンファイル変更が反映されない

症状

ゾーンファイルを編集したがdigで確認するとNXDOMAIN

原因

ゾーンファイル編集後にnamedへの再読み込みを行っていなかった
SOAレコードのシリアル番号が増加していなかった

解決策

1. rndc reload でゾーンを再読み込み

rndc reload example.jp

2. 解決しない場合はnamedを再起動

systemctl restart named

3. シリアル番号を必ず増加させてから再読み込み

SOAレコードのシリアル番号（通常は YYYYMMDDNN 形式）を更新しないと、セカンダリサーバーがゾーン転送を行わない場合があります。

3. 権威サーバー間でゾーン同期が不完全

症状

約50%の確率でDNS解決に失敗する

原因

複数の権威サーバーのうち、一部（ns1.example.jp）がREFUSEDを返していた
ゾーン転送が正しく行われておらず、データが同期されていなかった
TTLが1秒と極端に短く設定されていた

解決策

全権威サーバーでゾーンファイルが存在し正しく設定されているか確認
ゾーン転送の設定（allow-transfer）を確認
TTLは最低300秒（通常は3600秒程度）に設定

# 各権威サーバーの応答を確認
dig @ns1.example.jp example.jp SOA
dig @ns2.example.jp example.jp SOA

4. ゾーンファイルが見つからない（chroot環境）

症状

named-chrootが起動失敗

エラーメッセージ

zone example.jp/IN: loading from master file example.jp failed: file not found

原因

chroot環境ではファイルパスが /var/named/chroot/ 配下になるが、ゾーンファイルが通常のパスに配置されていた。

解決策

chroot環境の場合、ゾーンファイルは /var/named/chroot/var/named/ に配置
不要なゾーン定義はnamed.confから削除

# chroot環境でのファイル配置確認
ls -la /var/named/chroot/var/named/

5. named-checkzoneコマンドの誤用

症状

“ignoring out-of-zone data” エラーが大量に表示される

原因

コマンドの引数を間違えていた：

# 誤り（引数の順序が逆）
named-checkzone test.example.com example.com

解決策

正しい構文は「ゾーン名ファイルパス」の順：

# 正しい使い方
named-checkzone example.com /var/named/example.com.zone

6. namedが起動しているがクエリに応答しない

症状

nslookup/digでタイムアウト

確認すべきポイント

1. named-chrootサービスのステータス確認

systemctl status named-chroot

2. ファイアウォールでUDP/TCP 53番ポートが開いているか

firewall-cmd --list-all
# または
firewall-cmd --add-service=dns --permanent
firewall-cmd --reload

3. named.confでlisten-onが正しく設定されているか

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    ...
};

4. ログファイルにエラーがないか

journalctl -u named-chroot -f
# または
tail -f /var/log/messages | grep named

7. 権威サーバーに到達できない

症状

SERVFAIL / No Reachable Authority

エラーメッセージ

EDE: 22 (No Reachable Authority)

確認すべきポイント

権威サーバーのDNSサービスが起動しているか
レジストラに登録されているNSレコードのIPアドレスが正しいか
権威サーバーへのネットワーク到達性

# ポート疎通確認
nc -zv ns1.example.jp 53

# 権威サーバーへ直接クエリ
dig @ns1.example.jp example.jp SOA

対象ドメインのゾーン定義が権威サーバーに存在するか

トラブルシューティング早見表

症状	よくある原因	確認コマンド
named起動失敗	ゾーンファイル構文エラー	`named-checkconf`
NXDOMAIN	レコード未登録・未反映	`rndc reload ゾーン名`
SERVFAIL	サーバー設定エラー	`journalctl -u named`
タイムアウト	ファイアウォール/サービス停止	`nc -zv server 53`
一部のみ失敗	権威サーバー間同期不良	`dig @各NS ゾーン SOA`

予防策：トラブルを未然に防ぐために

1. 変更前に構文チェック

# named.confの構文チェック
named-checkconf

# ゾーンファイルの構文チェック
named-checkzone example.jp /var/named/example.jp.zone

2. シリアル番号の管理

SOAレコードのシリアル番号は YYYYMMDDNN 形式（例: 2026011101）で管理し、変更のたびに必ず増加させる。

3. TTLの適切な設定

通常運用: 3600〜86400秒
変更予定がある場合: 事前に300秒程度に下げておく
1秒などの極端に短いTTLは避ける

4. 監視の設定

# 定期的なDNS応答確認
dig +short example.jp @ns1.example.jp

まとめ

DNS関連のトラブルは、原因が特定できれば解決は比較的容易です。重要なのは、症状から原因を素早く絞り込むこと。この記事で紹介した7つのケースと早見表を参考に、効率的なトラブルシューティングを行ってください。

特に named-checkconf と named-checkzone による事前チェックは習慣化することをお勧めします。構文エラーの多くは、これらのコマンドで未然に防げます。