kdig と dnschecker の違いと使い分け｜世界各地の見え方を dnschecker で掴み、食い違いの原因を kdig で確かめる

dnschecker（dnschecker.org）は、世界各地の公開 DNS サーバーに同じ問い合わせを送り、どの地域でどの値が返っているかを一覧で見せる Web サービスです。kdig は、手元の端末やサーバーから、指定した1台に、指定した条件で問い合わせて応答をそのまま見せるコマンドです。広く「どこで食い違っているか」を見つけるのが dnschecker、見つけた食い違いが「待てば直るものか、設定の誤りか」を確かめるのが kdig、という分担になります。この記事では、2つの違いと、DNS の変更や移転のときに両方を組み合わせて判断する手順を説明します。

2つのツールの違い

kdig は Knot DNS に付属するコマンドで、Debian・Ubuntu では knot-dnsutils、RHEL 系では knot-utils、macOS では Homebrew の knot などで入れられます。dnschecker は登録なしで使える Web サービスで、問い合わせ先のサーバーの一覧や画面の構成、対応するレコード種別は更新で変わることがあります（2026年10月現在）。

dnschecker が向いている場面

dnschecker の価値は、自分では用意できない「各地の利用者の視点」を一度に見せてくれる点です。次のような確認に向いています。

• DNS を変更したあと、各地の公開 DNS に新しい値が行き渡ったかの見当を付ける
• 「海外の利用者だけサイトが開けない」といった報告を、地域ごとの答えで裏付ける
• 自宅や会社のネットワークの影響を受けない、外からの見え方を確かめる

一方で、ここに出る値はキャッシュサーバーが持っている答えです。変更後に古い値が残っている地域があっても、前の値の TTL が切れるまでは普通のことで、それだけでは設定の誤りとは言えません。また、一覧のうち一部が失敗の表示になるのは、そのサーバー自体が一時的に応答しないことでも起こります。1〜2か所の失敗だけで結論を出さず、どの種類の食い違いなのかを次の手順で切り分けます。

kdig が向いている場面

kdig は、条件を1つずつ固定して確かめるのに向いています。とくに大事なのは、権威サーバーに直接聞ける点です。

# 権威サーバーの一覧を確かめる
kdig @1.1.1.1 example.com NS +short

# 権威サーバーに直接、再帰なしで聞く（登録されている本来の値）
kdig @ns1.example.net www.example.com A +norecurse

# 特定の公開 DNS に聞く（その事業者のキャッシュに残る値と TTL の残り）
kdig @8.8.8.8 www.example.com A

権威サーバーからの答えには、ヘッダーのフラグに aa が付き、TTL はゾーンに設定した値そのものです。公開 DNS からの答えの TTL は、キャッシュが消えるまでの残り時間を表します。出力の末尾には、問い合わせた日時と問い合わせ先・通信方式の行が出るので、そのまま保存すれば確認の記録になります。

組み合わせて判断する手順

DNS の値を変えたとき、または DNS 事業者を移したときの流れです。

手順1：権威サーバーの値を kdig で確かめる

最初に、変更が権威サーバーに反映されているかを確かめます。ここが古いままなら、各地のキャッシュをいくら待っても新しい値にはなりません。

for ns in $(kdig @1.1.1.1 example.com NS +short); do
  echo "== $ns"
  kdig @"$ns" www.example.com A +norecurse +short
  kdig @"$ns" example.com SOA +norecurse +short
done

すべての権威サーバーが新しい値を返し、SOA のシリアル番号（3番目の値）がそろっていれば、登録側は問題ありません。1台だけ古いなら、その事業者側の同期の遅れか、移転前の事業者の NS がまだ混ざっている可能性があります。

手順2：dnschecker で各地の見え方を見る

次に dnschecker で同じ名前・同じ種別を調べ、新しい値を返す地域と古い値を返す地域の割合を見ます。変更から間もないなら、古い値が混ざるのは想定どおりです。変更前の TTL がどれだけあったかを思い出し、その時間が過ぎるまでは様子を見ます。

手順3：残った食い違いを kdig で確かめる

前の TTL を過ぎても古い値が残る地域がある場合は、その公開 DNS に手元から直接聞いてみます。dnschecker の一覧に出ている事業者のうち、Google Public DNS（8.8.8.8）、Cloudflare（1.1.1.1）、Quad9（9.9.9.9）のように広く知られたアドレスのものは、kdig で同じ問い合わせを再現できます。

for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "== $r"
  kdig @"$r" www.example.com A +noall +answer
done

TTL の残りが大きいまま古い値が返るなら、変更前の TTL が想定より長かった可能性があります。一方、権威サーバーが新しい値を返しているのに、特定の地域だけが恒常的に違う値を返す場合は、次の原因を疑います。

• 地域によって答えを変える設定：CDN や地域別の振り分け（ジオ DNS）を使っていると、地域ごとに違う IP アドレスが返るのは正常です。
• 移転前の NS が親ゾーンに残っている：レジストラ側の NS の登録を確かめます。kdig @a.gtld-servers.net example.com NS +norecurse（.com の例）で、親ゾーンに登録された委任を直接見られます。
• DNSSEC の不整合：検証を行うキャッシュサーバーだけが失敗する場合、DS と鍵の食い違いが考えられます。この判断は kdig ではなく、delv や DNSViz に任せます。

手順4：地域による答えの違いを再現する

地域別に答えを変えている権威サーバーの中には、EDNS Client Subnet（ECS）に対応し、問い合わせ元のネットワークに応じた答えを返すものがあります。kdig の +subnet を使うと、利用者のネットワークを指定した問い合わせを権威サーバーに送れます。

# 203.0.113.0/24 から来た問い合わせとして聞く（アドレスは例）
kdig @ns1.example.net www.example.com A +norecurse +subnet=203.0.113.0/24

ECS を無視する権威サーバーも多く、この方法で各地の答えを再現できるとは限りません。再現できない場合は、dnschecker の結果を地域ごとの答えの記録として保存し、DNS 事業者や CDN 事業者に問い合わせる材料にします。

暗号化 DNS と手元の環境の確認は kdig で

dnschecker は通常の DNS で問い合わせた結果しか示しません。キャッシュサーバーの DNS over TLS（DoT）や DNS over HTTPS（DoH）が使えるかを確かめたいときは、kdig を使います。

# DoT（853番ポート）で問い合わせる
kdig @1.1.1.1 example.com A +tls

# DoH で問い合わせる（対応する版のみ）
kdig @1.1.1.1 example.com A +https

DoH や DoQ の対応は Knot DNS の版や、ビルド時に組み込まれたライブラリによって異なります。オプションが認識されないときは kdig -h や man kdig で手元の版の対応を確かめてください。

社内の DNS サーバーにしか無い名前や、VPN の内側でだけ引ける名前も、dnschecker からは見えません。手元のネットワークに固有の問題（社内のキャッシュサーバーだけ古い、など）は、kdig で社内のサーバーと公開 DNS の答えを並べて比べます。

使うときの注意

• dnschecker に入れた名前は外部のサービスに送られる：公開前のサブドメインなど、外に知られたくない名前は入力しないようにします。
• 他人のドメインに大量に問い合わせない：kdig でのループや、dnschecker での繰り返しの確認は、自分が管理するドメインで必要な分にとどめます。
• 変更の前に元の値を控える：DNS 事業者の管理画面で現在のレコードを書き出すか、kdig の出力を保存しておくと、問題が起きたときに戻せます。

まとめ

• dnschecker は世界各地の公開 DNS の答えを一覧で見るサービス、kdig は手元から1台・1条件で問い合わせて応答をそのまま見るコマンドです。
• 変更の確認は、まず kdig で全権威サーバーの値と SOA のシリアル番号がそろっているかを見て、次に dnschecker で各地の行き渡り具合を見ます。
• 前の TTL を過ぎても残る食い違いは、kdig で公開 DNS に直接聞き、TTL の残りや親ゾーンの委任、地域別の振り分けの有無を確かめます。
• 暗号化 DNS、社内専用の名前、記録を残す確認は kdig の役割です。DNSSEC の検証の判断は delv や DNSViz に任せます。

• dnschecker の出力を読み解くポイント
• DNSの伝播が遅いときの確認方法