名前解決できない障害の切り分け｜DNSを疑う順番と確認手順
「サイトにつながりません」と連絡が来て、調べてみる。ping を IP で打つと返ってくる。でも、ドメイン名で叩くと「名前が解決できません」と言われる——。
こういうとき、アプリやサーバー本体を先に疑ってしまいがちですが、実はサーバーは元気で、名前解決（DNS）だけが引っかかっている、という現場は少なくありません。DNSはふだん意識しない裏方なので、いざ止まると「どこから見ればいいのか」で遠回りしやすいところです。ここは、経験のある人でも順番を間違えると沼りやすい。
この記事では、名前解決できない障害を、DNSを疑う順番に沿って一緒に切り分けていきます。まずは「本当にDNSが原因か」を1コマンドで確かめるところから。全部を一度に調べなくて大丈夫です。
用語：DNS（Domain Name System）は、example.com のような名前を、通信に使う数字の住所（IPアドレス）に変換する仕組みのことです。この変換を名前解決と呼びます。名前解決が止まると、サーバーが生きていても「名前でたどり着けない」状態になります。
結論：切り分けは上から順に4段です。①本当にDNSか確認する（IP直打ちで通り、名前でだけ失敗するか）、②自分のサーバーがどのDNSを見ているか確認する（参照先の設定を見る）、③キャッシュを疑う（古い情報が残っていないか）、④それでもダメなら権威DNS側（レコードそのもの）を疑う。この順で、下の階層から上へ、1コマンドずつ確かめていきます。
コマンドやファイルの場所は、OSやバージョンで少しずつ違います（後述します）。この記事の流れを出発点に、自分の環境に読み替えて進めてください。
名前解決は「どこで」引っかかっているのか
名前解決の失敗は「DNSが壊れた」の一言では終わりません。実際には、自分のサーバー → キャッシュDNS → 権威DNSという何段かの受け渡しのどこかで止まっています。どこで詰まっているかを見ずに闇雲に触ると、直っていないのに直った気になったり、関係ない設定をいじって二次被害を出したりします。
- 自分のサーバー：どのDNS（参照先）に聞きにいくかの設定を持っています。ここの設定が間違っていると、そもそも正しい相手に聞けません。
- キャッシュDNS：一度引いた結果をしばらく覚えている中継役です。ここに古い情報が残っていると、レコードを直したのに古い住所を返し続けることがあります。
- 権威DNS：そのドメインの「正解」を持っている大元です。レコードの設定ミスや、切り替え直後の反映待ちは、ここが原因です。
だから切り分けも、この左（自分）から右（権威）へ順にたどるのが遠回りしないコツです。手前で詰まっているのに大元を疑っても、時間だけが過ぎてしまいます。
手順1：本当にDNSが原因かを確かめる
まず、犯人がDNSかどうかの当たりをつけます。ここは数コマンドで済みます。
（1）IP直打ちで通るか、名前でだけ失敗するか
対象のIPアドレスが分かっているなら、IPと名前の両方で疎通を試します。
ping 93.184.216.34 # IPで通るか
ping example.com # 名前で通るかIPでは通るのに名前だと「名前が解決できません（Name or service not known / Temporary failure in name resolution）」と出るなら、通信そのものは生きていて、名前解決だけが引っかかっているサインです。ここでDNSに絞れます。
（2）名前を引けるか単体で確かめる
dig（無ければ nslookup や host）で、名前解決だけを直接試します。
dig example.com出力の ANSWER SECTION にIPアドレスが返っていれば、名前解決自体はできています。status: NXDOMAIN（そんな名前は無い）や status: SERVFAIL（引きにいったが失敗）、あるいは応答自体が返ってこないなら、DNSのどこかで止まっています。
メモ：digが入っていない環境もあります。その場合はnslookup example.comやhost example.comでも同じ確認ができます。まずは自分のサーバーにどれが入っているかを確かめてから進めましょう。
手順2：自分のサーバーがどのDNSを見ているか確認する
DNSが怪しいと分かったら、次は自分のサーバーが、そもそもどこに聞きにいっているかを見ます。ここがズレていると、いくら大元が正しくても引けません。
（1）参照先の設定を見る
多くのLinuxでは、参照先のDNSは次のファイルに書かれています。
cat /etc/resolv.confnameserver の行に並んでいるのが、聞きにいく相手（キャッシュDNS）です。ここが空だったり、もう使っていない古いサーバーのIPだったりすると、名前解決は失敗します。
（2）systemd-resolved を使っている環境
新しめのOSでは、systemd-resolved が名前解決をまとめて管理していることがあります。その場合は次で、実際に使っている参照先や状態を確認します。
resolvectl statusCurrent DNS Server や DNS Servers に、想定どおりの相手が入っているかを見ます。/etc/resolv.conf が 127.0.0.53（resolved 自身）を指しているのは、この構成では正常です。
（3）参照先を指定して引き比べる
参照先が怪しいときは、信頼できる外部のキャッシュDNS（例：8.8.8.8 や 1.1.1.1）を明示して引いてみます。
dig @8.8.8.8 example.comこれで引けるのに、参照先を指定しない dig example.com では引けないなら、問題は自分のサーバーの参照先設定か、社内のキャッシュDNSにある、と切り分けられます。
手順3：キャッシュ（古い情報）を疑う
「レコードを直したのに、古いIPを返し続ける」ときは、キャッシュが犯人です。DNSは同じ問い合わせを何度も繰り返さないよう、結果を一定時間（TTL）覚えています。
- TTLの残りを確認する：
dig example.comのANSWER SECTIONの左側の数字がTTL（秒）です。この時間が経つまで、キャッシュは古い答えを返し続けます。切り替え直後は、このTTLぶんだけ待つ必要があることがあります。 - ローカルのキャッシュを消す：
systemd-resolvedを使っているなら、次で自分のサーバー側のキャッシュを消せます。
sudo resolvectl flush-caches/etc/hostsに古い記述が残っていないか：/etc/hostsに手書きした行があると、DNSより優先されます。昔テスト用に足したまま忘れた1行が、本番の名前を古いIPに固定してしまう——これは現場でよくある落とし穴です。
cat /etc/hostsキャッシュや /etc/hosts が原因のときは、大元（権威DNS）はずっと正しい答えを持っています。ここを疑わずに権威側をいじると、かえって事故のもとです。まずは手前を消して確かめましょう。
手順4：それでもダメなら権威DNS（レコード）を疑う
手前をすべて確かめても引けない、あるいは dig @8.8.8.8 でも NXDOMAIN / SERVFAIL が返るときは、大元の権威DNSやレコードそのものを疑います。
- 大元まで直接たどる：
dig +trace example.comで、ルートから権威DNSまで、どこまでたどり着けているかを段階的に見られます。途中で止まっていれば、そこが怪しい場所です。 - 権威DNSに直接聞く：そのドメインを管理しているDNSサーバー（レジストラや外部DNSサービスの管理画面で確認できます）に対して
dig @権威DNSのアドレス example.comを打つと、大元が返す「正解」を確かめられます。 - レコードの設定を見直す：Aレコード（名前とIPの対応）やCNAME、NSレコードに、消し忘れ・打ち間違い・全角文字の混入がないか。DNSの切り替え直後なら、反映（浸透）待ちのこともあります。
権威側は、自分のサーバーの中だけでは直せないことが多い場所です。ここまで切り分けられていれば、DNSサービスの管理画面やベンダーへの問い合わせも、状況を具体的に伝えられます。「名前が引けない」ではなく「権威DNSに直接聞くと SERVFAIL が返る」まで言えれば、話が早く進みます。
そのまま使えるチェックリスト
名前解決できないトラブルに当たったとき、上から順に確認してください。手前（自分側）から大元（権威）へ進むのがコツです。
- IP直打ちでは通り、名前でだけ失敗しているか（DNSに絞れるか）
-
dig（またはnslookup/host）で、名前が引けるか・statusは何か確認したか -
/etc/resolv.confのnameserverが、正しい参照先になっているか -
systemd-resolved環境ならresolvectl statusで参照先を確認したか -
dig @8.8.8.8など外部DNS指定では引けるか（参照先の問題か切り分け） -
ANSWERのTTLを見て、切り替え直後の反映待ちでないか確認したか -
/etc/hostsに古い・不要な行が残っていないか - ローカルのDNSキャッシュを消して（
resolvectl flush-caches等）試したか -
dig +traceや権威DNSへの直接問い合わせで、大元の答えを確かめたか - 権威側が原因なら、レコード設定・反映待ち・ベンダー確認に切り分けられたか
全部に○が付かなくても大丈夫です。まずは「IPで通るか・名前で通るか」を1回試して、DNSに絞れるかを見るところからで十分です。それだけで、次に「つながらない」と言われたとき、切り分けの入口をひとつ多く持てます。
よければ、こちらも
名前解決の切り分けは、疎通確認やログ調査といった前後の作業とつながっています。あわせて手元に置いておくと、いざという時に落ち着けます。
- 疎通しないときの切り分け｜ping・traceroute・digの基本：名前解決の一歩手前、「そもそも通信が届いているか」を確かめる基本の道具です。
- 外部API連携の不具合｜相手側か自分側かを切り分ける：連携先に「つながらない」原因が名前解決だった、というケースの切り分けに。
- 500エラーが出たら最初に見る5つのログ｜場所と確認の順番：名前解決の失敗がアプリのエラーとして出ているとき、どのログから追うかの入口です。
名前解決のトラブルは、順番さえ決まっていれば、意外と短い時間で「どこで詰まっているか」までたどり着けます。手前から大元へ一段ずつ——その道筋を一度持っておくと、「つながりません」の連絡が来ても、慌てずに最初の一手を打てます。 今日はまず、IPと名前の両方で ping を打って、DNSに絞れるかを確かめるだけで十分です。その小さな切り分けの習慣が、原因の見えないトラブルに強い運用へと、少しずつ近づけてくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。