NWトラブルシュートとDNS LinuC102 第4回

LinuC レベル1 102試験対策シリーズの第4回です。前回はネットワークの「平時の構成」を読み取りました。今回は 「つながらないとき」 の切り分け方と、DNS クライアントの仕組み を扱います。ping traceroute mtr dig host nslookup getent、そして /etc/resolv.conf /etc/hosts /etc/nsswitch.conf の3ファイルを実機で読み解きます。

今ここマップ

LinuC 102 試験対策シリーズ（全12回）

  第1回 シェル環境のカスタマイズ
  第2回 Bashスクリプト入門
  第3回 ネットワーク基礎
▶ 第4回 ネットワークトラブルシューティングとDNS    ← いまここ
  第5回 ユーザ・グループ管理と sudo 設定
  第6回 ジョブスケジューリングと時刻管理
  第7回 ログ管理実践
  第8回 メール配送エージェント(MTA)の基本
  第9回 ファイアウォールと SELinux 入門
  第10回 暗号化によるデータ保護
  第11回 クラウドセキュリティの基礎
  第12回 オープンソースの文化

この記事で身につくこと

1. ping traceroute tracepath mtr で疎通確認・経路追跡ができる
2. dig host nslookup で DNS 解決を確認できる
3. /etc/resolv.conf の nameserver と search の意味を理解する
4. /etc/hosts と /etc/nsswitch.conf の hosts: 行で解決優先順位が決まることを説明できる
5. レイヤー別（リンク → IP → ルート → DNS → アプリ）で障害を切り分けられる

第1章：「つながらない」を分解する

1.1 障害の正体は1つではない

「サーバにつながらない」と一言で言っても、実際には次のように複数の異なる問題が混ざります。

• LAN ケーブルが抜けている／NIC が DOWN になっている（リンク層）
• IP アドレスが割り当てられていない／ルーティングが間違っている（IP 層）
• ファイアウォールでブロックされている（IP・トランスポート層）
• DNS でホスト名が引けない（アプリケーション層の下層）
• サーバ側でサービスが起動していない／待ち受けていない（アプリ層）

これを 「下から順に」 確認していくのが基本セオリーです。リンク → IP → ルート → DNS → アプリ。誰のために、なぜこの順序かというと：

• 開発者のため：「アプリのバグ」と「インフラの不具合」を切り分けたい。アプリ層に手を入れる前に下層を疑う
• 運用者のため：障害復旧時間を最短化したい。下から見ていけば、上位での無駄な調査を避けられる
• サポートのため：一次切り分けで「これは NW チーム案件」「これは DBA 案件」と振り分けたい

第2章：疎通確認 ── ping

2.1 ping は ICMP Echo を使う

ping は ICMP Echo Request を送って Echo Reply を待つコマンドです。TCP や UDP は使いません。「相手が生きていて、ICMP に応答する設定になっていれば」返事が返ります。

linuc-alma で実行 ── linuc-ubuntu に疎通を取ります。

実行コマンド：

$ ping -c 3 10.0.10.133

実行結果：

PING 10.0.10.133 (10.0.10.133) 56(84) bytes of data.
64 バイト応答 送信元 10.0.10.133: icmp_seq=1 ttl=64 時間=0.208ミリ秒
64 バイト応答 送信元 10.0.10.133: icmp_seq=2 ttl=64 時間=0.972ミリ秒
64 バイト応答 送信元 10.0.10.133: icmp_seq=3 ttl=64 時間=0.560ミリ秒

--- 10.0.10.133 ping 統計 ---
送信パケット数 3, 受信パケット数 3, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.208/0.580/0.972/0.312 ms

主要オプション：

• -c 回数：指定回数で停止（指定しないと Ctrl+C まで続く）
• -W タイムアウト：応答待ち秒数
• -i 間隔：送信間隔（既定 1秒）
• -s サイズ：パケットサイズ

2.2 応答がない場合の挙動

存在しないホスト（10.0.10.250）に ping してみます。

実行コマンド：

$ ping -c 2 -W 2 10.0.10.250

実行結果：

PING 10.0.10.250 (10.0.10.250) 56(84) bytes of data.

--- 10.0.10.250 ping 統計 ---
送信パケット数 2, 受信パケット数 0, 100% packet loss, time 1044ms

100% packet loss。応答行が一切出ません。終了ステータスは 1 です（成功時は 0）。スクリプトでの疎通判定に使えます。

2.3 ping が通らない原因の典型

• 相手ホストが停止している
• 経路がない（ルーティング設定誤り）
• ファイアウォールで ICMP がブロックされている
• ICMP 自体が無効化されている（クラウドの SecurityGroup でよくある）

「ping が通らない = 物理的につながっていない」ではない。ICMP は遮断していて TCP は許可というケースも多いので、ping NG だけで諦めずに ss や telnet（TCP）の確認も行います。

第3章：経路を追う ── traceroute / tracepath / mtr

3.1 traceroute の仕組み

パケットが宛先までたどる経路（途中のルーター）を表示するのが traceroute です。仕組みは TTL を 1, 2, 3, … と増やしてパケットを送り、各ルーターから返ってくる「TTL 超過」メッセージを集める こと。

AlmaLinux Minimal Install では未導入のため、事前にインストールします。linuc-alma で実行

実行コマンド：

$ sudo dnf install -y traceroute mtr

導入後、linuc-ubuntu まで経路を追います。

実行コマンド：

$ traceroute -n 10.0.10.133

実行結果（例）：

traceroute to 10.0.10.133 (10.0.10.133), 30 hops max, 60 byte packets
 1  10.0.10.133  0.234 ms  0.180 ms  0.176 ms

同一セグメント（10.0.10.0/24）の宛先なので 1ホップで到達。主要オプション：

• -n：数値表示（DNS 逆引きしない、速い）
• -I：ICMP を使う（既定は UDP）
• -T：TCP を使う（ファイアウォールで UDP が遮断されている場合）
• -w 秒：応答待ち
• -q 回数：各ホップでのプローブ回数

3.2 tracepath ── 特権なしで動く簡易版

traceroute は raw socket を使うため一部の権限が必要です。tracepath は iputils 標準で root 不要、AlmaLinux Minimal Install でも最初から入っています。

実行コマンド：

$ tracepath 10.0.10.133

実行結果：

 1?: [LOCALHOST]                      pmtu 1500
 1:  linuc-ubuntu.linuc.local                              0.271ミリ秒 到達しました
 1:  linuc-ubuntu.linuc.local                              0.190ミリ秒 到達しました
     Resume: pmtu 1500 hops 1 back 1 

pmtu は Path MTU（経路上の最大パケットサイズ）。同一セグメント直結のため 1 hop で到達しました。

3.3 mtr ── traceroute + ping の合体技

mtr は経路上の各ルーターに継続的に ping を送り続け、パケットロス率や RTT のばらつきを可視化します。間欠的な障害の発見に強力です。

実行コマンド：

$ mtr -rwc 3 10.0.10.133

実行結果（例）：

Start: 2026-05-12T...
HOST: linuc-alma                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- linuc-ubuntu.linuc.local   0.0%     3    0.2   0.3   0.2   0.4   0.1

主要オプション：-r レポートモード、-w 長いホスト名対応、-c 回数 プローブ回数、-n 数値表示。インタラクティブモード（オプションなし）では実行中に動的に更新されます。

第4章：DNS の基本と問い合わせ

4.1 DNS は「名前 ↔ IP」の電話帳

人間が覚えやすい example.com のような名前を、機械が使う 93.184.216.34 のような IP に変換するのが DNS（Domain Name System） です。ポートは UDP/TCP 53。通常は UDP、大きなデータは TCP。

4.2 主なレコードタイプ

タイプ	意味	例
A	名前 → IPv4 アドレス	example.com → 93.184.216.34
AAAA	名前 → IPv6 アドレス	example.com → 2606:2800:220:1:...
CNAME	別名（エイリアス）	www → example.com
MX	メールサーバ	example.com → mail.example.com
NS	権威 DNS サーバ	example.com → ns1.example.com
TXT	テキスト（SPF・DKIM 等）	"v=spf1 ..."
PTR	IP → 名前（逆引き）	34.216.184.93.in-addr.arpa → example.com

4.3 dig ── 推奨される問合せツール

本シリーズで使う内部 DNS は linuc-proxy（10.0.10.131）で動く dnsmasq です。linuc-ubuntu.linuc.local を引いてみます。linuc-alma で実行

実行コマンド：

$ dig linuc-ubuntu.linuc.local

実行結果：

; <<>> DiG 9.16.23-RH <<>> linuc-ubuntu.linuc.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22513
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;linuc-ubuntu.linuc.local.      IN      A

;; ANSWER SECTION:
linuc-ubuntu.linuc.local. 0     IN      A       10.0.10.133

;; Query time: 0 msec
;; SERVER: 10.0.10.131#53(10.0.10.131)
;; WHEN: Mon May 11 23:47:33 JST 2026
;; MSG SIZE  rcvd: 69

読み方：

• QUESTION SECTION：質問した内容（linuc-ubuntu.linuc.local の A レコード）
• ANSWER SECTION：答え（A 10.0.10.133）
• SERVER：どの DNS から答えが返ったか（10.0.10.131#53）
• WARNING: .local is reserved for mDNS：本来 .local は mDNS 用なので警告が出ている。検証環境では dnsmasq が応答しているため動くが、実環境では .lan .internal 等を使うのが推奨

4.4 dig +short ── スクリプト向け短縮表示

実行コマンド：

$ dig +short linuc-ubuntu.linuc.local
$ dig @10.0.10.131 linuc-ubuntu.linuc.local +short
$ dig -x 10.0.10.133 +short

実行結果：

10.0.10.133
10.0.10.133
linuc-ubuntu.linuc.local.

• +short：結果だけ表示（スクリプト向け）
• @サーバ：問い合わせ先 DNS サーバを指定
• -x IP：逆引き（IP → 名前、PTR レコード）
• +trace：ルート DNS から段階的にたどる（権威の流れを見たいとき）

4.5 host と nslookup ── 簡易版と旧式

実行コマンド：

$ host linuc-ubuntu.linuc.local
$ nslookup linuc-ubuntu.linuc.local

実行結果：

linuc-ubuntu.linuc.local has address 10.0.10.133

Server:		10.0.10.131
Address:	10.0.10.131#53

Name:	linuc-ubuntu.linuc.local
Address: 10.0.10.133

host は出力が一行で済む簡易版。nslookup は古い形式で 非推奨 ですが、LinuC 試験範囲には含まれます。

4.6 getent hosts ── nsswitch 経由で確認

dig や host は DNS だけを引きます。一方、アプリ（curl など）が実際に使う解決は nsswitch.conf に従うため、/etc/hosts も含めた解決を確認したいときは getent を使います。

実行コマンド：

$ getent hosts linuc-ubuntu.linuc.local
$ getent hosts no-such-host.example.invalid ; echo "exit: $?"
$ getent hosts localhost

実行結果：

10.0.10.133     linuc-ubuntu.linuc.local
exit: 2
::1             localhost localhost.localdomain localhost6 localhost6.localdomain6

解決失敗時の終了ステータスは 2。スクリプトで判定に使えます。localhost は IPv6 の ::1 が先に返っているのも観察できます。

第5章：DNS クライアント設定の3ファイル

5.1 /etc/hosts ── 静的なホスト名↔IP の対応

DNS より前から存在する仕組みです。テキストファイルに「IP ホスト名」を並べておくと、DNS より前に 解決されます（順序は nsswitch 次第）。

実行コマンド：

$ cat /etc/hosts

実行結果：

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

初期状態は localhost の定義のみ。検証や障害時の暫定対応で IP を追加することがありますが、後で消し忘れると事故の元です（第8章ヒヤリハット）。

5.2 /etc/resolv.conf ── nameserver と search

実行コマンド：

$ cat /etc/resolv.conf

実行結果：

# Generated by NetworkManager
search linuc.local
nameserver 10.0.10.131

• nameserver IP：問い合わせ先 DNS サーバ。最大 3 行まで記述可能（順に試行）
• search ドメイン：単純な名前（ホスト名だけ）を引くときに自動で付加するドメイン。linuc-ubuntu と書けば linuc-ubuntu.linuc.local として問い合わせる
• domain ドメイン：search の単一指定版（古い形式）
• options：タイムアウト・試行回数等のチューニング

冒頭の # Generated by NetworkManager が重要です。このファイルは NetworkManager によって再生成されます。手で編集しても接続再起動で消えます。永続的に DNS を変えたければ第3回で扱った nmcli connection modify eth0 +ipv4.dns 10.0.10.131 のように設定します。

5.3 /etc/nsswitch.conf ── 解決優先順位

実行コマンド：

$ grep ^hosts /etc/nsswitch.conf

実行結果：

hosts:      files dns myhostname

これが 解決の優先順位 です。

1. files = /etc/hosts を見る（最優先）
2. dns = DNS（/etc/resolv.conf の nameserver）に問い合わせる
3. myhostname = 自分自身のホスト名を解決する内蔵モジュール

つまり「/etc/hosts に書かれていれば DNS は引かれない」のが既定動作。これが第8章のヒヤリハットにつながります。

他の解決対象（passwd / group / shadow / netgroup / services 等）の優先順位も同じファイルで設定されます。man nsswitch.conf 参照。

第6章：レイヤー別切り分けの実践

6.1 切り分け5ステップ

1. リンク層：ip link show で対象 NIC が UP か
2. IP 層：ip addr show で IP が正しく割り当てられているか
3. ルート：ip route show で宛先への経路があるか・デフォルトゲートウェイは正しいか
4. DNS：dig 名前 で解決できるか
5. アプリ：ss -tuln（自サーバ側）／ ssh や curl で TCP 接続が成立するか

下から順に進めば、上位での無駄な調査を避けられます。「DNS が遅い」と感じても、原因は ip route のデフォルトゲートウェイの設定だけ、というケースは現場でよくあります。

6.2 切り分けパターン早見表

症状	疑うべきこと
ping IP NG	リンク／IP／ルート／FW の問題
ping IP OK / ping name NG	DNS の問題（resolv.conf or nameserver 障害）
ping OK / TCP 接続 NG	サーバ側 FW or サービス停止（ss で確認）
traceroute が途中で「* * *」	その先のルーター で ICMP/UDP がブロック（ファイアウォール）
解決はできるが IP が変	/etc/hosts に古い記述（ヒヤリハット）

現場での使いどころ

• アラート受領時の一次切り分け：ping → dig → ss の3点セット。3分以内で「NW or DNS or アプリ」の当たりを付ける
• 遅延の原因特定：mtr で経路の特定区間でロス・遅延が発生しているか可視化
• DNS 障害時の暫定対応：/etc/hosts に IP を直書きしてサービス継続。復旧後の削除を必ず手順に入れる
• DNS キャッシュフラッシュ：systemd-resolved 環境なら resolvectl flush-caches、dnsmasq なら sudo systemctl restart dnsmasq
• 新規サーバの初期確認：cat /etc/resolv.conf cat /etc/nsswitch.conf | grep hosts dig 内部ドメイン名 で DNS 設定の正しさを確認
• 監視のヘルスチェック：第2回で書いた Bash スクリプトに ping -c 1 -W 2 や getent hosts を組み込んで、終了ステータスで判定
• クラウドでの応用：AWS の VPC エンドポイント・Route53、Azure の Private DNS など、概念は同じ。問題が出たら resolv.conf の中身（または DHCP 取得の DNS）を疑う

第8章：ヒヤリハット ── 暫定 hosts の残置でサーバ移行時に旧 IP に接続継続

教訓：暫定対応には必ず「戻し」を組み込む

• 応急処置にはコメントで期限を書く：# TODO: 2026-05-31 DNS 復旧後に削除（impact: ticket-1234）
• cron などで定期 grep する：grep -v '^#' /etc/hosts | grep -v '^127\|^::1' | grep -v '^$' で「localhost 以外の何か」を検出。残置をアラート化
• サーバの構成管理ツール（Ansible 等）で hosts を上書き：手動変更を上書きで戻す仕組みを入れる
• 切り分けの早い段階で getent hosts を確認：「DNS 引いてみる」だけでは hosts の罠を見落とす。実際にアプリが使う解決経路で確認
• 暫定対応のチケットを必ず立てる：「対応完了 = 暫定残置」になりがち。チケットで戻しを管理

やってみよう

演習1：ping と経路追跡

linuc-alma で実行

$ sudo dnf install -y traceroute mtr
$ ping -c 3 10.0.10.133
$ ping -c 2 -W 2 10.0.10.250            # 存在しないホスト
$ traceroute -n 10.0.10.133
$ tracepath 10.0.10.133
$ mtr -rwc 3 10.0.10.133

到達できるホストと存在しないホストの差を観察します。経路追跡 3コマンドの出力の違いも見比べます。

演習2：dig / host / nslookup / getent で DNS を引く

$ dig linuc-ubuntu.linuc.local
$ dig +short linuc-ubuntu.linuc.local
$ dig @10.0.10.131 linuc-ubuntu.linuc.local +short
$ dig -x 10.0.10.133 +short
$ host linuc-ubuntu.linuc.local
$ nslookup linuc-ubuntu.linuc.local
$ getent hosts linuc-ubuntu.linuc.local
$ getent hosts no-such-host.example.invalid ; echo "exit: $?"

同じ名前を引いても、コマンドによって出力形式や情報量が大きく違うことを確認します。

演習3：3ファイルを読み解く

$ cat /etc/resolv.conf
$ cat /etc/hosts
$ grep ^hosts /etc/nsswitch.conf

出力から次を読み取ります。

• nameserver の IP は？ search ドメインは？
• /etc/hosts に書かれているエントリは？
• hosts: の優先順位は？ どちらが先に引かれる？

演習4：レイヤー別切り分けを実演

$ ip link show eth1               # リンク
$ ip addr show eth1               # IP
$ ip route show                   # ルート
$ dig linuc-ubuntu.linuc.local    # DNS
$ ping -c 1 -W 2 linuc-ubuntu.linuc.local    # 名前ベースで疎通
$ ss -tan | grep 10.0.10.133      # 該当 IP との接続有無

5ステップを順に実行することで、どこで「正常」か「異常」が判定できるかを確認します。実機ではすべて正常に動くはずですが、本番障害時の手順として身につけます。

理解度チェック（○×形式）

1. ping は ICMP プロトコルを使い、TCP や UDP は使わない（◯ / ✕）
2. traceroute が「* * *」を返したホップは、その先のルーターまでパケットが届いていない（◯ / ✕）
3. dig の +short オプションは結果だけを短縮表示し、スクリプトでパースしやすい（◯ / ✕）
4. /etc/nsswitch.conf の hosts: files dns 設定では、DNS の方が /etc/hosts より優先される（◯ / ✕）
5. /etc/resolv.conf は NetworkManager によって自動再生成されることがあり、手動編集は永続化されないことがある（◯ / ✕）

解答と解説

1. ◯。ICMP Echo Request / Reply を使う。クラウドのセキュリティグループで「ICMP を許可しないと ping が通らない」のはこのため。
2. △（条件付き）。「届いていない」とは限らず、そのルーターが ICMP/UDP の応答を返さない設定のことも多い。完全に届かないなら「* * *」ではなく「!H」「!N」など別のシグナルが出る。試験では「途中で応答が返らない」と覚えるとよい。
3. ◯。dig +short example.com は IP だけ返す。$(dig +short host) でシェル変数に取り込める。
4. ✕。hosts: files dns は files（/etc/hosts）が先。/etc/hosts に書かれていれば DNS は引かれない。これがヒヤリハットの典型例。
5. ◯。冒頭の # Generated by NetworkManager が手がかり。永続化は nmcli connection modify で行う。

次回予告

第5回は ユーザ・グループ管理と sudo 設定。useradd usermod userdel passwd groupadd visudo と、/etc/passwd /etc/shadow /etc/group の中身を読みます。発展として「退職者の権限剥奪」「運用ロールの分離」も扱います。

参照リソース（自分で調べる癖をつける）

• man ping man traceroute man tracepath man mtr ── 疎通・経路追跡
• man dig man host man nslookup ── DNS 問合せ
• man resolv.conf man nsswitch.conf man getent ── 設定と name service
• RFC1034 / RFC1035（DNS）／ RFC6762（mDNS）
• LinuC 公式範囲：https://linuc.org/linuc1/range/102.html 主題 1.07.3 / 1.07.4

LinuC 102 試験対策シリーズ 全12回

• 第1回：シェル環境のカスタマイズ：環境変数・エイリアス・履歴・ロケール
• 第2回：Bashスクリプト入門：if / for / 関数で書く現場の自動化スクリプト
• 第3回：ネットワーク基礎：TCP/IP・ip コマンド・NetworkManager
• 第4回：ネットワークトラブルシューティングとDNSクライアント設定（本記事）
• 第5回：ユーザ・グループ管理と sudo 設定の実務（useradd, visudo）
• 第6回：ジョブスケジューリングと時刻管理：cron, systemd timer, chrony, NTP
• 第7回：ログ管理実践：journalctl と rsyslog の使い分け
• 第8回：メール配送エージェント(MTA)の基本：postfix の動作確認
• 第9回：ファイアウォール（firewalld / ufw）と SELinux 入門
• 第10回：暗号化によるデータ保護：SSH鍵認証・GnuPG・OpenSSL
• 第11回：クラウドセキュリティの基礎：IAM・公開鍵管理・SSH踏み台構成
• 第12回：オープンソースの文化：主要ライセンス（GPL/MIT/Apache）とコミュニティ