delv の出力は、先頭の ; で始まる1行が「その答えが DNSSEC で検証できたか」を示し、その下にレコードと署名（RRSIG）が並ぶ形です。失敗したときは ;; で始まる行に理由が出るので、まずこの2種類のコメント行を読み分けるのが近道です。この記事では、正常時の出力を上から順に読み、検証結果の表示の種類、RRSIG の各項目、失敗時のメッセージ、検証の過程を表示する +vtrace などの使い方までを説明します。
delv は BIND に付属するコマンドで、dig と同じパッケージ（Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils）に入っています。表示の細部は版によって異なるため、以下は 2026年10月現在の BIND 9.18〜9.20 系を想定した例として読んでください。
正常に検証できたときの出力
$ delv @1.1.1.1 www.example.com A
; fully validated
www.example.com. 2875 IN A 203.0.113.10
www.example.com. 2875 IN RRSIG A 13 3 3600 20261101000000 20261011000000 12345 example.com. (署名データ)読む順番は次のとおりです。
- 1行目のコメントで、検証結果を確かめる
- レコードの行で、値と TTL を確かめる
- RRSIG の行で、署名した鍵と有効期限を確かめる
dig と違い、ヘッダーやフラグ、各セクションの見出しはありません。delv は答えを検証して結果を見せることに絞った道具なので、応答コードやフラグを細かく見たいときは dig や kdig を併用します。
1行目：検証結果のコメント
レコードの前に出る ; の行は、そのレコードの集まり（同じ名前・同じ種別のレコードの組）をどの程度信頼できるかを表します。主な表示は次のとおりです。
; fully validated：ルートのトラストアンカーから署名のつながりをたどり、検証に通った答えです。; unsigned answer：ゾーンが署名されていない（親ゾーンに DS が無いことが検証で確かめられた）答えです。DNSSEC を使っていないドメインでは正常な表示です。; answer not validated：検証を行っていない答えです。-iを付けて検証を止めたときに見られます。; negative response, fully validated：「その名前は無い」「その種別は無い」という否定の答えが、検証に通ったことを示します。
CNAME をたどる答えでは、CNAME の行と最終的なレコードの行で、それぞれにコメントが付くことがあります。たとえば www.example.com が CDN の名前を指している場合、自分のゾーンは fully validated でも、CDN 側のゾーンが署名されていなければ後半は unsigned answer になります。これは CDN 側の方針によるもので、自分の設定の誤りではありません。
コメントの表示は +notrust で消せます。+short を付けた場合も、コメントや RRSIG は表示されず値だけになります。
レコードの行と TTL
レコードの行は、左から名前、TTL（秒）、クラス、種別、値の順です。ここで表示される TTL は、問い合わせたキャッシュサーバーが返した値、つまりキャッシュの残り時間です。上の例の 2875 は「あと約48分はこの答えが使われる」という意味で、ゾーンに設定した値そのものではありません。
設定値は、次に説明する RRSIG の中に記録されています。
RRSIG の行の各項目
RRSIG は、レコードの集まりに対する署名です。値の部分は次の順に並びます。
| 位置 | 例 | 意味 |
|---|---|---|
| 1 | A |
署名の対象の種別 |
| 2 | 13 |
アルゴリズム番号（8 は RSA/SHA-256、13 は ECDSA P-256/SHA-256、15 は Ed25519） |
| 3 | 3 |
名前のラベル数（ワイルドカードの判定に使う） |
| 4 | 3600 |
元の TTL（ゾーンに設定された値） |
| 5 | 20261101000000 |
有効期限（UTC の年月日時分秒） |
| 6 | 20261011000000 |
署名した日時（UTC） |
| 7 | 12345 |
署名に使った鍵のタグ |
| 8 | example.com. |
署名したゾーンの名前 |
運用の点検で見る価値が高いのは、4番目・5番目・8番目です。
- 元の TTL と、レコードの行の TTL を比べると、設定値とキャッシュの残り時間を同時に把握できます。
- 有効期限が近いのに、何度問い合わせても新しい署名に置き換わらない場合は、署名を自動で更新する仕組み（DNS 事業者の機能や、自前のサーバーの設定）が止まっている可能性があります。期限が切れると、検証を行うキャッシュサーバーでは名前解決に失敗します。
- 署名したゾーンの名前で、どのゾーンの鍵で署名されたかが分かります。サブドメインを別の事業者に委任している場合などに、想定どおりのゾーンが署名しているかを確かめられます。
長い署名は +multiline で折り返して表示できます。RRSIG が不要なら +nodnssec で省けます。
失敗したときのメッセージ
検証に失敗すると、レコードは表示されず、;; で始まる行に経過と理由が出ます。たとえば、親ゾーンの DS と子ゾーンの鍵が合っていない場合は、次のような形になります（文言は版や原因によって異なります）。
;; validating example.com/DNSKEY: no valid signature found (DS)
;; no valid RRSIG resolving 'example.com/DNSKEY/IN': 1.1.1.1#53
;; broken trust chain resolving 'www.example.com/A/IN': 1.1.1.1#53
;; resolution failed: broken trust chain最後の resolution failed: の後ろが結論で、その上の行がどこでつまずいたかの経過です。経過の行に出る 名前/種別 を見ると、どの段階の検証で失敗したかが分かります。上の例では、example.com の DNSKEY を DS で確かめる段階で失敗しているので、レジストラに登録した DS と、DNS 事業者が公開している鍵の対応を確認します。
ほかによく見かける結論と、確認する場所は次のとおりです。
SERVFAIL：問い合わせ先のキャッシュサーバー自身が検証に失敗したなどの理由で、答えを返していません。+cdflagを付けて検証を止めた答えを受け取り、delv 側で検証し直すと、失敗の理由が表示されることがあります。ncache nxdomainやncache nxrrset：名前が無い、またはその種別のレコードが無いという否定の答えです。検証の失敗ではないので、名前のつづりやレコードの登録を確認します。timed outなどの通信の失敗：DNSSEC ではなく通信経路の問題です。問い合わせ先、ファイアウォール、大きな応答や TCP の DNS が止められていないかを確かめます。
失敗したら、-i を付けて検証なしで実行し、結果を比べるのが最初の切り分けです。-i なら答えが返り、付けないと失敗するなら、原因は名前解決そのものではなく DNSSEC の設定にあります。
delv @1.1.1.1 www.example.com A -i検証の過程を表示する
失敗の理由をさらに追いたいときは、過程を表示するオプションを使います。
# 検証の各段階（鍵や署名の確認）を表示する
delv @1.1.1.1 www.example.com A +vtrace
# delv の内部で行った問い合わせ（DS や DNSKEY の取得）を表示する
delv @1.1.1.1 www.example.com A +rtrace
# 受け取った応答の中身を表示する
delv @1.1.1.1 www.example.com A +mtrace+vtrace では、validating www.example.com/A: starting のように、どの名前のどの種別を検証しているかが1行ずつ出ます。下から上へ、失敗が最初に出た行を探すと、つながりが切れている段を見つけやすくなります。+rtrace は「何を取りに行ったか」の一覧で、DS や DNSKEY を取得できていない場合の確認に向きます。
これらの行は標準エラーに出力される版が多いため、ファイルに保存したり less で読んだりするときは 2>&1 を付けて標準出力とまとめます。
読み違えやすい点
unsigned answerは異常ではありません。DNSSEC を有効にしていないドメインでは、この表示が正常です。- 表示されるのは、問い合わせ先のキャッシュサーバーが持っていたデータを検証した結果です。キャッシュに古い答えが残っていれば、直したはずの問題がまだ見えることがあります。別のキャッシュサーバーを
@で指定して比べます。 - 問い合わせ先がローカルのスタブリゾルバ（
127.0.0.53など）だと、検証に必要なレコードを中継できずに失敗することがあります。外部のキャッシュサーバーを指定して比べます。 - delv は、組み込みのルートのトラストアンカーを使って検証します。ルートの鍵は新しい鍵への切り替えが計画的に進められており（2026年10月現在）、古い delv のままだと、正しいドメインでも検証に失敗する可能性があります。OS のパッケージを更新してから使ってください。
- 権威サーバーを
@で指定すると、検証に必要な親ゾーンの DS などを取得できず失敗することがあります。権威サーバーの生の値は dig の+norecurseで確認し、delv はキャッシュサーバー経由の検証に使います。
まとめ
- delv の出力は、検証結果のコメント、レコード、RRSIG の順に並びます。まず1行目の
fully validated・unsigned answerなどを確かめます。 - レコードの TTL はキャッシュの残り時間で、RRSIG の4番目の値が設定上の TTL です。RRSIG の有効期限と署名したゾーンの名前も点検に使えます。
- 失敗時は
;;の行のresolution failed:で結論を、その上の行でつまずいた段階を読みます。-iとの比較で DNSSEC が原因かを切り分けます。 - 詳しい過程は
+vtrace・+rtrace・+mtraceで表示でき、保存するときは2>&1を付けます。 - 古い delv や、ローカルのスタブリゾルバ経由の問い合わせは、誤った失敗の原因になります。