DNS と接続性のクイズ
最終更新日: 2026 年 9 月 15 日
何を観測したかと、そこから何を推論できるかを区別するために、レッスンを使ってください。内部ラボでは、クライアントは 192.0.2.10/24、サーバーは 192.0.2.20/24 です。サーバー上では DNS サービスは動作していません。
問題
/etc/hostsはserver.netlab.testを.20に対応付けています。getent ahostsv4は成功しますが、dig @192.0.2.20はタイムアウトします。どの解釈が適切ですか？- A) すべての名前解決が壊れている
- B) ローカルの NSS 検索は機能しているが、問い合わせ先のサーバーが想定した DNS サービスを提供していない
- C) 管理用デフォルトルートを削除する必要がある
- D) hosts エントリーによってサーバー上に DNS リスナーが自動作成された
解答を表示
解答: B) ローカルの NSS 検索は機能しているが、問い合わせ先のサーバーが想定した DNS サービスを提供していない
解説: getent はシステムの名前サービスソースを使います。dig は指定したサーバーに DNS クエリを送信します。ラボでは .20 に DNS リスナーがないのは意図された状態です。タイムアウトとは制限時間内に利用可能な応答がなかったことであり、NXDOMAIN の応答ではありません。動作している hosts の対応付けを保持し、システムの DNS を .20 に向けないでください。
- Ubuntu で
dig @127.0.0.53 server.netlab.test. Aを実行すると、/etc/hostsのアドレスが返ります。何が起きましたか？- A) dig が NSS 経由で問い合わせ名を直接検索した
- B) パブリックの権威 DNS サーバーがローカルの hosts エントリーを学習した
- C) クライアントがルーターになった
- D) dig が resolved の stub に問い合わせ、その stub がローカルの hosts データを使って応答できた
解答を表示
解答: D) dig が resolved の stub に問い合わせ、その stub がローカルの hosts データを使って応答できた
解説: dig 自体は NSS 経由で名前解決しません。ただし、systemd-resolved は通常 hosts データを読み込み、その結果を DNS stub 経由で返せます。ローカル stub への問い合わせと、無関係な upstream サーバーへの問い合わせは別の実験です。このローカル動作が無効な場合は構成を確認してください。
- ある DNS 応答には
status: NXDOMAINとあり、別のクエリはタイムアウトしました。違いは何ですか？- A) NXDOMAIN は否定的な DNS 応答であり、タイムアウトは制限時間内に利用可能な応答が届かなかったことを意味する
- B) どちらも、問い合わせた名前が存在しないことを証明する
- C) NXDOMAIN はすべての IP 経路が欠落していることを証明する
- D) タイムアウトは権威サーバーがレコードを削除したことを証明する
解答を表示
解答: A) NXDOMAIN は否定的な DNS 応答であり、タイムアウトは制限時間内に利用可能な応答が届かなかったことを意味する
解説: NXDOMAIN の場合は、名前のつづり、resolver の参照先、キャッシュされた否定応答を調べてください。タイムアウトの場合は、経路、resolver への到達性、ポリシーを調べます。NXDOMAIN の応答を受信した dig は終了コード 0 を返す場合があるため、シェルの終了コードだけに頼らず、DNS の状態と回答内容を確認してください。
- レコードの TTL は 300 です。権威 DNS の TTL を下げ、resolved のローカルキャッシュを消去しました。何を結論づけられますか？
- A) すべてのクライアントが新しいレコードを即座に参照する
- B) レコードが正確に 300 台のルーターを通過できる
- C) DNS TTL はキャッシュの保持時間である。他のキャッシュには古いデータが残ることがあり、IP TTL とは無関係である
- D)
/etc/hostsも消去された
解答を表示
解答: C) DNS TTL はキャッシュの保持時間である。他のキャッシュには古いデータが残ることがあり、IP TTL とは無関係である
解説: 1 つのローカルサービスの DNS キャッシュを消去しても、アプリケーションや upstream のキャッシュは消えません。権威 DNS の TTL を変更しても、すでにキャッシュされたデータの保持時間は書き換わりません。IP TTL は転送ホップ数を制限します。単位も仕組みも、秒単位で測る DNS TTL とは異なります。
- クライアントで
ip route get 192.0.2.20を実行すると、dev LAB_NIC src 192.0.2.10が表示され、viaはありません。何が確認できましたか？- A) サーバーの HTTP アプリケーションが正常に動作している
- B) ローカルルーティングが、オンリンクの相手にラボインターフェイスと送信元アドレスを選択したこと。到達性はまだテストしていない
- C) VM 内にデフォルトルートが一つもない
- D) DNS が相手の MAC アドレスを選んだ
解答を表示
解答: B) ローカルルーティングが、オンリンクの相手にラボインターフェイスと送信元アドレスを選択したこと。到達性はまだテストしていない
解説: 経路検索はローカルで完結し、probe は送信されません。オンリンクの /24 の相手に next-hop ルーターは不要です。別の管理用デフォルトルートはそのまま維持できます。Neighbor Discovery、相手側／戻り経路の動作、アプリケーションテストは個別に確認してください。
- クライアント自身の
192.0.2.10への ping は成功しましたが、.20の隣接ノードエントリーがFAILEDになりました。最初に何を調べるべきですか？- A) ラボ NIC にパブリック DNS をインストールする
- B) 自分自身への ping を仮想ケーブルの疎通証拠とみなす
- C) 管理用のルーティングテーブルを flush する
- D) 両方の内部ネットワークへの接続、相手のアドレス、キャリア、アドレス競合の可能性
解答を表示
解答: D) 両方の内部ネットワークへの接続、相手のアドレス、キャリア、アドレス競合の可能性
解説: ローカルアドレス宛ての要求は、通常ローカルで処理されます。仮想リンクのテストではありません。隣接ノードの解決失敗は next-hop MAC を解決できなかった可能性を示すため、アプリケーションや DNS より先にリンク／アドレスの証拠を調べてください。対照的に、STALE はそれだけで対応付けの失敗を意味しません。
- traceroute には
*が表示されますが、同じサーバーへのクライアント HTTP リクエストは成功します。妥当な説明はどれですか？- A) probe に一致する応答が制限時間内に届かなかった。通常のアプリケーション通信は動作している場合がある
- B)
*のホップですべてのパケットが破棄される - C) HTTP の結果が traceroute にキャッシュされた
- D) すべての仮想スイッチが IP ホップとして表示される
解答を表示
解答: A) probe に一致する応答が制限時間内に届かなかった。通常のアプリケーション通信は動作している場合がある
解説: probe のプロトコルと制御応答のポリシーは、アプリケーションのトラフィックとは異なる場合があります。フィルタリング、応答レート制限、戻り経路によって応答が見えないことがあります。ルーターとは異なり、Ethernet スイッチは IP TTL を減らしません。* だけではアプリケーションのパケット損失は測定できません。
nc -zまたはncat -zでポート 18080 に接続できましたが、HTTP リクエストは送っていません。何が確認されましたか？- A) DNS の権威性の検証
- B) HTTP 認証とページの表示
- C) そのエンドポイントで TCP 接続が確立した
- D) HTTPS 証明書の完全な検証
解答を表示
解答: C) そのエンドポイントで TCP 接続が確立した
解説: I/O を行わない接続 probe は、目的の HTTP リクエストを送信せず、応答も検証しません。続けて curl を実行し、状態、ヘッダー、本文を確認してください。TCP 接続が成功しても、サービスが想定するプロトコルを話すとは限りません。
- サーバー自身からのリクエストは 200 を返し、リスナーは
.20:18080に bind されていますが、クライアントからの TCP リクエストはタイムアウトしました。適切な報告はどれですか？- A) エンドツーエンドの HTTP が完全に動作している
- B) ローカルサービスは動作している。リモートのルーティング、隣接ノード／戻り経路の証拠、ホストポリシーについて調査が必要
- C) クライアントが数値アドレスを使ったにもかかわらず、DNS が必ず壊れている
- D) サーバーのファイアウォールを全体的に無効にする
解答を表示
解答: B) ローカルサービスは動作している。リモートのルーティング、隣接ノード／戻り経路の証拠、ホストポリシーについて調査が必要
解説: サーバー自身へのリクエストでは、クライアントが接続できることは証明できません。ファイアウォールは候補の一つですが、タイムアウトだけで結論づけられません。第 06 章で扱う範囲を限定したポリシー設定に備え、証拠を保持してください。リモートから拒否されたテストをローカルの成功で置き換えたり、成功を強制するためにファイアウォールを回避したりしないでください。
- Curl が
/missing-pageに対して HTTP 404 を返し、終了コード 0 で終了しました。これは何を意味しますか？
- A) TCP 接続がなかった
- B) サーバー名に DNS レコードがない
- C) Curl がサーバーの応答を必ず無視した
- D) HTTP がリソース不在を返した。
--failがなければ、curl は正常終了する場合がある
解答を表示
解答: D) HTTP がリソース不在を返した。--fail がなければ、curl は正常終了する場合がある
解説: HTTP をやり取りできる程度にはトランスポートが動作していましたが、要求したリソースはありませんでした。HTTP の状態行を読み、パス／アプリケーションを調べてください。この意図的なアプリケーションレベルの失敗を直すために DNS を変更しないでください。
- 数値アドレスへの HTTP は成功し、名前を指定した HTTP は失敗しましたが、
--resolve server.netlab.test:18080:192.0.2.20を追加すると名前付きリクエストも成功しました。次に何をすべきですか？
- A) getent/NSS で通常の名前解決を調べる。この override が影響するのは、その curl の実行だけである
- B)
.20への永続経路を削除する - C) curl によってパブリック DNS zone が更新されたと考える
- D) TLS 検証をすべての接続で無効にする
解答を表示
解答: A) getent/NSS で通常の名前解決を調べる。この override が影響するのは、その curl の実行だけである
解説: override は、既知のアドレスを curl に渡しながら、リクエスト内のホスト名を保持します。hosts ファイルや DNS レコードは変更されず、ロールバックも不要です。HTTPS ではホスト名、SNI、証明書の動作も重要です。この HTTP 演習を理由に証明書検証を回避しないでください。
- 完了報告とクリーンアップについて正しい説明はどれですか？
- A) 分離されたラボの合格には、パブリック DNS が成功する必要がある
- B)
/tmpの全ファイルを削除し、hosts ファイル全体をリセットする - C) 自分が所有するサーバーを停止し、対象のファイル／ディレクトリとマークした hosts エントリーを削除し、静的なラボ用アドレスを保持する。パブリック DNS は任意とする
- D) すべての観測が一致するよう、管理用 NIC の DNS をパブリック DNS に変更する
解答を表示
解答: C) 自分が所有するサーバーを停止し、対象のファイル／ディレクトリとマークした hosts エントリーを削除し、静的なラボ用アドレスを保持する。パブリック DNS は任意とする
解説: クリーンアップでは所有範囲に従います。フォアグラウンドサーバーには 5 分の上限があり、一時ディレクトリの場所は記録済みで、hosts のブロックにはマークが付いています。無関係な変更を保持し、第 03 章のアドレスを SSH 用に残してください。パブリック DNS の問い合わせは、既存の外部接続／ポリシーに依存するため、分離された相手への経路を示す証拠にはなりません。