DNSログの確認方法とトラブルシューティング

DNSサーバを運用していると、「名前解決できない」「ゾーン転送が失敗する」「セカンダリーDNSへ反映されない」など、さまざまなトラブルに遭遇します。

このような問題を解決するために最も重要なのがログの確認です。

DNSサーバは多くの場合、障害の原因をログへ記録しています。

そのため、ログを正しく確認できるかどうかでトラブル対応速度が大きく変わります。

本記事ではRocky LinuxのBINDを例に、ログの確認方法や実務でよくあるDNSトラブルの調査手順について解説します。

なぜDNSログが重要なのか

DNSトラブルの多くは設定ミスや通信障害によって発生します。

しかし利用者からは単純に「名前解決できない」としか見えません。

そのため管理者はログから原因を特定する必要があります。

例えば次のような問題があります。

• named.confの構文エラー
• ゾーンファイルの記述ミス
• ゾーン転送失敗
• 権限設定ミス
• DNS問い合わせ異常

これらはログを確認することで原因を把握できます。

BINDのログ出力先

Rocky Linux 9ではsystemd管理が標準です。

そのためBINDのログは主にjournalへ出力されます。

systemd-journald
↓
journalctl

まずはjournalctlを使いこなすことが重要です。

サービスログ確認

最も基本となるコマンドです。

# journalctl -u named

namedサービスのログのみ表示します。

最新ログ確認

最新のログだけ確認する場合です。

# journalctl -u named -n 50

直近50行だけ表示されます。

リアルタイム監視

ログをリアルタイム監視する場合です。

# journalctl -u named -f

障害調査時によく利用します。

サービス状態確認

まず最初に確認するべき項目です。

# systemctl status named

正常なら次のように表示されます。
active (running)

起動失敗時の確認

起動失敗時は以下を確認します。

# journalctl -xeu named

詳細なエラー内容を表示できます。

named.confの構文エラー

最も多いトラブルです。

例です。

allow-query { any }

セミコロンがありません。

ログには次のようなエラーが表示されます。

missing ';' before '}'

設定確認コマンド

起動前に確認できます。

# named-checkconf

正常なら何も表示されません。

ゾーンファイルエラー

ゾーンファイルの記述ミスも頻発します。

例です。

www IN A

IPアドレスがありません。

ログにはエラーが表示されます。

ゾーン確認コマンド

# named-checkzone example.com  /var/named/example.com.zone

構文エラーを事前確認できます。

末尾ドット忘れ

BIND初心者が最も遭遇するミスです。

ns1.example.com

ではなく

ns1.example.com.

です。

ゾーンロード失敗

ログ例です。

zone example.com/IN:
not loaded due to errors

ゾーンファイルに問題があります。

問い合わせログを確認する

通常BINDは問い合わせログを出力しません。

一時的に有効化します。

# rndc querylog

もう一度実行すると無効になります。

問い合わせログの例

client 192.168.60.100:
query: www.example.com IN A

誰が何を問い合わせたか確認できます。

ゾーン転送エラー

セカンダリーDNS構築時によく発生します。

ログ例です。

transfer denied

allow-transfer設定を確認します。

allow-transfer確認

allow-transfer {
    192.168.60.11;
};

セカンダリーDNSのIPアドレスが正しいか確認します。

シリアル番号更新漏れ

セカンダリーDNSへ反映されない場合です。

SOAレコードを確認します。

2026060901

変更後は増加させる必要があります。

2026060902

ポート確認

DNSサービスが待受しているか確認します。

# ss -ltnup | grep :53

UDP53とTCP53が表示されることを確認します。

ファイアウォール確認

外部から問い合わせできない場合です。

# firewall-cmd --list-services

dnsが含まれているか確認します。

SELinux確認

起動できない場合に確認します。
# getenforce

Enforcingの場合は監査ログも確認します。
# ausearch -m avc

digによる動作確認

最も重要な確認方法です。

# dig @127.0.0.1 www.example.com

ローカル動作を確認できます。

外部からの確認

$ dig @192.168.60.10 www.example.com

ネットワーク経由の動作を確認します。

NXDOMAINエラー

存在しないレコードです。

status: NXDOMAIN

ホスト名やゾーン設定を確認します。

SERVFAILエラー

DNSサーバ内部エラーです。

status: SERVFAIL

ログ確認が必要です。

REFUSEDエラー

アクセス拒否です。

status: REFUSED

allow-query設定を確認します。

実務でよくあるトラブル順位

1. ゾーンファイル記述ミス
2. シリアル番号更新忘れ
3. allow-transfer設定ミス
4. ファイアウォール設定忘れ
5. SELinux制限
6. 末尾ドット忘れ

まずはこれらを疑うのが近道です。

障害調査の基本手順

サービス確認
↓
ログ確認
↓
named-checkconf
↓
named-checkzone
↓
dig確認
↓
ネットワーク確認

この順番で調査すると効率的です。

実務で覚えておきたいポイント

• まずjournalctlを見る
• named-checkconfを活用する
• named-checkzoneを活用する
• digで動作確認する
• 問い合わせログはrndc querylogで確認する
• シリアル番号更新忘れに注意する

まとめ

DNSトラブルの多くはログを確認することで原因を特定できます。

Rocky Linuxではjournalctlが基本となり、BINDではnamed-checkconfやnamed-checkzoneが非常に重要な確認ツールになります。

また、問い合わせ確認にはdig、ログ取得にはrndc querylogが役立ちます。

DNS障害対応では、やみくもに設定を変更するのではなく、ログを確認しながら原因を切り分けることが重要です。

関連記事:

権威DNSサーバとは？ゾーン情報を管理するDNSの中核を理解する DNSゾーンとは？ゾーンファイルとドメイン管理の仕組みを理解する DNSの歴史とは？HOSTS.TXTからBIND誕生までの進化を理解する named.confの読み方と設定例｜BIND設定ファイルの基本構造を理解する