dig で観察する DNS と DNSSEC の入口

dig — ここまでの全部を「目で見る」道具

第 5 章までで、DNS 応答を読むための概念は揃いました。誰が答えたか（第 1〜2 章）、何が返ったか（第 3〜4 章）、いつまで有効か（第 5 章）。この章では、それを実際の応答として観察する標準ツール dig を使えるようにします。

DNS の調査で最初にやるべきは、管理画面を開くことではなく実際の問い合わせ結果を見ることです。設定した「つもり」と、世界に返っている「現実」は、キャッシュや委任ミスでしばしば食い違うからです。dig の使い方で大事なのはオプションの暗記ではなく、出力の 4 つのセクションが何を表すかを知っていることです。

$ dig www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31201
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.        IN      A

;; ANSWER SECTION:
www.example.com.  300    IN      A       203.0.113.10

覚えておくと便利な形を 2 つだけ: dig @8.8.8.8 www.example.com A のように @ で問い合わせ先を指定できます。再帰リゾルバに向ければ「このリゾルバのキャッシュには何が入っているか」、権威サーバに向ければ「権威はいま何を配っているか」を確かめる形です。リゾルバ相手に数秒おきに 2 回引いて TTL の数字が減っていれば、その答えはキャッシュ — 第 5 章の理屈を目で確認できます。結果の値だけ欲しいときは +short が便利です。

+trace — フルミスの旅を再演する

dig +trace は、再帰リゾルバのキャッシュに頼らず root から委任を辿り直します。第 3 章のシミュレータで見たフルミス経路を、実物の DNS で再演するオプションだと考えてください。

$ dig +trace www.example.com A
.               518400  IN  NS  a.root-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
example.com.      900   IN  NS  ns1.example.com.
www.example.com.  300   IN  A   203.0.113.10

各行は「どのゾーンが、誰に案内したか」の記録です。途中に古い NS や身に覚えのない委任先が現れたら、レコードの中身より先に委任の境界（zone cut）を疑います。「キャッシュ越しの眺め（普通の dig）」と「権威直行の眺め（+trace）」を見比べられることが、調査での大きな武器になります。

dig で見えるのは DNS 層だけ

「レコードを直したのに、サイトの表示が変わらない」— このとき DNS 層の外側も疑う必要があります。名前解決の先には、HTTP のレスポンスキャッシュ、CDN の edge cache、TLS のセッションと証明書、とそれぞれ独立した寿命を持つ層が積み重なっているからです。

• DNS 層 — 名前 → 値の解決結果。寿命は TTL。dig で観察できるのはここだけ。
• HTTP / CDN 層 — コンテンツそのもののキャッシュ。寿命は Cache-Control や CDN の設定で決まる。
• TLS 層 — 証明書の有効期限やセッション再利用。DNS とは無関係に振る舞う。

切り分けの手順は単純です。まず dig で DNS が新しい値を返しているかを確認する。このとき 1 つだけ注意 — 影響を受けている利用者と同じ経路で確認することです。ブラウザの DoH 設定や OS のキャッシュ、別ホストからの dig では、利用者と違うリゾルバの答えを見ている可能性があります。@ でその利用者が使うリゾルバを指定して引くのが確実です。同じ経路で新しい値が返っていれば原因は DNS より上の層、返っていなければ第 5 章の TTL 計算と委任の確認に戻る。この一手で、調査の半分が終わります。

DNSSEC — 何を守り、何を守らないか

最後に、dig の出力にしばしば顔を出す DNSSEC を「守備範囲の理解」に絞って押さえます。DNSSEC は DNS データに電子署名を付け、受け取った側が「この RRset は本当にそのゾーンの管理者が出したもので、途中で改ざんされていないか」を検証できるようにする仕組みです。

登場する型は最低限、次の 3 つで足ります。

dig +dnssec を付けると、署名付きの応答を要求できます。

$ dig +dnssec www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41203
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:
;www.example.com.        IN      A

;; ANSWER SECTION:
www.example.com.  300    IN      A       203.0.113.10
www.example.com.  300    IN      RRSIG   A 13 3 300 20260601000000 (
                                         20260501000000 12345 example.com.
                                         abcDEF... )

注目するのは 3 点です。

• flags: ... ad — Authenticated Data。問い合わせた再帰リゾルバが署名検証に成功した印。
• flags: do（OPT 内） — DNSSEC OK。クライアントが署名付き応答を要求した印。
• RRSIG 行 — 直前の RRset（ここでは A）への署名。アルゴリズム（13 = ECDSA P-256）、署名の有効期間、鍵 ID（12345）が読み取れます。署名には有効期限があるため、更新運用が止まると期限切れで解決不能になる — DNSSEC 特有の障害はたいていこれです。

この章で持ち帰ること

• 調査は管理画面より先に dig で「現実に何が返っているか」を見る。読む場所は status / ANSWER / AUTHORITY / ADDITIONAL
• +trace はフルミス経路の再演。委任の事故は普通の dig ではなく +trace で見つかる
• dig で見えるのは DNS 層だけ。HTTP / CDN / TLS のキャッシュは別に切り分ける
• DNSSEC は署名による検証（起源認証・完全性）であって、暗号化による秘匿ではない

道具はすべて揃いました。最終章では、実際の障害を模したケース問題で総仕上げをします。