名前解決の確認
つながらない原因が「経路」なのか「名前解決」なのかを切り分けることは重要です。IPアドレス直打ちでは届くのに名前ではダメな場合、DNSが疑わしいといえます。dig や nslookup で対象ドメインのIPアドレスや応答してくれるDNSサーバを確認します。dig は応答の詳細まで見られ、nslookup は手軽に引けるのが特徴です。
前のトピックの最後で、鮮やかな切り分けの種をまいた。ここで回収しよう。
「つながらない」という症状に出くわしたとき、その原因が経路（パケットの通り道）にあるのか、それとも名前解決（名前からIPアドレスへの変換）にあるのか。この二つはまったく別の段階で起きる問題なので、ごちゃ混ぜにして闇雲に設定を見直すと遠回りになる。
切り分けの考え方はシンプルだ。IPアドレスを直接指定すれば届くのに、名前を指定すると届かない。この状況なら、ネットワークの経路そのものは生きていて、疑うべきは名前解決、つまりDNS側だと判断できる。
逆に、名前でもIPアドレスでも届かないなら、問題はより下の層（経路やゲートウェイ、インターフェース）にある可能性が高い。この一段を意識するだけで、調べる範囲が半分に絞れる。では、名前解決が生きているかを、どう確かめるのか。
🔎 名前は、本当に引けているのか
名前解決の状態を詳しく調べる定番が dig コマンドだ。dig www.example.com のように使うと、問い合わせの詳細な結果が表示される。
注目すべきはANSWER SECTION（応答欄）で、ここに名前に対応するIPアドレス（AレコードならIPv4アドレス）が並ぶ。ここにアドレスが返ってくれば名前解決は成功しており、返ってこなければ解決に失敗している、と読み取れる。
答えだけを手早く知りたいときは dig +short www.example.com とすると、対応するIPアドレスだけが短く表示される。
さらに出力の末尾にある SERVER の行には、実際に問い合わせに答えてくれたDNSサーバのアドレスが示されるので、「どのDNSサーバが応答しているか」も同時に確認できる。名前解決はふだんUDPの53番ポートで行われるので、SERVER 行にも 53 番が示される。前のトピックの知識が、そのまま出力の読み取りに効いてくる。
dig の真価は、トラブルの切り分けで発揮される。特定のDNSサーバに直接問い合わせたいときは dig @8.8.8.8 www.example.com のように @ に続けてサーバのアドレスを指定する。これを使うと、いま設定されているDNSサーバの調子が悪いのか、それとも名前そのものに問題があるのかを分けて確かめられる。
たとえば、設定中のサーバでは引けないのに、別のサーバを指定すると引ける場合、原因は自分の参照先DNSサーバ側にあると分かる。
逆にIPアドレスからホスト名を引きたいときは dig -x 203.0.113.10 のように -x を使う（逆引き）。逆引きは登録されていないことも多いので、引けなくても異常とは限らない。どの階層のサーバを順にたどって答えにたどり着いたかを根元から追いたいときは dig +trace も使える。
これらを組み合わせると、「名前が登録されていないのか」「自分のDNSサーバだけが答えられないのか」「経路の問題でDNSサーバに届いていないのか」を一つずつ切り分けられる。
⚡ もっと手軽に試したいとき
dig は情報が細かいぶん、ちょっと大げさに感じることもある。より手軽に名前解決を試したいときは nslookup コマンドも使える。
nslookup www.example.com とすると、最初に問い合わせ先のDNSサーバ（Server と Address）が表示され、続いて結果が出る。出力の最後の Address 行が、指定した名前に対応するIPアドレスだ。途中に canonical name と出ることがあるが、これは別名（エイリアス）の本当の名前を示している。
dig が応答の全項目を省略せず細かく見せてくれるのに対し、nslookup は要点を手早く確認するのに向く。どちらを使ってもよいので、まずは結果のIPアドレスが返るかどうかに注目しよう。返らなければ、DNSサーバの設定ミスや到達不可が疑われる。なお、より詳しく確実に調べたい現場では、nslookup より dig が好まれる傾向がある。
📇 答える相手を、間違えていないか
名前解決がうまくいかないとき、見落としがちな盲点がある。そもそも自分が、どのDNSサーバに問い合わせているのか、だ。
Linuxでは参照先のDNSサーバが /etc/resolv.conf の nameserver 行に書かれている。ここに正しいサーバのアドレスが書かれていなかったり、到達できないアドレスが指定されていたりすると、名前解決そのものが成立しない。
dig の出力末尾の SERVER 行と、このファイルの内容を突き合わせれば、「想定どおりのサーバに問い合わせているか」を確かめられる。多くの環境ではこのファイルは自動生成されるが、調査の際は中身を一度確認しておくと安心だ。DNSサーバ自体に到達できているかは、その nameserver のアドレスへ ping を打って確かめることもできる。
🩺 つまずいたら、まずここ
最後に、迷わないための「順番」をまとめておく。
まず ping を名前で打ってみて失敗したら、同じ相手をIPアドレスで ping してみる。IPアドレスなら通るのに名前で通らないなら、これは名前解決の問題だと確定できるので、dig や nslookup でその名前が引けるかを確かめ、引けなければ /etc/resolv.conf のDNSサーバ設定や、dig @別のサーバ での比較に進む。
逆に名前でもIPでも通らないなら、DNSではなく経路側の問題として ip addr・ip route・traceroute などで調べる方向へ切り替える。
このように、名前解決という一段を独立した検査項目として扱うことで、「なぜか特定のサイトだけ開けない」「IPでは入れるのにURLでは開けない」といった分かりにくい症状も、落ち着いて原因の所在へたどり着けるようになる。
dig や nslookup、/etc/resolv.conf の確認はいずれも状態を見るだけの安全な操作なので、つながらないと感じたら、まず名前が引けるかどうかを早い段階で確かめる癖をつけておくと、無駄な設定変更を避けられる。