DNS 操作マニュアル

問い合わせ失敗、応答差、変更が見えない現象を分ける。名前・型・server・時刻を記録し、権威・再帰・システム解決を比較する。例の domain は変更対象ではない。

やりたいこと	参照先
名前解決失敗	応答を読む
変更後も旧 IP	権威と cache
DNSSEC・暗号化 DNS	検証の境界

診断中は status を省かない

最初に応答全体を読む

# 設定された DNS に問い合わせ、ヘッダーも読む
dig example.com A

status・flags・ANSWER・AUTHORITY・SERVER・時間を記録する。例の TTL 300 は秒で、SERVER が問い合わせ先を示す。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
www.example.com. 300 IN A 192.0.2.10
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)

# 指定した再帰 DNS に同じ名前と型を問い合わせる
dig @1.1.1.1 example.com A +noall +comments +answer +authority +stats

@ はサーバー指定。表示オプションは状態・回答・authority・統計を残すためで、レコードは変更しない。

目的に合うレコード型を選ぶ

# IPv6 アドレスレコードを読む
dig example.com AAAA

IPv4 のみ通る場合、AAAA と IPv6 経路を調べる。AAAA なしでも名前自体がないとは限らない。

# MX と優先度を読む
dig example.com MX

通常、数値が小さいほど優先される。交換器名のアドレスは別に調べる。TXT/CAA/CNAME も明示し、ANY を全件取得と考えない。

# アドレスから逆引き名を作り PTR を問い合わせる
dig -x 192.0.2.10

実 IP に置き換える。PTR と A/AAAA は別管理で、一方だけでは他方の設定を証明できない。

アプリの名前解決経路も確認する

# Linux NSS 経由の結果を取得する
getent ahosts example.com

hosts・DNS・他の NSS モジュールからの可能性がある。dig と違えば来源を調べる。独自 DNS や DoH を使うアプリもある。

# systemd-resolved の結果と選択リンクを確認する
resolvectl query example.com

resolved を使わない環境では不要。resolvectl status でリンク別サーバーと routing domain を見る。

応答	意味と次の確認
NOERROR + answer	応答あり。CNAME・型・TTL・SERVER を確認
NOERROR + empty answer	型の NODATA や referral 等。authority を見る
NXDOMAIN	その view で名前不存在。negative cache を確認
SERVFAIL	解決処理失敗。DNSSEC・権威への到達等を調べる
timeout	応答が時間内にない。経路・UDP/TCP53・server を確認

dig は DNS、getent は hosts 等を含む NSS、resolvectl は systemd-resolved。経路が違う。+short は状態確認後の抽出向け。ANY は全記録の列挙を保証せず必要な型を指定する。

TTL は各 cache 項目の期限

図を準備しています

権威 DNS を確認してからキャッシュを比較する

# 対象 zone の権威サーバー候補を探す
dig example.com NS

子 domain の委任も確認する。親の NS がすべての子を担当するとは限らない。

# 確認した権威サーバーへ非再帰問い合わせする
dig @ns1.example.com www.example.com A +norecurse

サーバー名を置き換え、aa と SOA/委任を確認する。aa がなければ zone を見直す。複数権威を比較して反映差を調べる。

# 再帰 DNS の回答と残り TTL を比較する
dig @1.1.1.1 www.example.com A

問い合わせ時刻を記録する。権威更新後も旧回答なら旧 TTL 待ちの可能性がある。負のキャッシュも新規レコードの可視性を遅らせる。

# 委任をたどり zone 間の問題箇所を探す
dig +trace www.example.com A

各階層 DNS への直接アクセスが必要。企業の転送・分割 DNS・再帰キャッシュは再現しない。

ローカルキャッシュが原因と判断してから消す

# このホストの systemd-resolved キャッシュを消す
sudo resolvectl flush-caches

任意の修復で、問い合わせ前に毎回実行するものではない。再問い合わせと実アプリを確認する。他のキャッシュは残る。

権威 server を置き換え AA・委任・zone を確認する。+trace は再帰器の cache・forwarder・split view を再現しない。応答差は地理・view・cache 等でも起こる。TTL を下げても既存 cache の期限は短くならず、負応答も cache される。

record の識別を保存して各層を検証

cloud 変更前に zone/record ID・名前・型・値・TTL・経路方針を保存する。record ID で更新し意図せぬ追加を避ける。Alibaba UpdateDomainRecord は RR・Type・Value が必要。無関係な TXT を残し、権威→再帰器→アプリで確認する。

resolvectl flush-caches はローカル resolved だけで、ISP・browser・container・外部再帰器の cache は消さない。ACME DNS-01 は委任・TXT 名と値も確認する。証明書参照。

暗号化転送と DNSSEC 検証を分ける

DNSSEC データの要求と検証を区別する

# DO を設定し関連 DNSSEC データを要求する
dig @1.1.1.1 example.com A +dnssec

RRSIG などと ad フラグを読む。dig 自体による信頼連鎖の検証ではない。

# ローカル検証器で DNSSEC を確認する
delv example.com A

validated・unsigned・validation failure を区別する。時刻・信頼アンカー・ネットワークを確認する。未署名と署名不正は別。

転送方式を比べる際は問い合わせを揃える

# 同じ問い合わせを TCP 53 で比較する
dig @1.1.1.1 example.com A +tcp

UDP のみ失敗するならフィルター・断片化・経路を調べる。TCP DNS は暗号化ではない。

# DoT で問い合わせ、CA とサーバー名を検証する
kdig @1.1.1.1 example.com A +tls +tls-ca +tls-hostname=cloudflare-dns.com

+tls は TLS、+tls-ca は信頼検証、+tls-hostname は期待する名前。失敗時はポート・時刻・証明書を調べ、検証を切らない。対応方式は提供元で確認する。

kdig は TLS 対応の Knot tools と対応 endpoint が必要。+dnssec は要求で dig 自体の検証ではない。AD は再帰器の主張で信頼できる経路が前提。delv は trust anchor と正しい時計で検証する。暗号化転送と zone の署名は別。

BIND dig/delv · DNS negative caching RFC 2308 · Alibaba UpdateDomainRecord · Cloudflare DoT