DNS の比較確認で大切なのは、「何と何を比べるか」を先に決め、比べる必要のない違いを結果から取り除いておくことです。doggo は1回のコマンドで複数の問い合わせ先に聞けるうえ、--json で結果を機械的に扱える形にできるので、この2つを組み合わせると比較の作業を短く正確にできます。この記事では、サーバー移転やレコードの整理を例に、変更前の控えを JSON から作って変更後との差分を取る手順と、複数のキャッシュサーバーや通信方式の答えを並べて比べる手順を説明します。
doggo の導入や基本の問い合わせ方、TTL と NS の一括確認は同じシリーズの別の記事で扱っているため、ここでは比較の進め方に絞ります。
比べる組み合わせを決める
DNS の比較には、大きく3つの組み合わせがあります。
- 変更前と変更後：意図した変更だけが起き、意図しない変更が混ざっていないかを確かめます。サーバー移転やレコードの整理で使います。
- 権威サーバーとキャッシュサーバー：設定した値が各地のキャッシュに届いたかを確かめます。
- キャッシュサーバー同士、通信方式同士：特定の公開 DNS や、暗号化 DNS の経路だけで違う答えになっていないかを確かめます。
WordPress サイトの場合、比べる対象の名前と種別は、多くの場合次のあたりになります。ドメインそのものと www の A と AAAA、MX、SPF などを含むドメインの TXT、_dmarc の TXT、CAA です。サイトで使っている CDN やメール配信サービスの名前があれば加えます。
手順1：比べる名前の一覧を作る
比べる名前と種別を、1行に1組ずつテキストファイルに書きます。変更前と変更後で同じ一覧を使うことが、比較を正しく行う前提です。
# names.txt（名前 種別）
example.com A
example.com AAAA
www.example.com A
www.example.com AAAA
example.com MX
example.com TXT
_dmarc.example.com TXT
example.com CAA手順2：変更前の控えを JSON から作る
権威サーバーに問い合わせて、名前・種別・値の3つだけを取り出した一覧を作ります。TTL を含めないのが要点です。キャッシュサーバーの TTL は時間とともに減っていくので、含めると値が同じでも毎回違いとして表示されてしまいます。
#!/usr/bin/env bash
# 使い方: ./snapshot.sh names.txt @192.0.2.53 > before.tsv
set -u
list="$1"
server="$2"
while read -r name type; do
[ -z "${name:-}" ] && continue
case "$name" in \#*) continue ;; esac
doggo "$name" "$type" "$server" --json --color=false \
| jq -r '.. | objects | select(has("address")) | [.name, .type, .address] | @tsv'
done < "$list" | sort -u@192.0.2.53 には、権威サーバーの IP アドレスを入れます。ネームサーバー名から IP アドレスを調べるには doggo ns1.example.net A --short を使います。JSON の入れ子の形は版や問い合わせ先の数で変わることがあるため、jq では .. で全体をたどり、address を持つ項目だけを選んでいます。版を上げたときは、一度 doggo example.com A --json | jq . で構造を確かめてください（2026年10月現在）。答えが空の名前では、応答の AUTHORITY にあたる部分の SOA が拾われることがあり、その場合はゾーンを編集するたびに上がるシリアル番号の行が差分に出ます。この行は「答えが無い名前がある」という印として読みます。
sort -u で並べ替えているのは、複数の A レコードなど、答えの順番が問い合わせごとに変わる場合があるためです。順番の違いは不具合ではないので、比較の前に取り除いておきます。
手順3：変更後に差分を取る
DNS の変更を終えたら、同じ一覧と同じ権威サーバーで控えを作り直し、diff で比べます。
./snapshot.sh names.txt @192.0.2.53 > after.tsv
diff before.tsv after.tsv< で始まる行は変更前にだけあった値、> で始まる行は変更後にだけある値です。サーバー移転で A を変えたなら、旧アドレスの < と新アドレスの > が1組だけ出るのが期待どおりの結果です。それ以外の行が出た場合、たとえば MX や TXT の行が消えているなら、移転作業の途中で意図しない削除や書き換えが起きています。事業者を移した場合は、旧事業者の権威サーバーで作った控えと、新事業者の権威サーバーで作った控えを比べれば、移し忘れを見つけられます。
差分が何も出ないのに変更したはずの値がある場合は、編集したゾーンと問い合わせた権威サーバーが一致しているかを確かめます。
手順4：複数のキャッシュサーバーの答えを並べる
権威サーバーの値が正しいと分かったら、キャッシュサーバーへの広がりを見ます。doggo は @ の付いた問い合わせ先を複数並べられ、表の NAMESERVER の列でどのサーバーの答えかが分かります。
doggo www.example.com A @1.1.1.1 @8.8.8.8 @9.9.9.9 --strategy=all複数の問い合わせ先にすべて聞くか、一部だけに聞くかは --strategy で決まります。比べるときは all を指定して、すべての答えが並ぶようにします。
並べた結果を残したいときは、JSON から問い合わせ先・値・TTL を取り出します。ここでは TTL を含めて、各キャッシュサーバーで古い値があとどれくらい残るかを読みます。
doggo www.example.com A @1.1.1.1 @8.8.8.8 @9.9.9.9 --strategy=all --json \
| jq -r '.. | objects | select(has("address")) | [.nameserver, .address, .ttl] | @tsv'JSON の TTL は 300s のように末尾に s の付いた文字列です。数値として比べる場合は、jq の sub("s$"; "") などで s を取り除いてから扱います。
手順5：通信方式ごとの答えを比べる
同じ公開 DNS でも、通常の UDP、TCP、暗号化 DNS（DoH・DoT）で違う答えが返ることがあります。社内のネットワークやセキュリティ製品が、特定の経路の DNS だけを書き換えている場合です。
doggo www.example.com A @1.1.1.1 @tcp://1.1.1.1 @tls://1.1.1.1 @https://cloudflare-dns.com/dns-query --strategy=all暗号化 DNS だけ正しい値が返り、通常の UDP で別の値が返るなら、経路の途中で DNS が書き換えられている可能性があります。逆に暗号化 DNS だけ失敗する場合は、その通信が遮断されていることが考えられます。
違いが出たときの読み方
比較で出た違いのうち、次のものは不具合ではありません。
- キャッシュサーバーごとの TTL の違い（残り時間が違うだけです）
- 複数の A レコードの並び順
- CDN を使った名前で、問い合わせ先によって近い拠点のアドレスが返ること
一方、次の違いは原因を調べる必要があります。
- 権威サーバー同士で値が違う（ゾーンの同期の遅れや停止）
- 変更していない種別の行が差分に出る（意図しない削除や書き換え）
- TTL を過ぎても一部のキャッシュサーバーが古い値を返す（そのサーバーの問題や、別の権威サーバーの古い値）
使うときの注意
公開 DNS に短い間隔で大量の問い合わせを送ると、制限を受けることがあります。一覧の名前が多いときは、ループの中に sleep を入れて間隔を空けてください。また、変更前の控えは、作業の前に取らないと意味がありません。DNS を変える作業の手順書に、控えを作る手順を最初の段階として入れておくと、作業後の確認と元に戻す作業が楽になります。
まとめ
- 比べる組み合わせ（変更の前後、権威とキャッシュ、キャッシュ同士や通信方式同士）を先に決めます。
- 変更前後の比較は、同じ名前の一覧と同じ権威サーバーで、TTL を除いて並べ替えた控えを作り、
diffで差分を取ります。 - キャッシュサーバー同士の比較は、複数の
@と--strategy=allで並べ、TTL で古い値の残り時間を読みます。 - TTL の違いや並び順、CDN の地域差は不具合ではありません。権威サーバー同士の違いや意図しない差分を優先して調べます。