「名前解決できない」の原因を体系的に調査する方法｜DNS障害を効率よく切り分ける手順
KoAN
目次
「名前解決できない」の原因を体系的に調査する方法
ネットワークやサーバ運用の現場では、「名前解決できない」という問い合わせが頻繁に発生します。
しかし、実際にはDNSそのものが原因とは限りません。
ネットワーク障害、ルーティング異常、ファイアウォール設定、DNSサーバ停止、ゾーン設定ミスなど、原因は多岐にわたります。
そのため重要なのは、経験や勘で調査するのではなく、順序立てて切り分けることです。
本記事では実務で利用できる「名前解決できない」問題の体系的な調査方法を解説します。
名前解決とは何か
名前解決とは、ホスト名やドメイン名をIPアドレスへ変換する処理です。
www.example.com
↓
192.168.60.20
この変換に失敗すると、多くのサービスが利用できなくなります。
まず確認すべきこと
利用者から「サイトへ接続できない」と言われた場合、本当にDNSが原因なのか確認します。
実際には次のようなケースもあります。
- Webサーバ停止
- ネットワーク断
- VPN未接続
- ファイアウォール遮断
- ルーティング異常
最初からDNSと決めつけないことが重要です。
症状を整理する
最初に影響範囲を確認します。
- 特定PCのみ発生
- 部署全体で発生
- 社内全体で発生
- 特定サイトのみ発生
- すべてのサイトで発生
影響範囲によって調査箇所が変わります。
IPアドレスで接続してみる
DNS障害かどうかを確認する最も簡単な方法です。
ping 192.168.60.20
またはブラウザで直接アクセスします。
http://192.168.60.20
接続できる場合、DNS障害の可能性が高くなります。
ネットワーク疎通確認
まずネットワーク自体が正常か確認します。
ping 8.8.8.8
応答が無ければDNS以前の問題です。
デフォルトゲートウェイ確認
Linuxの場合です。
ip route
Windowsの場合です。
route print
正しいデフォルトゲートウェイが設定されているか確認します。
DNSサーバ設定確認
Linuxの場合です。
cat /etc/resolv.conf
例です。
nameserver 192.168.60.10
DNSサーバ設定が正しいか確認します。
NetworkManager環境の場合
Rocky Linuxでは次も確認できます。
nmcli device show
現在利用中のDNSサーバを確認できます。
Windowsの場合
ipconfig /all
DNSサーバ設定を確認します。
nslookupによる確認
まずは簡単に確認します。
nslookup www.example.com
応答が返るか確認します。
digによる詳細確認
Linux管理者はこちらを利用することが多いです。
dig www.example.com
応答内容を詳細に確認できます。
DNSサーバを直接指定する
ローカル設定を無視して確認します。
dig @192.168.60.10 www.example.com
DNSサーバ自体が正常か確認できます。
応答が無い場合
次のような結果になります。
connection timed out
DNSサーバ停止や通信障害を疑います。
DNSサーバの稼働確認
BINDの場合です。
$ systemctl status named
正常な例です。
active (running)53番ポート確認
DNSサーバ側で確認します。
$ ss -ltnup | grep :53
TCP53とUDP53が待受していることを確認します。ファイアウォール確認
Rocky Linuxでは次を確認します。
$ firewall-cmd --list-services
dnsが含まれているか確認します。ログ確認
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サーバ内部エラーです。
ゾーン設定やDNSSEC関連の問題が考えられます。
REFUSEDの場合
status: REFUSED
問い合わせ拒否です。
allow-query設定を確認します。
権威DNSへ直接問い合わせる
キャッシュの影響を排除します。
$ dig @ns1.example.com www.example.com
権威DNSの情報を直接確認できます。TTLによる影響を確認する
DNS変更直後はTTLの影響を受けます。
www.example.com. 3600 IN A 192.168.60.20
3600秒間は古い情報が残る場合があります。
クライアントキャッシュ確認
Windowsの場合です。
ipconfig /displaydns
DNSキャッシュを確認できます。
キャッシュ削除
Windowsの場合です。
ipconfig /flushdns
LinuxのBINDキャッシュDNSの場合です。
rndc flush
セカンダリーDNS確認
複数DNS構成では同期状態を確認します。
$ dig @ns1.example.com SOA example.com
$ dig @ns2.example.com SOA example.com
シリアル番号を比較しますシリアル番号不一致
ns1
2026060902
ns2
2026060901
ゾーン転送失敗の可能性があります。
問い合わせログ確認
問い合わせ状況を確認します。
# rndc querylog
その後ログを確認します。
#journalctl -u named -f実務でよくある原因ランキング
- ゾーンファイル記述ミス
- TTLによるキャッシュ残存
- シリアル番号更新忘れ
- allow-query設定ミス
- ファイアウォール設定忘れ
- DNSサーバ停止
- ネットワーク障害
- クライアント側DNS設定ミス
実務で使う切り分けフローチャート
IPで接続できる？
↓
YES
↓
DNS疑い
↓
resolv.conf確認
↓
dig確認
↓
DNSサーバ指定確認
↓
named確認
↓
ログ確認
↓
ゾーン確認
↓
TTL確認
この順番で確認すると効率的です。
実務で覚えておきたいポイント
- まずIPアドレスで接続確認する
- DNSとネットワークを切り分ける
- digで直接問い合わせる
- named-checkconfを活用する
- TTLの影響を考慮する
- シリアル番号を確認する
まとめ
「名前解決できない」というトラブルは、必ずしもDNSサーバそのものが原因とは限りません。
ネットワーク、DNS設定、キャッシュ、ゾーンファイル、ファイアウォールなど、複数の要因が関係します。
そのため、IPアドレスでの接続確認から始め、digやログ確認を組み合わせながら体系的に調査することが重要です。
実務では切り分け手順を定型化しておくことで、障害対応時間を大幅に短縮できます。
