DNSViz と delv の違いと使い分け｜DNSSEC の不具合を「権威サーバー全体」と「利用者の経路」の両面から確かめる

DNSViz は、ルートから対象のゾーンまでの各段階の権威サーバーにまとめて問い合わせ、委任と DNSSEC の署名のつながりを総点検して図とエラーの一覧で示す診断ツールです。delv は、1台のキャッシュサーバーから受け取った答えを手元で DNSSEC 検証し、「その名前がいま検証に通るか」を短い出力で返すコマンドです。「どこが壊れているか」を探すのは DNSViz、「利用者の環境からいま正しく引けるか」を確かめるのは delv、と覚えておくと迷いません。この記事では、2つのツールの見ている範囲の違い、場面ごとの使い分け、結果が食い違ったときの読み方を説明します。

2つのツールの位置づけ

delv は ISC の BIND に付属するコマンドで、dig と同じパッケージに入っています。Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils が一般的です（2026年10月現在）。DNSViz は Web 版のほか、オープンソースの CLI 版を Python のパッケージとして導入できます。

DNSViz が得意なこと

DNSViz の強みは「すべての権威サーバーに、いろいろな聞き方で問い合わせる」点です。キャッシュサーバーは権威サーバーのうち1台から答えを取るだけなので、利用者の側からは見えない問題も DNSViz なら表に出ます。

• 権威サーバーのうち1台だけが古い鍵や古い署名を配っている
• 親ゾーンの DS が、子ゾーンに存在しない鍵を指している
• 署名の有効期限が切れている、または切れかけている
• 存在しない名前への応答（NSEC・NSEC3 による否定の証明）が正しく作られていない
• IPv6 や TCP で問い合わせたときだけ応答が無い

1台だけが壊れている状態では、キャッシュサーバーがどのサーバーに当たるかで成功と失敗が入れ替わり、「ときどき引けない」という分かりにくい症状になります。この種の原因を絞り込むには、全サーバーを並べて比べる DNSViz が向いています。

Web 版で解析した結果はサイト上で他の人も閲覧できる形で残るため、社内専用の名前や公開前のゾーンは Web 版に入れず、CLI 版を自分の環境で動かします。CLI 版の使い方は別の記事で扱っています。

delv が得意なこと

delv は、利用者と同じキャッシュサーバーを通した答えを検証できる点が強みです。@ で問い合わせ先を指定すれば、社内のキャッシュサーバーや公開 DNS ごとに結果を比べられます。

# 公開 DNS を経由した答えを検証する
delv @1.1.1.1 www.example.com A

# 検証を止めた結果と比べる
delv @1.1.1.1 www.example.com A -i

# 検証の過程を表示する
delv @1.1.1.1 www.example.com A +vtrace

先頭に ; fully validated と出れば、ルートからのつながりで検証に通った答えです。; unsigned answer は署名されていないゾーンの答えで、DNSSEC を使っていないドメインでは正常な表示です。検証に失敗すると、その旨と理由が表示されます。文言は版によって少し違うことがあります。

-i を付けると答えが返り、付けないと失敗する場合は、名前解決の経路ではなく DNSSEC の設定に原因があると判断できます。1回の実行が軽いので、スクリプトに組み込んで繰り返し実行する用途にも向いています。

一方で、delv が見ているのは「そのキャッシュサーバーが持っていたデータ」です。キャッシュに古い答えが残っていれば、直したはずの問題がまだ見えたり、逆に壊れたばかりの問題がまだ見えなかったりします。どの権威サーバーが原因かも delv だけでは分かりません。

場面ごとの使い分け

「サイトが開かない」と連絡を受けたとき

1. 連絡をくれた人が使っているキャッシュサーバー（分からなければ主な公開 DNS）を指定して delv を実行し、検証に失敗しているかを確かめます。
2. 失敗していれば -i を付けて再実行します。答えが返るなら DNSSEC が原因です。
3. DNSViz で対象の名前を解析し、エラーが出ている箇所（DS と鍵の対応、特定の権威サーバー、署名の期限など）を特定します。
4. 修正したら DNSViz で再解析してエラーが消えたことを確かめ、続けて delv で各キャッシュサーバーからの結果を確認します。

修正後もしばらく失敗が続くことがあります。キャッシュサーバーによっては、検証に失敗した結果を一定時間保持するためです。待つ時間の目安は、関係するレコードの TTL です。

DNSSEC を有効にする・鍵や DS を差し替えるとき

作業の各段階の前後に DNSViz で解析し、結果の図を保存しておきます。DS をレジストラに登録したあとは、delv を複数のキャッシュサーバーに向けて実行し、fully validated に変わっていくかを見ます。DNSViz で整合性を、delv で利用者側への反映を確かめる、という役割分担です。DS の登録は、新しい鍵がすべての権威サーバーで公開されたことを DNSViz で確かめてから行います。

署名の期限切れを防ぐ監視

日常の監視には delv が手軽です。次の例は、いくつかの公開 DNS で検証結果の1行目を記録します。

#!/bin/sh
# 検証結果の1行目を記録する例（表示の文言は手元の版で確認）
name=www.example.com
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  res=$(delv @"$r" "$name" A 2>&1 | head -n 1)
  echo "$(date '+%F %T') $r $res"
done

cron で定期的に実行し、fully validated 以外の行が出たら DNSViz で詳しく調べます。ただし delv は「いま失敗しているか」を見る道具で、期限が近づいていることの警告は出しません。期限切れを事前に知りたい場合は、DNSViz の CLI 版を定期的に実行して警告を拾うか、DNSSEC に対応した外部の監視サービスを検討します。

社内専用のゾーンを確かめるとき

社内向けのゾーンを独自の鍵で署名している場合、ルートからのつながりが無いため、delv も DNSViz も既定の設定では検証できません。delv では -a で独自のトラストアンカーを書いたファイルを指定し、DNSViz の CLI 版ではトラストアンカーを与えて解析します。どちらも指定の書き方は版で変わることがあるので、手元のマニュアルで確かめてください。

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

DNSViz ではエラーなのに、delv では fully validated になる一部の権威サーバーだけに問題がある可能性が高い状態です。キャッシュサーバーがたまたま正常なサーバーから答えを取っていると、delv は成功します。また、DNSViz が IPv6 や TCP での問い合わせの失敗を指摘している場合、IPv4 と UDP で問い合わせたキャッシュサーバーでは問題が表に出ません。どちらも、条件次第で利用者に影響するので修正しておきます。

delv では失敗するのに、DNSViz ではエラーが無い次の順に疑います。

• キャッシュサーバーに修正前の答えが残っている。別のキャッシュサーバーを指定して結果が変わるかを確かめます。
• 手元の delv が古く、組み込みのルートのトラストアンカーが現在のものと合っていない。OS のパッケージを更新します。
• 問い合わせ先がローカルのスタブリゾルバ（127.0.0.53 など）で、検証に必要なレコードを中継できていない。@1.1.1.1 のように外部のキャッシュサーバーを指定して比べます。
• 手元のネットワークが大きな UDP の応答や TCP での DNS を止めている。別の回線で再現するかを確かめます。

両方で失敗するゾーンの設定に問題がある状態です。DNSViz の図で、どの段階のどのつながりが切れているかを確認して修正します。

まとめ

• DNSViz は全権威サーバーを調べてゾーンを公開する側の整合性を点検し、delv は1台のキャッシュサーバーを通した答えを利用者の側から検証します。
• 原因の特定や変更作業の前後の診断は DNSViz、日常の確認や監視、利用者の環境での再現は delv に任せます。
• delv で失敗したら -i で検証なしの結果と比べ、DNSSEC が原因なら DNSViz で場所を探します。
• 結果が食い違うときは、一部のサーバーだけの問題、キャッシュに残った古い答え、手元の delv やネットワークの事情を順に疑います。
• 社内専用の名前は Web 版に入れず、CLI 版と独自のトラストアンカーで確かめます。

• delv で TTL と NS を一括確認する方法
• DNSSEC を有効化する手順と注意点