delv と whatsmydns の違いと使い分け｜DNSSEC の検証結果と、世界各地のキャッシュサーバーからの見え方を組み合わせる

whatsmydns は、世界各地にある公開のキャッシュサーバーが「いまその名前に何を返しているか」を一覧で見せる Web サービスです。delv は、指定した1台のキャッシュサーバーから答えを受け取り、その答えが DNSSEC で正しく署名されているかを手元で検証するコマンドです。値の反映の広がりを見るのは whatsmydns、答えが本物か（検証に通るか）を確かめるのは delv、と分けて考えると迷いません。この記事では、両者の見ている範囲の違いと、サーバー移転や DNSSEC の導入・DNS 事業者の移転といった場面での組み合わせ方、結果が食い違ったときの読み方を説明します。

2つのツールの位置づけ

delv は dig と同じパッケージ（Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils）に含まれます。whatsmydns は Web ブラウザから名前とレコードの種別を選んで使います。表示の形や対応する種別、問い合わせ先の一覧はサービス側で変わることがあります（2026年10月現在）。

whatsmydns で分かること・分からないこと

whatsmydns の強みは、自分では問い合わせられない場所のキャッシュサーバーの状態を一度に見られる点です。サーバー移転で A レコードを変えたあと、「地域によって新旧の値が混ざっている」「一部だけ古い値が残っている」といった広がり方を一目で把握できます。

一方で、次のことは whatsmydns では分かりません。

• 問い合わせ先のキャッシュサーバーを自分で選べないため、特定の利用者の環境を再現できない
• 引けなかったときに、それが DNSSEC の検証失敗なのか、権威サーバーに届かなかったのかが区別できない
• 表示された値がいつキャッシュされたものか、あとどのくらい残るかは、表示から読み取れないことが多い

また、調べた名前は第三者のサービスに送られます。公開前のサブドメインや社内専用の名前は入力しないでください。結果の画面を自動で取得するような使い方は、サービスの利用規約を確認したうえで判断します。

delv で分かること・分からないこと

delv は、受け取った答えをルートのトラストアンカーから順に検証し、先頭に結果を表示します。

delv @1.1.1.1 www.example.com A

; fully validated なら検証に通った答え、; unsigned answer なら署名されていないゾーンの答え（DNSSEC を使っていないドメインでは正常）です。失敗した場合は ;; で始まる行に理由が出ます。

delv の弱点は、見えるのが「指定した1台のキャッシュサーバーが持っていた答え」に限られる点です。地域による違いや、別の事業者のキャッシュサーバーの状態は、問い合わせ先を変えながら繰り返し実行しないと分かりません。公開 DNS の多くはエニーキャストで運用されているため、同じアドレスを指定しても、手元の場所に近い拠点の答えしか見えません。

場面ごとの使い分け

サーバー移転で A レコードを変えたとき

主役は whatsmydns です。変更後に A レコードを調べ、新しい IP アドレスがどの程度広がったかを見ます。古い値が残っている地域があっても、多くは TTL が切れるまでの一時的な状態です。変更前の TTL の長さを目安に待ちます。

ドメインが DNSSEC で署名されている場合は、delv も実行しておきます。新しいレコードが fully validated になっていれば、DNS 事業者が新しい値にも署名を付けていることを確かめられます。

DNSSEC を有効にする・DS を登録するとき

主役は delv です。DS をレジストラに登録したあと、いくつかの公開 DNS を指定して delv を実行し、unsigned answer から fully validated に変わっていくかを確認します。

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "== $r"
  delv @"$r" www.example.com A 2>&1 | head -n 1
done

失敗の行は標準エラーに出る版があるため、2>&1 で標準出力にまとめてから先頭の行を見ています。

whatsmydns は、ここでは「引けなくなった地域が出ていないか」の見張りに使います。DS と鍵が合っていないと、検証を行うキャッシュサーバーでは名前解決に失敗し、検証を行わないキャッシュサーバーでは引けるため、一覧の中に失敗が点々と混ざる形になります。

DNSSEC を使ったまま DNS 事業者を移すとき

いちばん事故が起きやすい場面です。旧事業者の鍵に対応する DS が親ゾーンに残ったまま、新事業者のネームサーバーに切り替わると、検証を行うキャッシュサーバーからは名前が引けなくなります。手順は事業者ごとに異なるので、両方の事業者の案内に従い、各段階で delv の結果を記録しておきます。

# 親ゾーンに登録されている DS を確認する
delv @1.1.1.1 example.com DS

切り替えの前後で whatsmydns の NS と A の表示を見比べ、失敗が広がっていないかを確かめます。

「一部の人だけサイトが開かない」と言われたとき

1. whatsmydns で A レコードを調べ、値は同じなのに一部の地域だけ失敗していないかを見ます。
2. 失敗が混ざっていれば、delv で複数の公開 DNS を指定して実行します。検証に失敗するなら、DNSSEC が原因の可能性が高いと判断できます。
3. delv で失敗したら -i を付けて検証なしで実行し、答えが返るかを比べます。返るなら、原因は DS と鍵の不一致や署名の期限切れなど DNSSEC の設定です。
4. 問い合わせ先のキャッシュサーバーが失敗して何も返さない場合は、+cdflag を付けると検証を止めた答えを受け取れ、delv 側で失敗の理由を表示できることがあります。

結果が食い違うときの読み方

whatsmydns ではすべて引けているのに、delv は失敗する次の順に疑います。手元の delv が古く、組み込みのルートのトラストアンカーが現在のものと合っていない（ルートの鍵は計画的に切り替えが進められています）。問い合わせ先がローカルのスタブリゾルバ（127.0.0.53 など）で、検証に必要なレコードを中継できていない。手元のネットワークが大きな DNS 応答や TCP での DNS を止めている。いずれも、パッケージの更新や @1.1.1.1 などの外部指定、別の回線での再実行で切り分けられます。

delv は fully validated なのに、whatsmydns では一部が失敗する権威サーバーのうち1台だけに問題がある、または一部のキャッシュサーバーに失敗の結果や古い答えが残っている状態が考えられます。どの権威サーバーが原因かは、DNSViz などで全権威サーバーを調べると絞り込めます。

両方で値が古い権威サーバーの設定自体が変わっていない可能性があります。DNS 事業者の管理画面で保存されているか、ネームサーバーの切り替え先が正しいかを確認します。

まとめ

• whatsmydns は各地のキャッシュサーバーが返す値の広がりを見る道具、delv は1台のキャッシュサーバー経由の答えを DNSSEC で検証する道具です。
• A レコードの変更の反映は whatsmydns、DNSSEC の導入や DS の登録の確認は delv が主役です。
• 一部の地域だけ失敗する症状は、DNSSEC の検証失敗の典型です。delv の -i や +cdflag で原因を切り分けます。
• whatsmydns には公開前や社内専用の名前を入れず、監視の自動化には delv を使います。
• 結果が食い違うときは、手元の delv の版、問い合わせ先、ネットワークの制限、一部の権威サーバーの問題を順に確かめます。

• whatsmydns の出力を読み解くポイント
• DNSSEC を有効化する手順と注意点