観測と運用 — dig / ログ / 典型的な誤診
まず実際の応答を見て、negative caching / split-horizon / browser cache などの誤診を先に外す。
前章のおさらい: 第 5 章では DNSSEC の守備範囲と last hop 問題、そして多層防御の組み立てを整理しました。本章ではその防御を「動作中の resolver で何を観測すれば崩れに気づけるか」に展開します。dig の基本操作（DNS101 で扱った範囲）はあくまで土台で、ログから poisoning 兆候を拾うパターンまで踏み込みます。
管理画面より先に、実際の応答を見る
名前解決トラブルでは、レコード管理画面のスクリーンショットより先に、「affected resolver がいま何を返しているか」「authoritative path ではどう見えるか」を比べるのが近道です。
$ dig @192.0.2.53 www.example.com A
$ dig +trace www.example.com A
$ dig +dnssec www.example.com A
ここでの 192.0.2.53 は例示用の TEST-NET アドレスです。実際の確認では、自分が管理する resolver や正当な観測対象だけを使います。
小問 6-1 — 最初の切り分け
管理画面の印象より先に、実際の応答を比較します。
Q1. 利用者から「ある名前だけ変な IP へ飛ぶ」と報告されたとき、最初の安全な確認として妥当なものはどれですか。
妥当な最初の確認は、影響を受けた recursive resolver の回答と、authoritative path / +trace の見え方を比較することです。管理画面の印象だけで判断せず、実際の応答を見ます。
Q2. dig +trace が向いている目的として最も近いものはどれですか。
dig +trace は delegation path を root から順に見て、どこで曲がるかを確かめるのに向いています。委任境界の観察や NS の曲がり方確認に役立ちます。
Q3. 次のうち、browser 個別のキャッシュより shared recursive cache の問題を疑いやすい状況はどれですか。
同じ resolver を使う複数利用者で、同じ誤答と似た残り TTL が見えるなら、browser 個別というより shared recursive cache 側の問題を疑いやすいです。
よくある見え方の切り分け
| 見え方 | まず疑うもの | 最初の確認 |
|---|---|---|
| 同じ resolver を使う複数利用者が同じ誤答 | shared recursive cache | 影響 resolver と authoritative path の比較 |
| internal だけ別 IP | split-horizon / 内部向け設計 | 設計意図と internal zone の有無 |
| 作ったばかりの名前がまだ NXDOMAIN | negative caching | 否定応答の TTL |
| RRSIG / AD が絡む異常 | DNSSEC validation / last hop | dig +dnssec と trust chain |
negative caching と誤診
「さっき作った名前がまだない」「internal と external で違う」などは、poisoning と紛らわしい典型例です。negative caching と split-horizon を先に除外すると、不要な誤検知を減らせます。
ヒント: negative caching の TTL は SOA の minimum field と RFC 2308 で説明される挙動で決まります。存在しない結果にも寿命があることを忘れないでください。
小問 6-2 — negative caching と誤診
poisoning と紛らわしい典型例を先に外します。
Q4. 13:00:00 に NXDOMAIN が 300 秒で negative cache されました。13:01:00 にその名前のレコードを作成したのに、13:02:00 でもまだ NXDOMAIN です。最も近い説明はどれですか。
negative caching の TTL が残っているためです。レコードを作成しても、resolver 側で NXDOMAIN の寿命が切れるまでは直ちに見え方が変わらないことがあります。
Q5. 次のうち cache poisoning より split-horizon / 内部向け設計を疑う手がかりとして最も近いものはどれですか。
社内 resolver だけが内部 IP を返し、public authoritative 側は意図どおり別の答えを返しているなら、split-horizon / 内部向け設計をまず疑います。異常と断定する前に設計意図を確認します。
ログから異常を拾うパターン
dig での個別確認に加えて、resolver / クエリログを定常的に見ておくと、「いま何かが起きている」「過去に何かが起きた」を早く拾えます。中級コースの観測としては、次の 3 つのパターンを覚えておくと現場で役立ちます。
小問 6-3 — ログから異常を拾うパターン
中級として一歩踏み込み、resolver / クエリログから poisoning 兆候を拾う観点を確認します。
Q6. ある zone に対して、見覚えのない大量のサブドメインへの query が短時間に集中し、しかもそれぞれ NXDOMAIN を返しています。cache poisoning 観点で最も妥当な仮説はどれですか。
ランダム風の存在しないラベルへの query 集中は、attempts を稼ぐために fresh miss を意図的に発生させる挙動と整合します。同じ zone に対する NXDOMAIN 率の急増、querier IP の偏り、時間帯の集中も合わせて見ると判断しやすくなります。
Q7. validating resolver のログで「同一 zone に対する RRSIG 検証 failure」が短時間に連続しています。最初に切り分けるべき仮説の組み合わせとして最も適切なのはどれですか。
RRSIG 検証 failure は (1) zone 運用側の問題（鍵ロール・署名期限切れ）、(2) 経路上での応答改ざん／誤受理、(3) 検証側の時刻ずれ、のいずれでも起きます。まずこの 3 軸で切り分け、自前の clock と zone の運用状況を確認した上で、残りを poisoning や中間者の疑いとして追います。
この章で持ち帰ること
- まず affected resolver と authoritative path を比べる
+traceは delegation path の観察に向く- negative caching、split-horizon、browser cache などの誤診要因を先に外す
- ログでは「random label 集中」「RRSIG 検証 failure 連続」「port 分布の縮退」を継続観測する