doggo で複数の DNS サーバーに同じ名前を問い合わせて比べたとき、答えが食い違うことがあります。その多くは TTL の残り時間や並び順の違いで、直す必要はありません。直す必要があるのは「権威サーバー同士の違い」「TTL を過ぎても残る古い値」「特定の経路だけの違い」の3つで、権威サーバーから順に確かめていけば原因を絞り込めます。この記事では、食い違いの種類の見分け方と、可能性の高い原因から順に確かめて直す手順を説明します。
変更の前後で控えを取って差分を出す比較の手順そのものは、同じシリーズの別の記事で扱っています。ここでは、比べた結果に違いが出たあとの対処に絞ります。
最初に、比べ方の条件をそろえる
食い違いに見えるものの中には、比べ方の違いから生まれるものがあります。原因を調べる前に、次の条件がそろっているかを確かめます。
- 同じ名前を聞いているか：doggo は resolv.conf の検索ドメイン（search）を使う設定が既定で有効です。末尾にドットを付けない短い名前を問い合わせると、検索ドメインが補われた別の名前を聞いていることがあります。表の NAME の列で、実際に問い合わせた名前を確かめます。完全な名前で問い合わせるか、
--search=falseを付けると、この取り違えを避けられます。 - 同じ種別を聞いているか：A と AAAA、CNAME を含む答えを混ぜて比べていないかを確かめます。
- すべての問い合わせ先に聞いているか：複数の問い合わせ先を並べたときにどう聞くかは
--strategyで決まります。比べるときは--strategy=allを明示して、すべての答えが表に並ぶようにします。
doggo www.example.com. A @1.1.1.1 @8.8.8.8 @9.9.9.9 --strategy=alldoggo のオプションは版によって増えたり既定値が変わったりすることがあります。使う前に doggo --help で、手元の版にある項目を確かめてください（2026年10月現在）。
直さなくてよい違い
次の違いは、DNS の正常な動きです。
- TTL の値が問い合わせ先ごとに違う：キャッシュサーバーの TTL は、キャッシュしてからの経過時間だけ減っていきます。違うのは残り時間です。
- 複数の A レコードの並び順が違う：並び順は問い合わせごとに変わることがあります。
- CDN を使った名前で、問い合わせ先ごとに違うアドレスが返る：CDN は問い合わせ元に近い拠点のアドレスを返すことがあり、公開 DNS ごとに違う答えになるのは自然です。
この3つしか違いが無ければ、対処は不要です。
原因1：権威サーバーの更新がまだ行き渡っていない
もっとも多いのは、レコードを変えた直後で、キャッシュサーバーにまだ古い値が残っている状態です。まず権威サーバーに直接聞き、正しい値かを確かめます。
# 権威サーバーの名前を調べる
doggo example.com NS --short
# 権威サーバーに直接聞く（アドレスは上で調べたネームサーバーのもの）
doggo www.example.com A @192.0.2.53 --time権威サーバーの値が新しく、キャッシュサーバーの値だけ古いなら、古い値の TTL が切れるのを待てば解消します。キャッシュサーバーの答えに表示される TTL が、古い値の残り時間の目安です。変更前の TTL が長かった場合は、その時間だけ古い値が残ります。
対処：基本は待つことです。急ぐ場合でも、公開 DNS のキャッシュを利用者側から消すことはできません。事業者によってはキャッシュの削除を依頼できる仕組みを用意していますが、それで直るのはその事業者の分だけです。次の切り替えに備えて、作業の数日前に TTL を短くしておく運用に変えます。
原因2：権威サーバー同士で値が違う
TTL を過ぎても、一部のキャッシュサーバーだけが古い値を返し続ける場合は、権威サーバーのうち1台が古い値を持っていることを疑います。キャッシュサーバーは複数の権威サーバーのどれかに聞くため、古い台に当たったキャッシュサーバーだけが古い値を受け取ります。
# すべての権威サーバーに同じ名前を聞いて並べる
doggo www.example.com A @192.0.2.53 @198.51.100.53 --strategy=all
# 各権威サーバーの SOA を比べ、シリアル番号がそろっているかを見る
doggo example.com SOA @192.0.2.53 @198.51.100.53 --strategy=all対処：シリアル番号が違うなら、セカンダリへの同期（ゾーン転送）が止まっています。自前運用なら、プライマリでシリアル番号を上げ忘れていないか、セカンダリからの転送がファイアウォールや転送の許可設定で止められていないかを確かめます。DNS 事業者を使っているなら、事業者の障害情報を確かめ、問い合わせます。
原因3：委任されているネームサーバーが違う
DNS 事業者を移したあとに起きやすいのが、親ゾーンに登録されたネームサーバーと、レコードを編集したゾーンが違う状態です。編集した新しい事業者のサーバーには新しい値があるのに、世界からは旧事業者のサーバーが参照されています。
# 委任の経路をたどり、どのネームサーバーが答えているかを見る
doggo www.example.com A --trace--trace は比較的新しい版で加わったオプションで、出力の形は版で変わることがあります。使えない版では、dig www.example.com A +trace で同じ確認ができます。
対処：レジストラの管理画面でネームサーバーの設定を確かめ、使う事業者のものにそろえます。旧事業者のゾーンは、新しいネームサーバーへの切り替えが行き渡るまで削除せず、内容をそろえたまま残しておくと、切り替え中の食い違いを小さくできます。
原因4：特定の経路だけ答えが違う
通常の UDP と、TCP や暗号化 DNS（DoH・DoT）で答えが違う場合は、経路の途中の機器が影響しています。
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- UDP だけ違う値が返る：社内のネットワークやセキュリティ製品が、通常の DNS 通信を書き換えている可能性があります。別の回線から同じ問い合わせをして比べ、ネットワークの管理者に確かめます。
- 暗号化 DNS だけ失敗する：その通信が遮断されている可能性があります。答えの違いではなく通信の問題として扱います。
- TCP だけ失敗する：答えが大きいレコード（TXT が多い、DNSSEC の署名を含むなど）で影響が出ます。権威サーバーやファイアウォールが TCP の 53 番ポートを止めていないかを確かめます。
原因5：DNSSEC の検証で一部だけ失敗する
一部の公開 DNS だけ SERVFAIL になり、他は答えを返す場合、DNSSEC の検証の失敗が考えられます。検証を行うキャッシュサーバーは、署名が正しくない答えを返しません。
# 検証を行わない指定（--cd）で聞くと答えが返るかを比べる
doggo www.example.com A @1.1.1.1
doggo www.example.com A @1.1.1.1 --cd--cd を付けたときだけ答えが返るなら、署名か DS レコードに問題があります。doggo は検証の結果を詳しく示す道具ではないため、delv や DNSViz のような検証向けの道具で原因を確かめ、署名の更新や DS の登録を見直します。
直したあとの確認
修正したら、権威サーバーをすべて並べて値と SOA のシリアルがそろっていることを確かめ、その後に複数のキャッシュサーバーを並べて、古い値が TTL の時間内に消えていくかを見ます。結果を --json で保存しておくと、作業の記録として後から見返せます。公開 DNS に短い間隔で何度も問い合わせると制限を受けることがあるため、繰り返し確かめるときは間隔を空けてください。
まとめ
- 比べる前に、名前（検索ドメインの補完）・種別・
--strategy=allの条件をそろえます。 - TTL の違い、並び順、CDN の地域差は直す必要のない違いです。
- 直す必要がある違いは、権威サーバーへの直接の問い合わせ、SOA のシリアルの比較、委任のトレースの順に確かめると原因を絞り込めます。
- 経路ごとの違いはネットワーク側、一部だけの SERVFAIL は DNSSEC を疑い、検証向けの道具で詳しく確かめます。