DNSが引けない時の切り分け手順｜名前解決トラブルを効率よく調査する方法
KoAN
目次
DNSが引けない時の切り分け手順
DNSはネットワークやインターネットを利用する上で欠かせない仕組みです。
しかし実際の運用現場では、「Webサイトへ接続できない」「メールが送信できない」「名前解決ができない」といったトラブルが頻繁に発生します。
DNS障害は原因が多岐にわたるため、やみくもに設定を変更するとかえって問題を複雑化させてしまいます。
重要なのは体系的な切り分けです。
本記事では、実務で利用できるDNSトラブルの切り分け手順を順番に解説します。
まず確認するべきこと
DNSが原因と思い込まないことが重要です。
実際には次のようなケースもあります。
- ネットワーク断
- ルーティング障害
- Webサーバ停止
- ファイアウォール設定ミス
- DNS設定ミス
まずは本当にDNSが原因なのか確認します。
症状を整理する
最初に症状を整理します。
例えば次のような状況があります。
- 特定サイトだけ接続できない
- 全サイト接続できない
- 一部PCだけ発生する
- 全利用者で発生する
影響範囲を把握することで原因候補を絞り込めます。
IPアドレスで接続できるか確認する
DNSかどうかを判断する最も簡単な方法です。
例えば対象サーバのIPアドレスが分かっている場合です。
ping 192.168.60.20
またはブラウザで直接アクセスします。
http://192.168.60.20接続できる場合はDNS障害の可能性が高くなります。
ネットワーク疎通確認
まずネットワークが正常か確認します。
ping 8.8.8.8応答が無い場合はDNS以前の問題です。
ネットワーク障害を疑います。
デフォルトゲートウェイ確認
Linuxの場合です。
ip routeデフォルトルートが存在するか確認します。
DNSサーバ設定確認
Linuxでは次を確認します。
cat /etc/resolv.conf
例です。
nameserver 192.168.60.10設定ミスが無いか確認します。
複数DNS設定確認
複数指定されている場合もあります。
nameserver 192.168.60.10
nameserver 8.8.8.8どちらが応答しているか確認が必要です。
digで確認する
まず最も基本的な確認です。
dig www.example.com正常ならANSWER SECTIONが表示されます。
DNSサーバを指定して確認する
指定されたDNSサーバへ直接問い合わせます。
dig @192.168.60.10 www.example.com応答があるか確認します。
タイムアウトの場合
次のような表示になります。
connection timed outDNSサーバへ到達できない可能性があります。
53番ポート確認
DNSサーバ側で確認します。
$ ss -ltnup | grep :53UDP53およびTCP53で待受しているか確認します。
namedサービス確認
BINDの場合です。
$ systemctl status named
正常なら以下になります。
active (running)ログ確認
BINDログを確認します。
$ journalctl -u namedエラーが出ていないか確認します。
設定ファイル確認
named.confの構文確認です。
$ named-checkconf正常なら何も表示されません。
ゾーンファイル確認
$ named-checkzone example.com /var/named/example.com.zoneゾーンファイルの記述ミスを確認できます。
NXDOMAINの場合
dig結果に次が表示される場合です。
status: NXDOMAIN対象レコードが存在しません。
ホスト名の誤りを確認します。
SERVFAILの場合
内部エラーです。
status: SERVFAILゾーン設定やDNSサーバ内部エラーが考えられます。
REFUSEDの場合
問い合わせが拒否されています。
status: REFUSEDallow-query設定を確認します。
権威DNSへ直接問い合わせる
キャッシュの影響を排除します。
dig @ns1.example.com www.example.com権威DNSが正常か確認できます。
キャッシュDNSとの比較
比較確認します。
$ dig @8.8.8.8 www.example.com
$ dig @1.1.1.1 www.example.com結果が異なる場合があります。
DNS変更直後の確認
変更したばかりの場合はTTLを疑います。
www.example.com. 3600 IN A 192.168.60.203600秒間は古い情報が残る可能性があります。
セカンダリーDNS確認
権威DNSが複数ある場合です。
$ dig @ns1.example.com SOA example.com
$ dig @ns2.example.com SOA example.comシリアル番号を比較します。
シリアル番号不一致
例です。
ns1
2026060902
ns2
2026060901
ゾーン転送が失敗している可能性があります。
ファイアウォール確認
DNSサーバ側で確認します。
$ firewall-cmd --list-servicesdnsが含まれているか確認します。
SELinux確認
BIND起動失敗時に確認します。
$ getenforce
Enforcingの場合は監査ログも確認します。
$ausearch -m avcクライアントキャッシュ確認
クライアント側に古い情報が残る場合があります。
Windowsの場合です。
ipconfig /flushdns
DNSキャッシュを削除します。
BINDキャッシュ削除
キャッシュDNSの場合です。
# rndc flushキャッシュを削除できます。
実務でよくある原因
- ゾーンファイル記述ミス
- named.conf設定ミス
- シリアル番号更新忘れ
- ファイアウォール設定忘れ
- TTLによる反映遅延
- allow-query設定ミス
- セカンダリーDNS未同期
切り分けの流れ
IPで接続確認
↓
ネットワーク確認
↓
resolv.conf確認
↓
dig実行
↓
DNSサーバ指定確認
↓
named確認
↓
ログ確認
↓
ゾーン確認
この順番で確認すると効率よく原因を特定できます。
実務で覚えておきたいポイント
- まずIPアドレスで接続確認する
- digを利用して切り分ける
- named-checkconfを活用する
- named-checkzoneを活用する
- TTLの影響を考慮する
- シリアル番号を確認する
まとめ
DNSトラブルは原因が多岐にわたるため、体系的な切り分けが重要です。
まずはネットワークとDNSを切り分け、その後digやnamed-checkconf、named-checkzoneを利用して問題箇所を特定します。
また、TTLやキャッシュ、セカンダリーDNSの同期状態なども考慮する必要があります。
DNS障害対応では、順序立てて確認する習慣を身につけることが迅速な復旧につながります。
