この記事で分かること
「サイトが開かない」「接続が妙に遅い」──こうした症状が起きたとき、原因がDNSにあるのか、それとも回線やルーティングの問題なのかを素早く切り分けることが現場では最重要です。この記事では、DNS名前解決が遅い・失敗する場面を想定し、nslookup・dig・tracertという3つのコマンドを使った確認フローを具体的に解説します。コマンドの実行例と「どこを見るべきか」をセットで説明するため、初めてDNS問題の切り分けに取り組む方から、現場で手早く原因を特定したいネットワーク担当者まで役立つ内容です。
なお本記事では、DNSの仕組みそのもの（再帰問い合わせ・権威サーバーの役割・レコード種別の違いなど）も必要に応じて補足しながら解説します。コマンド出力の読み方を理解するうえで、背景知識があると格段にスムーズだからです。
前提知識：DNS名前解決の仕組みをざっくり理解する
DNS名前解決フロー別の遅延ポイント
※参考データ（イメージ）
トラブルシューティングに入る前に、名前解決がどのような流れで行われるかを把握しておくことが重要です。仕組みを知ることで、「どこで何が詰まっているか」をコマンド出力から読み取れるようになります。
- クライアントのOSがまずローカルキャッシュを確認する（Windowsであれば%SystemRoot%\System32\drivers\etc\hostsも参照）
- キャッシュになければスタブリゾルバーがフルサービスリゾルバー（フォワーダーまたはキャッシュDNSサーバー）に問い合わせる（社内環境では社内DNSサーバー、家庭環境ではルーター内蔵DNSまたはISP提供DNSが該当）
- フルサービスリゾルバーはキャッシュになければルートDNSサーバー→TLDサーバー（.comなど）→権威DNSサーバーの順に再帰問い合わせを行う
- 権威DNSサーバーが正式なAレコード（またはAAAAレコード）を返す
- クライアントはIPアドレスを受け取り、TCP接続を開始する
この流れのどこかで詰まると「名前解決が遅い・失敗する」症状が出ます。nslookupやdigはこの流れの各ポイントを手動で確認するツールです。
DNS名前解決が遅い・失敗するときに疑うべき原因の全体像
DNS名前解決トラブルの原因別発生頻度
※参考データ（イメージ）
名前解決のトラブルシューティングに入る前に、原因候補を整理しておくと効率よく動けます。「DNSが悪い」と決めつけて設定を変えてしまうと、本当の原因が回線側にあった場合に時間を無駄にします。
| 症状 | 疑われる原因 | 最初に使うコマンド |
|---|---|---|
| URLを叩くと数秒待ってからエラー | DNSサーバーへの到達不可またはタイムアウト（デフォルトは5秒待って再試行） | nslookup / dig |
| IPアドレス直打ちだと繋がる | DNSの応答失敗・ホスト名解決の問題（回線は生きている） | nslookup / dig |
| 特定のドメインだけ遅い | 上位権威DNSの遅延、レコードTTL切れによる再帰問い合わせの発生 | dig +stats / dig +trace |
| 社内のみ名前解決できない | 内部DNSサーバーの障害・スプリットDNS設定ミス・フォワーダー設定漏れ | nslookup（サーバー指定） |
| pingやtracertも遅い・失敗 | 回線問題・ルーティング異常・デフォルトゲートウェイ障害 | tracert / ping |
| NXDOMAIN（ドメインが存在しないエラー）が返る | DNSレコードの削除・ドメイン失効・タイポ・権威DNSへの委譲ミス | dig +trace |
| SERVFAIL が返る | 権威DNSが応答しない・DNSSEC検証失敗・フォワーダーが上流と通信できない | dig +dnssec / dig @権威NS |
この表を頭に入れてから以下の確認フローを実施すると、無駄な手戻りを防げます。
ステップ1：まずIPアドレス直打ちで切り分ける
名前解決 トラブルシューティングの第一歩は、DNSを完全にバイパスすることです。アクセスしたいサイトのIPアドレスが分かる場合は、ブラウザのアドレスバーにIPアドレスを直接入力してみてください。HTTPSサイトの場合はSNI（Server Name Indication）の関係で証明書エラーが出ることがありますが、「接続できるかどうか」の判断には十分使えます。
- IPアドレス直打ちで繋がる：DNS問題が濃厚。回線自体は生きている
- IPアドレス直打ちでも繋がらない：回線問題・ルーティング問題の可能性が高い
IPアドレスを調べる方法としては、別のネットワーク環境（スマートフォンのキャリア回線など）からnslookup ドメイン名 8.8.8.8を実行するか、DNSCheckerなどのWebサービスを利用するのが手軽です。
ここでDNS問題であることが分かれば、次はnslookupやdigでDNSサーバーへの疎通確認に進みます。逆にIPアドレスでも繋がらない場合は、後述のtracertで経路を確認するフローに飛んでください。
ステップ2：nslookupでDNS確認をする具体的な手順
nslookupはWindows・macOS・Linuxいずれでも使える基本コマンドです。nslookup DNS確認の基本として、まずデフォルトのDNSサーバーで問い合わせ、次に別のDNSサーバーを指定して結果を比較します。
基本的なnslookupの使い方
nslookup google.com実行すると以下のような出力が返ります。
Server: dns.example.local
Address: 192.168.1.1
Non-authoritative answer:
Name: google.com
Addresses: 142.250.196.142
2404:6800:4004:820::200eどこを見るべきか：
・「Server:」と「Address:」が問い合わせ先DNSサーバーのホスト名とIPアドレス。ここが意図したDNSサーバーでなければ、OS側のDNS設定を確認してください（Windowsなら「ネットワークアダプターの設定」、Linuxなら/etc/resolv.conf）。
・「Addresses:」にIPアドレスが返れば名前解決は成功。IPv6アドレス（2404:…のような形式）が混在する場合はAAAAレコードも返っています。
・「Request to … timed out」が表示される場合は、そのDNSサーバーへの到達自体に問題があります。
・「Non-authoritative answer:」の表示はキャッシュDNSサーバーが答えていることを意味し、正常な動作です。
特定のDNSサーバーを指定して問い合わせる
nslookup google.com 8.8.8.8どこを見るべきか：
デフォルトのDNSサーバーでは失敗するのに、8.8.8.8（Google Public DNS）では成功する場合は、自社・自宅のDNSサーバー自体に問題がある可能性が高いです。逆にどちらでも失敗する場合は、DNS以前のネットワーク疎通問題が疑われます。
主要なパブリックDNSサーバー一覧
| サービス名 | プライマリDNS | セカンダリDNS | 特徴 |
|---|---|---|---|
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | 世界規模のAnycastで低レイテンシ。DNSSEC対応 |
| Cloudflare DNS | 1.1.1.1 | 1.0.0.1 | 高速性・プライバシー重視。ログを最小化。DNSSEC対応 |
| OpenDNS (Cisco) | 208.67.222.222 | 208.67.220.220 | フィッシングブロック機能あり。企業向け拡張あり |
| IIJmio DNS（国内） | 103.2.57.5 | 103.2.57.6 | 国内アクセスが多い環境向け。日本のIXに近い |
逆引き（IPアドレスからホスト名解決）
nslookup 8.8.8.8IPアドレスを入力することで逆引き（PTRレコード検索）が行えます。「dns.google」などのホスト名が返ればPTRレコードが正しく設定されています。逆引きが失敗してもブラウジングには直接影響しないケースが多いですが、メールサーバーの送信元確認（FCrDNS検証）やセキュリティ機器がPTRを使う場合は重要な確認ポイントです。
ステップ3：digコマンドで詳細な応答時間と経路を確認する
Linux・macOS環境ではdigコマンドの方がnslookupより詳細な情報を得られます。Windows環境では標準搭載されていませんが、BIND for WindowsをインストールするかWSL（Windows Subsystem for Linux）を使えば利用可能です。dig コマンド 使い方の基本と、DNS名前解決が遅い・失敗する原因を特定するための応用例を紹介します。
基本的なdigの使い方と出力の読み方
dig google.com実行すると以下のような出力が返ります（抜粋）。
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
google.com. 21 IN A 142.250.196.142
;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jan 15 10:23:45 JST 2025
;; MSG SIZE rcvd: 55各フィールドの読み方：
・status: NOERROR：名前解決成功。NXDOMAIN（ドメイン未存在）・SERVFAIL（サーバー障害）・REFUSED（問い合わせ拒否）が出た場合は問題あり。
・flags: qr rd ra：qr=応答パケット、rd=再帰要求フラグ、ra=再帰利用可能フラグ。raがないDNSサーバーに向けると再帰問い合わせが使えません。
・ANSWER SECTION の TTL：「21」の部分がTTL（秒）。この値が0または非常に小さいと毎回権威サーバーへ問い合わせが発生します。
・Query time: 12 msec：応答時間。通常は数ms〜数十ms程度。100ms以上は要注意。
・SERVER: 192.168.1.1#53：実際に問い合わせたDNSサーバーとポート番号（標準は53番）。
特定のDNSサーバーを指定する
dig @8.8.8.8 google.com
dig @1.1.1.1 google.com
dig @192.168.1.1 google.com「@」の後にDNSサーバーのIPアドレスを指定します。自社DNSと外部DNS（8.8.8.8や1.1.1.1）でQuery timeを比較することで、自社DNSサーバーの処理遅延なのか、外部への回線問題なのかを切り分けられます。
権威DNSサーバーへの経路をトレースする（+trace）
dig +trace google.com+traceオプションを付けると、ルートDNSサーバーから権威DNSサーバーまでの委譲経路を追いながら問い合わせを行います。「特定のドメインだけ遅い」「NXDOMAIN が返る」場合に、どの委譲ポイントで問題が起きているかを特定できます。出力は長くなりますが、各ステップのQuery timeを比較することで遅延箇所を特定できます。
応答の詳細統計を確認する（+stats）
dig +stats google.com複数回実行してQuery timeが大きくばらつく場合（例：1回目8ms→2回目350ms→3回目12ms）は、DNSサーバーの負荷問題かネットワークの不安定さが原因の可能性があります。
TTLを確認してキャッシュの状態を把握する
dig google.com A
dig google.com AAAA
dig google.com MX
dig google.com TXTレコードタイプを指定することで、Aレコード（IPv4）・AAAAレコード（IPv6）・MXレコード（メール）・TXTレコード（SPF/DKIMなど）を個別に確認できます。ANSWER SECTIONのTTL値が0または数秒以下の場合は、DNSレコードの設定を見直す必要があります。一般的なWebサービスではTTLを300〜3600秒程度に設定することが多いです。
DNSSEC検証状態を確認する
dig +dnssec google.com ADNSSEC（DNS Security Extensions）が有効なドメインでは、応答にRRSIG（署名レコード）が付与されます。SERVFAILが出る場合、DNSSECの署名検証に失敗している可能性があります。その場合はdig +cd google.com（Check Disabledフラグを立てて検証を無効化）で問い合わせてみてください。CDフラグ付きで成功する場合はDNSSEC関連の問題が確定します。
nslookupとdigの比較
| 項目 | nslookup | dig |
|---|---|---|
| 対応OS（標準） | Windows・macOS・Linux | macOS・Linux（Windowsは追加インストールまたはWSL） |
| 応答時間の確認 | 不可 | 可（Query time表示） |
| TTL確認 | 不可 | 可 |
| 委譲経路のトレース | 不可 | 可（+traceオプション） |
| DNSSEC確認 | 限定的 | 可（+dnssec / +cdオプション） |
| スクリプト連携 | やや不向き | 向いている（+short / +noallオプションで出力を絞れる） |
| 初心者への使いやすさ | 出力がシンプルで分かりやすい | 情報量が多くやや読みにくいが詳細 |
| OSのリゾルバーキャッシュを使うか | Windowsでは使う場合あり（実装依存） | 使わない（直接DNSサーバーに問い合わせる） |
ステップ4：tracertで問題がDNSか回線かを判別する
nslookupやdigでDNSサーバーへの疎通がうまくいかない場合、tracert（Windowsではtracert、Linux/macOSではtraceroute）でネットワークの経路を確認します。tracert ネットワーク診断は、パケットがどの経路を通って目的地に届くか（または届かないか）を視覚的に確認できるため、DNS問題かルーティング問題かの判別に有効です。
仕組みとしては、TTL（Time To Live）を1から順に増やしながらICMP（またはUDP）パケットを送信し、各ルーターが「TTL超過」を返すことでホップごとの応答時間とIPアドレスを把握します。
Windowsでのtracert実行例
tracert 8.8.8.8実行すると以下のような出力が返ります。
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 2 ms 1 ms 2 ms 192.168.1.1 ← デフォルトゲートウェイ（家庭用ルーター）
2 10 ms 11 ms 10 ms 10.xxx.xxx.1 ← ISP側の集線装置
3 12 ms 13 ms 12 ms xxx.xxx.xxx.xxx ← ISPバックボーン
4 * * * Request timed out.← ICMPに応答しないルーター（必ずしも障害ではない）
5 15 ms 14 ms 15 ms 72.14.xxx.xxx ← Googleのネットワーク
6 12 ms 12 ms 12 ms dns.google [8.8.8.8]どこを見るべきか：
・ホップ1（デフォルトゲートウェイ）が「* * *」：ローカルネットワーク内の問題。ルーターの障害かPCのゲートウェイ設定ミスを疑います。
・ホップ2以降で「* * *」が連続して最終到達できない：ISP側またはその先のネットワーク問題。
・途中のホップだけ「* * *」で最終到達できる：そのルーターがICMPに応答しない設定になっているだけで障害ではありません（上記出力のホップ4がこれに該当）。
・特定のホップで応答時間が急増する（例：前のホップ12ms→急に200ms）：そのポイントでネットワーク遅延が発生しています。
DNSサーバー自体への経路確認
tracert 192.168.1.1上記は社内DNSサーバーが192.168.1.1の場合の例です。DNSサーバーのIPアドレスに対してtracertを実行し、到達できているか確認します。到達できていないのであれば、DNSサーバーへの経路そのものに問題があります。1ホップで到達できるはずのLocal DNSへ到達できない場合は、VLANやアクセスコントロールリスト（ACL）の設定確認が必要です。
Linux・macOSでのtraceroute
traceroute 8.8.8.8
# macOSでTCPを使う場合（ICMPがブロックされる環境向け）
traceroute -T -p 53 8.8.8.8LinuxのtracerouteはデフォルトでUDPを使用します。ICMPを使いたい場合はtraceroute -I 8.8.8.8と指定してください。企業ネットワークではICMPがファイアウォールでブロックされているケースも多く、その場合はTCPポート指定（-Tオプション）が有効です。
mtrコマンドによるリアルタイム経路監視（Linux）
mtr 8.8.8.8
mtr --report 8.8.8.8mtr（Matt's Traceroute）はpingとtracerouteを組み合わせたツールで、各ホップのパケットロス率・最小/平均/最大/標準偏差のレイテンシをリアルタイムで表示します。断続的な問題の調査に特に有効で、「たまに遅くなる」「稀に失敗する」という再現性の低い問題を可視化できます。
ステップ5：DNS問題と判明した場合の切り分けと対処フロー
ここまでの確認でDNS問題であることが絞り込めた場合、次に「どのDNSサーバーに問題があるのか」「設定の問題かサーバー自体の問題か」を切り分けます。
①DNSキャッシュをクリアして再確認
古いキャッシュが原因でIPアドレスが古いまま返ってくるケースがあります。特にDNSレコードを変更した直後（ドメイン移管・サーバー移転など）に多く発生します。
# Windowsの場合
ipconfig /flushdns
# macOSの場合（macOS Monterey以降）
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linuxの場合（systemd-resolved使用時）
sudo systemd-resolve --flush-caches
# Linuxの場合（nscd使用時）
sudo service nscd restartキャッシュクリア後に再度nslookupやdigで問い合わせて、名前解決が正常に行われるか確認します。解決する場合は古いキャッシュが原因だったと判断できます。ただしキャッシュクリアは根本解決ではなく、TTLの設定やDNSサーバーの状態確認を並行して行ってください。
②複数のDNSサーバーで同じ問い合わせをして比較
# Google Public DNS
nslookup example.com 8.8.8.8
# Cloudflare DNS
nslookup example.com 1.1.1.1
# 自社DNSサーバー（例）
nslookup example.com 192.168.1.1どこを見るべきか：
外部DNS（8.8.8.8、1.1.1.1）では成功するが自社DNSでは失敗する場合：自社DNSサーバーの設定・稼働状態を確認する。Windowsサーバーの場合はDNSサーバーサービスの状態（Get-Service DNS）を、Linuxの場合はnamed/unboundのプロセス状態を確認してください。
すべてのDNSサーバーで失敗する場合：DNSサーバーへの疎通自体に問題があるか、問い合わせているドメインのDNSレコードが存在しない（ドメイン失効など）可能性があります。
③DNSサーバーへのping確認
ping 8.8.8.8
ping 192.168.1.1pingが通るのにnslookupで失敗する場合は、DNSサービス（ポート53）が停止しているかファイアウォールでブロックされている可能性があります。ICMPとUDP/TCP53は別のプロトコルのため、pingが通ってもDNSクエリが通るとは限りません。
④DNSのポート53疎通確認
# Windows PowerShell
Test-NetConnection -ComputerName 8.8.8.8 -Port 53
# Linux（ncコマンド）
nc -zv -u 8.8.8.8 53 # UDP
nc -zv 8.8.8.8 53 # TCPPowerShellで「TcpTestSucceeded : True」が返ればポート53へのTCP疎通は確認できます。DNSはデフォルトでUDP/53を使いますが、512バイトを超える応答（DNSSECや大量のSRVレコードなど）ではTCP/53にフォールバックします。両方のプロトコルを確認することが重要です。
⑤社内スプリットDNSの設定確認
社内環境で「外部サイトは開けるが社内システムだけ名前解決できない」場合は、スプリットDNS（内外で異なるDNSゾーンを使う構成）の設定を確認します。
# 社内DNSで社内ホスト名を引く
nslookup intranet.company.local 192.168.1.1
# 社内DNSで外部ドメインも引けるか確認（フォワーダー設定の確認）
nslookup google.com 192.168.1.1社内DNSで外部ドメインが引けない場合は、フォワーダー設定（社内DNS→上位DNS）が壊れているか、社内DNSサーバーからインターネットへのUDP/TCP53番ポートがファイアウォールでブロックされています。
DNSエラーコード別の原因と対処法
| エラーコード・メッセージ | 意味 | 主な原因 | 対処の方向性 |
|---|---|---|---|
| NXDOMAIN | ドメインが存在しない | ドメイン失効・タイポ・レコード削除・委譲設定ミス | dig +traceで委譲経路を追い、どのサーバーがNXDOMAINを返すか確認 |
| SERVFAIL | サーバーが処理失敗 | 権威DNSへの到達不可・DNSSEC検証失敗・再帰問い合わせ失敗 | dig +cd で DNSSEC無効化して試す。権威NSサーバーへ直接問い合わせ |
| REFUSED | 問い合わせが拒否された | 再帰問い合わせを許可していないDNSサーバーへの問い合わせ | 権威DNSへの再帰問い合わせはREFUSEDが返って正常。フルサービスリゾルバーに問い合わせを向ける |
| NOERROR（ANSWER 0件） | ドメインは存在するがレコードがない | Aレコードを削除したままにしている・レコードタイプの指定ミス | 別のレコードタイプ（AAAA・CNAMEなど）を確認。DNS管理コンソールでレコード有無を確認 |
| Request timed out | 応答がない（タイムアウト） | DNSサーバーへの到達不可・ポート53ブロック・DNSサービス停止 | ping・tracert・ポート53疎通確認を実施 |
よくある勘違いと見落としポイント
現場でDNS名前解決が遅い・失敗する問題を調査する際、勘違いによって時間を無駄にするケースが多くあります。以下の点は特に注意してください。
| よくある勘違い | 実際の状況・正しい対処 |
|---|---|
| pingが通るからネットワークは問題ない | pingはICMPを使う。DNSはUDP/TCPポート53を使うため、ICMPが通っても53番ポートがFWでブロックされている場合がある |
| DNSを8.8.8.8に変えたら解決した＝社内DNSが悪い | スプリットDNS環境では社内名前解決が必要。8.8.8.8に変えると社内ホスト名（intranet.company.localなど）が引けなくなる場合がある |
| キャッシュクリアを繰り返す | キャッシュクリアは根本解決ではない。TTL設定やDNSサーバーの状態・レコード内容を確認する必要がある |
| nslookupが成功したからDNSは問題ない | nslookupはOSのDNSキャッシュを使わない実装の場合がある。アプリケーションが参照するDNS（getaddrinfo経由）と結果が異なるケースがある |
| tracertのタイムアウトは必ず障害 | 一部のルーターはICMPのTTL超過に応答しない設定になっているため、途中が「* * *」でも最終的に到達できていれば問題ない場合がある |
| TTLが長いから問題ない | TTLが長いと、DNSレコードを変更しても世界中のキャッシュサーバーに古い情報が残り続ける。サーバー移転前はTTLを短く（300秒程度に）しておく必要がある |
確認フロー全体のまとめと実施順序
ここまでの内容を整理して、DNS名前解決 トラブルシューティングの確認フロー全体を示します。この順序で実施することで、無駄な手戻りなく原因を特定できます。
- IPアドレス直打ちテスト：DNSをバイパスして疎通確認。繋がればDNS問題、繋がらなければ回線・ルーティング問題の可能性が高い
- nslookupで名前解決を確認：デフォルトDNS vs 外部DNS（8.8.8.8・1.1.1.1）を比較し、問題のあるDNSサーバーを特定。エラーコード（NXDOMAIN・SERVFAILなど）も確認する
- digでQuery timeとTTLを確認（Linux/macOS）：応答時間を計測して遅延の有無を数値で把握。+traceで委譲経路を追い、遅延発生ポイントを特定する
- DNSサーバーへのping・ポート53疎通確認：到達できているかを確認。到達できなければtracertで経路確認へ
- tracert / traceroute / mtrで経路確認：どのホップで遅延や到達不可が発生しているかを特定し、DNS問題か回線・ネットワーク遅延問題かを判別
- キャッシュクリア後に再確認：キャッシュが原因かどうかを確認（根本解決ではなく切り分けとして実施）
- DNSサーバー設定・DNSSEC・スプリットDNSの確認：それでも解決しない場合はDNSサーバー自体の設定・稼働状態・フォワーダー設定を確認する
DNS名前解決が遅い・失敗する問題は、「DNSサーバーへの到達不可」「DNSサーバーの設定ミス・停止」「回線のネットワーク遅延」「ローカルキャッシュの問題」「DNSSEC検証失敗」「スプリットDNSの設定ミス」など複数の原因が絡み合うことがあります。一つのコマンドで判断せず、nslookup・dig・tracertを組み合わせて系統的に切り分けることが、現場での確実な問題解決につながります。特に企業ネットワーク環境では、ファイアウォールのACLやスプリットDNS構成が絡むことが多いため、ネットワーク構成図とDNSサーバーの設定ファイルを手元に置きながら確認フローを進めることを強く推奨します。
