CCNA学習71日目｜DNS 入門（第3回）確認コマンドの見方とトラブルシューティング

CCNA学習71日目のDNS入門（第3回）アイキャッチ画像。確認コマンドの見方とトラブルシューティングをテーマに、Packet Tracerの最小構成、show hosts と ping による確認、DNSレコードの入力ミス修正の流れを分かりやすく表したCCNA学習記事用サムネイル 資格学習ログ
2026.07.14

こんにちは。CCNA学習71日目です。
今回は Packet Tracer を使って、DNS の最小構成での設定と確認を行いました。前回までは DNS の役割や、ルータが DNS クライアントとして動く考え方を中心に整理してきましたが、今回はそこから一歩進んで、確認コマンドで何を見るのか、そしてうまく名前解決できないときにどこを疑うのかを整理する回になりました。

今回の最小構成

Packet Tracerで作成したDNS学習用の最小構成図。Router1、PC1、Server1をSwitch1で接続したシンプルな構成で、DNS設定と確認の前提となるネットワーク構成を示した図
Packet Tracer で作成した DNS 学習用の最小構成です。Router1、PC1、Server1 を Switch1 で接続し、シンプルな環境で名前解決の確認を行いました。

今回の構成は、Router1・PC1・Server1 を Switch1 で接続したシンプルな最小構成です。
Server1 は DNS サーバとして動かし、Router1 や PC1 から名前解決の確認を行う形でした。リンクも正常に上がっており、まずはこの状態で IP 疎通と DNS 動作を確認していきました。

今回の確認ポイント

DNS確認コマンドの見方を整理した図。show hosts でDNS関連情報、ping 192.168.1.10 でIP疎通、ping server1.lab.local で正引き確認を行う流れと、DNS設定を疑う判断ポイントをまとめた図解
DNS の確認で見るポイントを整理した図です。まず IP で疎通確認を行い、そのうえで DNS サーバ設定や Resource Records を確認し、最後にホスト名で再確認する流れが分かります。

今回の確認で中心になったのは、次の3つです。

  • show hosts：DNS 関連情報の確認
  • ping 192.168.1.10：IP での疎通確認
  • ping server1.lab.local：ホスト名での正引き確認 確認コマンド図

DNS まわりの確認では、いきなり「名前で通るか」だけを見るのではなく、まずIPで通るかを確認し、そのあと名前で確認する流れがとても大事だと分かりました。

show hosts で見ること

show hosts は、DNS に関する情報を確認するためのコマンドです。
DNS を使う設定が入っているか、どんな名前解決情報を持っているかを確認するときの入口になります。今回のように「IPでは通るのに、名前では通らない」というときは、まず DNS 側の情報を疑うきっかけになります。

ping 192.168.1.10 と ping server1.lab.local の違い

ping 192.168.1.10 は、純粋なIP疎通確認です。
これが通るなら、少なくとも PC1 から Server1 までの通信経路そのものには大きな問題がないと考えやすくなります。

一方で ping server1.lab.local は、名前解決も含めた確認になります。
こちらが失敗する場合は、単なる通信障害ではなく、DNS サーバ設定や Resource Records の内容を疑う流れになります。

確認の流れ

今回のキャプチャでは、確認の流れがとても分かりやすく整理されていました。

  1. IP で疎通確認
  2. DNS Server 設定確認
  3. Resource Records 確認
  4. ホスト名で再確認

この順番で見ていくと、問題が「通信そのもの」なのか、「DNS サーバ設定」なのか、「登録名のミス」なのかを切り分けやすくなります。
特に、IPで通るのに名前で通らない場合は DNS 設定を疑う、という考え方はとても大事だと感じました。

今回詰まったこと

今回詰まったのは、PC1 から Server1 に対してホスト名で ping したときに失敗したことです。
一方で、R1 では正引きに成功しており、さらに PC1 から 192.168.1.10 への ping も成功していました。つまり、通信経路は問題なさそうなのに、PC1 からホスト名でだけ失敗するという状態でした。

原因

原因は、Server1 側の Resource Records の入力ミスでした。
登録されていた名前が
誤：servwe1.lab.local
になっており、本来問い合わせたかった
正：server1.lab.local
と一致していませんでした。

DNS は「だいたい似ていれば通る」ものではなく、登録名と問い合わせ名が完全一致して初めて成功する仕組みなので、1文字の違いでも失敗することがよく分かりました。

解決後

Resource Records の内容を正しく修正したあと、PC1 からの名前解決は成功しました。
これによって、DNS 設定自体は正常に動いていたこと、問題は通信経路ではなく 登録レコードのタイポ にあったことがはっきりしました。

「今回詰まったこと」「原因」「解決後」の説明部分の直前または直後 alt：DNSトラブルシューティングの実例を整理した図。PC1からホスト名でのpingが失敗した原因がServer1のResource Recordsの入力ミスであり、server1.lab.local への修正で解決した流れを示した図解
DNS トラブルの実例を整理した図です。IP では通るのにホスト名では通らない場合、通信経路ではなく DNS の登録内容を疑う必要があることがよく分かります。

今回の学習ポイント

今回の学習で特に大きかったのは、DNS は1文字の違いでも失敗するということです。
IPで通るか、DNSサーバ設定は正しいか、レコード名は完全一致しているか、という順番で見ていけば、落ち着いて原因を切り分けられると感じました。

まとめ

今回は、DNS の確認コマンドの見方と、名前解決がうまくいかないときのトラブルシューティングを整理しました。
show hosts、IPでの疎通確認、ホスト名での再確認を分けて考えることで、DNS の問題をかなり見つけやすくなります。特に 「IPで通るのに名前で通らないなら DNS 設定を疑う」 という流れは、今後も大事な基本になりそうです。

また今回は、実際に Resource Records の入力ミス で失敗したことで、DNS が文字列の完全一致で動く仕組みもより理解できました。うまくいかなかった経験があった分、確認の順番と見るポイントがかなり整理できた気がします。

コメント

タイトルとURLをコピーしました