2.4クライアント側のDNS設定

前節で「名前解決が怪しい」と切り分けたら、次はクライアント側の設定3点セット——どの順で引くか（nsswitch.conf）・静的対応（hosts）・どの DNS サーバーに聞くか（resolv.conf）——を確認します。この3ファイルの役割分担が本節の核心です。

2.4.1設定ファイル3点セット

• /etc/resolv.conf＝問い合わせ先 DNS サーバーの指定（nameserver 8.8.8.8・最大3つ・上から順に試行）。search example.com はドメイン補完（ホスト名だけで引いたとき補うサフィックス）。
• /etc/hosts＝静的な対応表。通例 DNS より先に引かれる（順序は nsswitch.conf 次第）。
• /etc/nsswitch.conf＝hosts: files dns の行が参照順序を決める（files＝/etc/hosts）。順序を入れ替えれば DNS 優先にもできる。

2.4.2確認コマンドの使い分け

• host＝簡潔な正引き/逆引き（host www.example.com／host 192.0.2.1）。host 名前 8.8.8.8 のように問い合わせ先サーバーを指定できる。
• dig＝詳細表示（QUESTION/ANSWER セクション・TTL・応答コード）。dig @8.8.8.8 example.com MX のようにサーバー指定は @・レコード種別も指定可。
• getent＝getent hosts 名前 で nsswitch.conf の順序どおりに引いた結果を表示＝「実際にアプリが見る答え」。host/dig は DNS だけに聞く（/etc/hosts を見ない）点が対照。

3ファイル＋3コマンドの関係を1つの物語にしましょう。アプリケーション（ブラウザや ssh）が名前を引くときは、nsswitch.conf の順序に従い、まず /etc/hosts を見て、無ければ resolv.conf の nameserver に UDP/53 で問い合わせます。だから「テスト用に hosts へ 192.0.2.10 www.example.com を書いた」場合、ブラウザ（と getent）はテストサーバーへ向かいますが、dig は DNS に直接聞くので本番の IP を返し続けます——両者の答えの食い違いこそが「hosts が効いている」証拠です。逆に「hosts に書いても無視される」なら nsswitch.conf の順序が dns 先行になっていないかを疑います。search example.com は ssh web01 のような短い名前を web01.example.com に補完する仕組みで、複数書けば順に試されます。クラウドや DHCP 環境では resolv.conf が自動生成・上書きされることが多い（手編集が消える）という運用注意も、トラブルの定番原因として覚えておきましょう。

2.4.3この節のまとめ

• 役割分担＝nsswitch.conf（順序）・hosts（静的）・resolv.conf（nameserver/search）
• 確認は getent hosts（実際の答え）／host・dig（DNS 直接・@ でサーバー指定）