1.07.3標準
app.example.testの名前解決について、ルートDNSから委任を順にたどり、どの段階で問題が起きるか調査する。
digを使用する。
適切なコマンドはどれか。
× 不正解
dig +traceはルートDNSから反復的に委任をたどり、権威サーバーへ至る過程を表示する。通常の再帰リゾルバー問い合わせとは異なる。
詳細解説
誤り
dig app.example.test +short回答値を短く表示するが、委任経路を順番にたどらない。
+shortは最終的な回答値を簡潔に確認する用途である。どの委任段階で問題が起きたかは表示しない。
誤り
dig app.example.test +tcpTCPを強制するが、ルートから委任を追跡しない。
+tcpはUDPではなくTCP 53を使う。トランスポートの切り分けにはなるが、委任経路を追跡しない。
誤り
dig app.example.test +noall +answer回答節だけを表示する指定で、委任過程を調べない。
+noall +answerは回答節だけに出力を絞る。途中の委任や権威サーバーを調べる情報は減る。
正しい
dig app.example.test +traceルート側から反復問い合わせを行い、委任の経路を表示する。
+traceはルートからNS委任を反復的にたどるため、名前空間のどの段階で応答が崩れるかを調査できる。
実際に確かめる
一時的な検証環境で実行できる例です。
dig -h 2>&1 | sed -n '1,8p'期待される結果
digの使用方法理解のポイント
- +traceは委任追跡
- ルートから反復問い合わせ
- 通常の再帰問い合わせと区別
確認時の注意
- 確認環境: BIND dig help / 外部問い合わせなし
- +traceは実際には複数DNSサーバーへ問い合わせるため、検証ではhelpだけを確認する。
基礎のおさらい
再帰と反復
通常のクライアントは再帰リゾルバーへ最終回答を求めるが、traceでは委任先を順番に問い合わせる。
委任障害
親側NS、glue、権威サーバーの応答などを段階ごとに確認できる。
問題IDKL-102-992
確認環境BIND dig help / 外部問い合わせなし
最終技術確認2026-08-13
誤り・権利侵害を報告