delv でトレースするには、+vtrace（検証の過程）、+rtrace（取得したレコードの記録）、+mtrace（受け取った応答の中身）の3つの指定を使い分けます。dig の +trace が委任をルートから順にたどるのに対し、delv のトレースは「答えを検証するために何を取りに行き、どこで検証が止まったか」を表示する点が特徴です。この記事では、それぞれの指定の役割、DNSSEC の不具合を絞り込む手順、出力を読むときの注意点を説明します。逆引き（PTR）の確認方法は別の記事で扱っているため、ここでは正引きの名前を例にします。
delv のトレースで何がわかるのか
delv は BIND に付属する問い合わせツールで、受け取った答えを delv 自身が DNSSEC で検証します。検証のために、対象のレコードと署名（RRSIG）に加えて、各ゾーンの DNSKEY と、親ゾーンに登録された DS を順に取得し、ルートのトラストアンカー（delv に組み込まれた鍵の情報）までつながるかを確かめています。
通常の出力では、その結果が ; fully validated（検証できた）、; unsigned answer（署名のないゾーン）、または失敗の表示として1行で示されるだけです。トレースの指定を付けると、この途中の過程が表示されるため、失敗したときに「どのゾーンの、どのレコードで」つまずいたかを特定できます。
WordPress サイトの運用でこれが役立つのは、DNS 事業者を移したあとや DNSSEC を有効・無効にしたあとに、一部の利用者だけサイトが開けなくなった場合です。検証を行うキャッシュサーバー（公開 DNS の多くが該当します）を使う利用者だけが SERVFAIL になり、そうでない利用者には問題なく表示される、という分かりにくい症状になります。
3つのトレース指定の役割
# 検証の過程を表示する
delv www.example.com A +vtrace
# 検証のために取得したレコード（名前と種別）を表示する
delv www.example.com A +rtrace
# 受け取った応答メッセージの中身を表示する
delv www.example.com A +mtrace
# まとめて指定し、ページャーで読む
delv www.example.com A +vtrace +rtrace 2>&1 | less- +vtrace：どのレコードの検証を始め、どの鍵で署名を確かめ、結果が安全（secure）と判断されたか、どこで失敗したかが順に出ます。DNSSEC の不具合を調べるときに最初に使う指定です。
- +rtrace：検証のために取りに行ったレコードが「名前と種別」の形で並びます。
example.com/DNSKEY、example.com/DSのように、どのゾーンの何を必要としたかがわかります。 - +mtrace：受け取った応答そのものが表示されます。情報量が多いため、+rtrace で気になるレコードが見つかってから使うと読みやすくなります。
トレースの記録は標準エラー出力に出ることがあるため、上の例のように 2>&1 で標準出力にまとめてからページャーやファイルに渡すと扱いやすくなります。表示の文言や細部は BIND の版によって異なります。
手順1：通常の問い合わせで結果を確かめる
まずはトレースを付けずに実行し、先頭の1行を確認します。
delv www.example.com A; fully validated なら DNSSEC の検証に問題はありません。; unsigned answer はゾーンが署名されていないという意味で、署名していないドメインでは正常な表示です。失敗の表示が出た場合に、次の手順へ進みます。
手順2：-i で検証を外した結果と比べる
-i は検証を行わない指定です。
delv www.example.com A -i-i を付けると答えが返り、付けないと失敗する場合は、レコードそのものではなく DNSSEC の設定が原因です。-i でも失敗するなら、名前解決自体の問題（権威サーバーが応答しない、委任の誤りなど）なので、dig の +trace や権威サーバーへの直接の問い合わせで委任の経路を確かめます。
手順3：+vtrace で止まったゾーンを特定する
DNSSEC が原因とわかったら、+vtrace で過程を表示し、どのゾーンで「安全」と判断できなくなったかを探します。
delv www.example.com A +vtrace 2>&1 | tee vtrace.log出力は、対象のレコードから検証を始め、その署名を確かめるために DNSKEY、さらにその DNSKEY を親ゾーンにつなぐ DS、と上位へさかのぼる流れで並びます。正常なゾーンでは、各段階で検証に成功し安全と判断された旨が出ます。途中で「署名が見つからない」「鍵が一致しない」「期限切れ」といった趣旨の表示が出た段階が、問題のあるゾーンです。
よく見つかる原因と対処は次のとおりです。
- 親ゾーンの DS と子ゾーンの DNSKEY が一致しない：DNS 事業者を移したときに、古い事業者の鍵に対応する DS がレジストラに残っている場合に起こります。新しい事業者の案内に沿って DS を登録し直すか、DNSSEC を使わないなら DS を削除します。
- 署名の有効期限が切れている：署名を自動更新する仕組みが止まっている可能性があります。DNS 事業者のサービスなら事業者に、自前の権威サーバーなら署名の設定とログを確認します。
- DNSSEC を止めたのに DS が残っている：ゾーンの署名をやめる場合は、先に DS を親ゾーンから外し、その TTL が過ぎてから署名を止める順序が基本です。
DS と DNSKEY は、次のように個別に引いて見比べられます。
delv example.com DS +multiline
delv example.com DNSKEY +multiline -i+multiline を付けると、鍵のタグ（key id）がコメントとして表示されることが多く、DS に記録された鍵のタグと照らし合わせられます。
手順4：+rtrace で取りに行ったレコードを確かめる
+vtrace だけでは流れがつかみにくいときは、+rtrace で取得したレコードの一覧を確認します。
delv www.example.com A +rtrace 2>&1 | less取りに行ったはずの DNSKEY や DS が並んでいるのに検証に失敗している場合は、その中身（手順3の比較）に問題があります。逆に、必要なレコードを取得できていない場合は、問い合わせ先のキャッシュサーバーが DNSSEC のレコードを中継していない可能性があります。
問い合わせ先による違いに注意する
delv は、@ を指定しなければ /etc/resolv.conf に書かれたサーバーに問い合わせ、検証に必要なレコードもそこから取得します。そのため、問い合わせ先によって結果が変わることがあります。
- ローカルのスタブリゾルバ（例：
127.0.0.53）は、DNSSEC のレコードを十分に中継できず失敗することがあります。@1.1.1.1のように外部のキャッシュサーバーを指定して比べます。 @に権威サーバーを指定すると、ルートや親ゾーンの情報もそのサーバーに求めることになり、検証に失敗しやすくなります。権威サーバーの生の値は dig の+norecurseで確認します。
新しめの BIND（9.20 系など）の delv には、キャッシュサーバーを使わず delv の内部でルートから名前解決を行う +ns という指定があり、トレースと組み合わせると委任と検証の過程を一度に追えます。使える指定は版によって異なるため、手元の delv で delv -h やマニュアルを確認してください（2026年10月現在）。
つまずきやすい点
- 古い delv は組み込みのトラストアンカーが現行のものと合わず、どのドメインでも検証に失敗することがあります。複数の有名ドメインで試しても失敗するなら、OS のパッケージを更新します。
- ネットワークによっては大きな DNS 応答や TCP での問い合わせが止められ、署名付きの応答を受け取れないことがあります。別の回線や別のキャッシュサーバーで再現するかを確かめます。
- 出力を読み解くのが難しい場合は、DNSViz のような可視化ツールで同じドメインを調べると、どの段階で問題があるかを図で確認できます。
まとめ
- delv のトレースは、検証の過程（+vtrace）、取得したレコード（+rtrace）、受け取った応答（+mtrace）を表示します。
- まず通常の問い合わせと
-iを比べ、DNSSEC が原因かを判断します。 +vtraceで失敗した段階を見つけ、DS と DNSKEY を個別に引いて照らし合わせます。- 問い合わせ先で結果が変わるため、外部のキャッシュサーバーも指定して比べます。
- DS の登録や削除は、事業者の案内に沿って順序を守って行います。