kdig で DNS の応答を比較するときは、比べたい条件を1つだけ変え、それ以外（名前・種別・問い合わせ先・表示のオプション）を揃えて2回以上問い合わせるのが基本です。kdig は UDP・TCP・DNS over TLS（DoT）・DNS over HTTPS（DoH）を同じ書式で切り替えられ、応答したサーバーの識別子（NSID）や DNSSEC の情報も表示できるため、「通信方式による違い」「権威サーバーの拠点による違い」「DNSSEC の検証の有無による違い」を比べるのに向いています。この記事では、その3つの比較と、変更の前後で結果を保存して差分を取る方法を説明します。
レコードの中身を旧 DNS と新 DNS で突き合わせる作業は、出力が1行ずつの文になる host コマンドのほうが手軽なので、別の記事で扱っています。ここでは kdig ならではの比較に絞ります。
比較の前に揃えること
比較で迷う原因の多くは、条件が揃っていないことです。最初に次の点を決めておきます。
- 問い合わせ先：
@で明示します。省くと/etc/resolv.confのサーバーに聞くため、端末ごとに答えが変わります。 - 表示の範囲：
+noall +answerで回答セクションだけにすると、比べる行が減って読みやすくなります。 - TTL の表示：キャッシュサーバーの TTL は問い合わせのたびに減るので、値だけを比べたいときは TTL の表示を外すと差分が見やすくなります（kdig のオプション名は手元の
man kdigで確認してください）。
kdig のオプションは版によって追加や変更があります。この記事のオプションは執筆時点（2026年10月現在）のマニュアルを基準にしています。まず kdig -V で版を確認してください。
比較1：通信方式を変えて同じ問い合わせをする
同じサーバーに、通信方式だけを変えて問い合わせます。ネットワークの途中で特定の通信が遮断されていないか、暗号化 DNS のサーバーが通常の DNS と同じ答えを返しているかを確かめられます。
# UDP（既定）
kdig @1.1.1.1 example.com A +noall +answer
# TCP
kdig @1.1.1.1 example.com A +noall +answer +tcp
# DNS over TLS（853番ポート）。システムの CA で証明書を検証する
kdig @1.1.1.1 example.com A +noall +answer +tls-ca +tls-hostname=cloudflare-dns.com
# DNS over HTTPS
kdig @1.1.1.1 example.com A +noall +answer +https+noall +answer を外すと、出力の末尾にどのサーバーへどの方式で問い合わせたかが表示されます。比べる前に一度外して実行し、本当に TCP や TLS で通信したかを確認しておくと安心です。
結果の読み方は次のとおりです。
- すべて同じ答え：通信方式による違いはありません。
- UDP は成功し、TCP だけ失敗する：ファイアウォールで TCP の 53 番ポートが塞がれている可能性があります。大きな応答は TCP で受け取るため、DNSSEC の署名付きの応答や長い TXT の取得に影響します。
- 通常の DNS は成功し、TLS だけ失敗する：853 番ポートが経路で遮断されているか、証明書の検証に失敗しています。
-dを付けるとデバッグ用の情報が表示され、証明書の名前などを確認できる場合があります。 - 方式によって答えが違う：暗号化 DNS の問い合わせ先が、実際には別のリゾルバーにつながっている可能性があります。社内のフィルタリングや、端末のセキュリティソフトが DNS を書き換えている場合にも起こります。
比較2：権威サーバーやその拠点ごとの答えを比べる
ゾーンを複数の権威サーバーで運用している場合、1台だけ古い内容を返していると、利用者によって答えがばらつきます。権威サーバーを1台ずつ指定し、再帰を要求しない問い合わせで比べます。
for ns in ns1.example.net ns2.example.net; do
echo "== $ns"
kdig @"$ns" example.com SOA +norecurse +noall +answer
kdig @"$ns" www.example.com A +norecurse +noall +answer
doneSOA のシリアル番号がサーバーごとに違えば、ゾーン転送の遅れを疑います。ただし、マネージド DNS の中にはシリアル番号を独自の規則で付けるサービスもあるため、気になるレコードの値も合わせて比べてください。
多くのマネージド DNS は、同じ IP アドレスで世界の複数拠点から応答する anycast という仕組みを使っています。この場合、同じサーバー名に聞いても、問い合わせ元によって別の拠点が答えます。+nsid を付けると、相手が対応していれば応答した拠点の識別子が表示されます。
kdig @ns1.example.net www.example.com A +norecurse +nsidある地域の利用者だけ古い答えが返るときに、拠点の識別子を控えて事業者のサポートに伝えると、調査が進みやすくなります。識別子の形式は事業者ごとに違い、対応していない事業者もあります。
比較3：DNSSEC の検証の有無で比べる
DNSSEC を導入したドメインで、一部の利用者だけ名前解決に失敗する場合は、検証するリゾルバーに、検証ありとなしの2通りで問い合わせて比べます。
# 検証あり（通常の問い合わせ）。DNSSEC の情報も要求する
kdig @8.8.8.8 example.com A +dnssec
# 検証を無効にして問い合わせる（CD フラグを立てる）
kdig @8.8.8.8 example.com A +dnssec +cdflag1つ目で status が SERVFAIL になり、2つ目では答えが返る場合は、署名の期限切れや、親ゾーンに登録した DS レコードと鍵の不一致など、DNSSEC の検証の失敗が原因と考えられます。1つ目で答えが返り、ヘッダーのフラグに ad が含まれていれば、そのリゾルバーで検証に成功しています。
権威サーバー同士で、署名（RRSIG）が返るかも比べられます。鍵の切り替え作業の後に、1台だけ署名が古い、または署名が付かない、といった状態を見つけるのに使います。
変更の前後で結果を保存して比べる
サーバー移転や DNS の設定変更では、作業前の応答を保存しておき、作業後に同じ問い合わせをして差分を取ると、意図しない変化を見つけやすくなります。
#!/bin/sh
# 使い方: OUT=保存先ファイル sh snapshot.sh
ns=ns1.example.net
for q in "example.com A" "www.example.com A" "example.com MX" "example.com TXT"; do
set -- $q
echo "## $1 $2"
kdig @"$ns" "$1" "$2" +norecurse +noall +answer | sort
done > "${OUT:-snapshot.txt}"作業前に OUT=before.txt sh snapshot.sh、作業後に OUT=after.txt sh snapshot.sh を実行し、diff before.txt after.txt で比べます。権威サーバーの TTL は設定値がそのまま返るため、TTL を含めたままでも、TTL を変更していなければ差分には出ません。複数の値を持つレコードは返る順番が変わることがあるので、並べ替えてから比べています。
より細かく処理したい場合、比較的新しい kdig には +json で JSON 形式に出力するオプションがあります。キーの名前や構造は版によって変わる可能性があるため、kdig ... +json | jq . で手元の構造を確かめてから値を取り出す式を書いてください。
比較で迷いやすい点
- CDN や GeoDNS：問い合わせ元の地域で答えが変わるのは正常な動作です。差分が出ても設定の誤りとは限りません。
- 短時間の繰り返し：公開 DNS や他者の権威サーバーに大量の問い合わせを繰り返すと、制限される場合があります。比較は必要な名前に絞ります。
- dig との混在：作業前を dig、作業後を kdig で取ると、表示の差を変化と取り違えます。比べる記録は同じツール・同じオプションで取ります。
まとめ
- 比較は、変える条件を1つに絞り、問い合わせ先と表示のオプションを揃えて行います。
- 通信方式（UDP・TCP・TLS・HTTPS）を変えて比べると、経路での遮断や暗号化 DNS の向き先の違いが分かります。
- 権威サーバーごとの比較では
+norecurseを使い、anycast の拠点の特定には+nsidを使います。 - DNSSEC の問題は、検証ありと
+cdflag付きの結果を比べて切り分けます。 - 作業の前後で同じ問い合わせを保存し、並べ替えてから diff を取ると、意図しない変化を見つけやすくなります。