dig で読む DNS と DNSSEC の入口
dig の主要セクションと DNSSEC の守備範囲を押さえ、調査の入口を揃える。
dig は『いま誰が何を返しているか』を観察する道具
第 4・5 章ではレコード型と TTL の理屈を見てきました。本章ではそれを 実際の応答として観察する手段 として dig を使い、最後に DNSSEC の守備範囲だけを押さえます。
DNS の障害調査で役立つのは、レコード管理画面よりも先に、実際の問い合わせ結果を見ることです。dig はそのための基本ツールです。大事なのはオプションを大量に覚えることではなく、Question / Answer / Authority / Additional の各セクションが何を表すかを把握することです。
$ 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
| 見る場所 | 意味 | 最初に見る観点 |
|---|---|---|
| status | NOERROR / NXDOMAIN などの結果 | 名前自体がないのか、型だけないのか |
| ANSWER | 最終 RRset | 期待する名前と型が本当にあるか |
| AUTHORITY | NS や SOA などの補助情報 | referral なのか、否定応答なのか |
| ADDITIONAL | glue や補助アドレス | 次へ進むための足がかりが入っているか |
小問 6-1 — dig の最小限を読む
どこを見れば最終 RRset やステータスが分かるかを押さえます。
Q30. dig の出力で、最終的な RRset が最も直接載る場所はどこですか。
ANSWER セクションには、最終的に得られた RRset が載ります。AUTHORITY は NS や SOA など補助情報、ADDITIONAL は補助アドレスなどです。
Q32. dig の status: NXDOMAIN が最も直接意味するものはどれですか。
NXDOMAIN は、その QNAME 自体が存在しないことを表す代表的な否定応答です。『名前はあるが特定の型がない』場合とは別です。
+trace は『どこで曲がるか』を見る
dig +trace は root から順に辿った結果を見せてくれます。委任の途中でおかしな NS が見えたら、レコードの中身より前に 委任の境界 を疑えます。
$ 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
小問 6-2 — trace が教えてくれるもの
どこで referral を受けたかを辿れると、委任ミスに気づきやすくなります。
Q31. dig +trace を使う主な目的として最も近いものはどれですか。
dig +trace は root から順に問い合わせを辿るので、委任の途中でおかしな NS や曲がり方がないかを確認するのに向いています。
DNS のキャッシュは『DNS 層だけ』の話
第 5 章で見た TTL は、再帰リゾルバが名前解決結果を保持する時間でした。一方で、ブラウザの HTTP レスポンスキャッシュ、CDN の edge cache、TLS セッション、TLS 証明書の有効期限など、近くにあるが別層のキャッシュ が混在しています。dig で見えているのは DNS 層だけだ、という前提を最初に置いておくと、調査でぶつかる『直したのに直らない』の切り分けが速くなります。
小問 6-3 — DNS の TTL と他の層のキャッシュを切り分ける
DNS のキャッシュと、HTTP / CDN のキャッシュは別物であることを確認します。
Q29. DNS の TTL と、ブラウザの HTTP キャッシュや CDN の TTL の関係として正しいものはどれですか。
DNS の TTL は再帰リゾルバなどが名前解決結果をどれだけ保持するかの話で、HTTP レスポンスや CDN edge cache の寿命とは別です。dig で観察対象にできるのは DNS 層の TTL のみで、HTTP の Cache-Control や CDN edge の挙動はそれぞれ別ツールで切り分けます。
DNSSEC は何を守り、何を守らないか
DNSSEC は DNS データに署名を付け、検証側がその署名を辿れるようにする仕組みです。直感的には、『この RRset は本当にそのゾーンの持ち主が出したもので、途中で改ざんされていないか』 を確かめるためのものです。
最低限の用語だけ覚えるなら次の 3 つです。
dig +dnssec をつけると、応答に RRSIG や 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。クライアントが DNSSEC 対応応答を要求している印。RRSIG行 — 直前の RRset（ここでは A）に対する署名そのもの。鍵 ID（12345）、署名アルゴリズム（13= ECDSA P-256）、署名期限（20260601000000）などが並びます。
関連する dig DNSKEY や dig DS でも、それぞれゾーンの公開鍵や親ゾーンが持つ鍵参照を直接観察できます。
小問 6-4 — DNSSEC の守備範囲を誤解しない
『署名による検証』であって『秘匿化』ではないことを確認します。
Q33. DNSSEC が提供するものにあてはまらないものはどれですか。
DNSSEC はデータ起源認証・完全性検証・改ざん検知を提供しますが、問い合わせ内容や応答の秘匿そのものは提供しません。秘匿は DoT / DoH など別の仕組みの担当です。
Q34. DS レコードの役割として最も近いものはどれですか。
DS は親ゾーン側に置かれ、子ゾーンの DNSKEY と結びついて、署名検証チェーンを下のゾーンへつなぐ役割を持ちます。
この章で持ち帰ること
- dig は 『実際に何が返ってきているか』 を観察する第一歩
+traceは 委任の境界や経路の異常 を掴みやすい- DNSSEC は 改ざん検知とデータ起源認証 の仕組みであり、暗号化とは別