DNSViz のコマンドライン版は、dnsviz probe で権威サーバーに問い合わせた結果を JSON に保存し、その JSON を print（文字で一覧）・grok（問題点を JSON で抽出）・graph（図）で読み解く、という2段階で使います。問い合わせと解析を分けられるので、同じ結果を何度でも読み直せ、作業の前後の比較や、Web 版では調べられない社内専用のゾーンや公開前のゾーンの検査にも使えます。この記事では、導入から基本の流れ、症状ごとの調べ方、公開前の検査、つまずきやすい点までを説明します。
DNSViz のサブコマンドやオプションは版によって追加・変更されることがあります。ここでの説明は執筆時点（2026年10月現在）の公式の説明にもとづくので、手元では dnsviz help probe（または dnsviz probe -h）の表示を優先してください。
Web 版ではなく CLI 版を使う理由
Web 版（dnsviz.net）は手軽ですが、次のような場面では CLI 版が向いています。
- 社内専用の名前を調べたい：Web 版はインターネット側から問い合わせるため、社内の DNS サーバーには届きません。また、Web 版の解析結果は他の人も閲覧できる形でサイトに残ります。
- 自分のネットワークから見た結果がほしい：IPv6 での到達性や、特定の回線からの応答の様子を確かめられます。
- 結果を保存して比べたい：JSON をファイルとして残せるので、変更の前後で差を取れます。
- 定期的に実行したい：cron などから実行し、警告が出たら通知する仕組みを作れます。
導入
DNSViz は Python のパッケージとして公開されています。システムの Python を汚さないよう、仮想環境に入れるのが無難です。
python3 -m venv ~/dnsviz-env
. ~/dnsviz-env/bin/activate
pip install dnsviz
dnsviz help図を作る graph には Graphviz と、その Python 向けの部品（pygraphviz）が必要です。pygraphviz の導入で失敗する場合は、先に OS のパッケージで Graphviz 本体と開発用のヘッダーを入れてから再実行します。ディストリビューションによっては dnsviz という名前のパッケージが用意されていることもあります。依存するライブラリは版によって変わるので、導入でつまずいたら公式リポジトリの説明を確認してください。
基本の流れ：probe で集めて、print・grok・graph で読む
# 1. 権威サーバーに直接問い合わせ、結果を JSON に保存する
dnsviz probe -A -p example.com > example.com.json
# 2. 文字で全体を確認する
dnsviz print -r example.com.json
# 3. 問題点だけを取り出す
dnsviz grok -l warning -p -r example.com.json
# 4. 図にする
dnsviz graph -r example.com.json -T png -o example.com.png-A は、キャッシュサーバーを経由せず、ルートから委任をたどって権威サーバーに直接問い合わせる指定です。付けない場合は resolv.conf のキャッシュサーバーを経由して調べます。デバッグでは、各権威サーバーの生の応答を見たいので -A を付けるのが基本です。-p は JSON を読みやすく整形する指定です。
2〜4 は、保存した JSON を -r で読み込むだけで、DNS への問い合わせは行いません。表示の仕方を変えて何度読み直しても、権威サーバーに負荷をかけずに済みます。dnsviz probe -A example.com | dnsviz print のようにパイプでつなぐこともできます。
print で全体をざっと見る
print は、ゾーンごとに DS・DNSKEY と、各レコードの集合（同じ名前・同じ種別のレコードのまとまり）の状態を文字で並べます。エラーや警告がある箇所には、その内容が続けて表示されます。最初に print で「どのゾーンの、どのレコードで問題が起きているか」をつかみ、詳しい理由を grok で確かめる、という順にすると効率よく進められます。
記号や表示の細かい形は版で変わることがあるので、慣れないうちは、正常なドメインを一度 print して見比べると読み方がつかめます。
grok で問題点を取り出す
grok は、解析した結果を JSON で出力します。-l で出力する重要度を絞れ、-l warning なら警告とエラー、-l error ならエラーだけになります。状態は SECURE・INSECURE・BOGUS などの値で表され、BOGUS は「署名が検証できない」状態で、DNSSEC を検証するキャッシュサーバーでは名前解決に失敗します。
出力の入れ子は深いので、jq でエラーの項目だけを拾うと読みやすくなります。
# errors を持つ項目を、場所に関係なく取り出す
dnsviz grok -l error -r example.com.json \
| jq '.. | objects | select(has("errors")) | .errors'JSON の構造は版によって変わる場合があるので、最初に jq . で全体を眺めてから絞り込み方を決めてください。
graph で関係を確かめる
graph は、ゾーンの委任と、DS・DNSKEY・署名のつながりを図にします。-T png や -T svg のほか、-T html を指定すると、ブラウザで開いて要素ごとの詳細を確かめられる形式になります。文字では分かりにくい「どの DS がどの鍵を指しているか」「どの鍵がどの署名を作っているか」は、図で見るのが早道です。図の読み方は Web 版と共通です。
症状ごとの調べ方
ときどき名前解決に失敗する
一部の権威サーバーだけが古いデータを配っていることを疑います。print や grok のエラーには、問題のあった権威サーバーのアドレスが含まれます。そのアドレスに dig などで直接問い合わせ、他のサーバーと比べます。セカンダリへのゾーン転送が止まっている、エニーキャストの一部の拠点だけ更新が遅れている、といった原因が見つかることがあります。
DNS 事業者を移したあとに検証に失敗する
親ゾーンの DS が、移転前の事業者の鍵を指したままになっていないかを確かめます。図で DS から伸びる線が、どの DNSKEY にもつながっていなければこの状態です。移転先の事業者の案内に従って DS を差し替えるか、いったん DS を外します。
署名の期限についての警告が出る
署名の有効期限が近いのに新しい署名に置き換わっていない状態です。署名を自動で更新する仕組み（DNS 事業者の機能や、自前のサーバーの署名の設定）が止まっていないかを確認します。期限が切れる前に対処できるよう、定期的な probe と grok -l warning を cron で実行しておくと安心です。
IPv6 や TCP だけで応答が無い
手元から IPv6 で外に出られない環境では、IPv6 の問い合わせの失敗が手元の事情によるものか判断できません。IPv6 が使える別のサーバーで実行するか、-4 で IPv4 に限って解析し、IPv6 は別に確かめます。TCP で応答が無いという指摘は、権威サーバーの前のファイアウォールで TCP の 53 番が閉じられているときによく出ます。DNSSEC の署名付きの応答は大きくなりやすく、TCP で取り直す場面が増えるので、開けておくのが基本です。
社内専用のゾーンや公開前のゾーンを検査する
probe には、問い合わせる権威サーバーを指定するオプション（-x）があり、親ゾーンからの委任がまだ無いゾーンや、社内の DNS サーバーにしか無いゾーンも解析できます。
# 指定したアドレスのサーバーを example.com の権威サーバーとして扱う（書式は版で確認）
dnsviz probe -A -x example.com:192.0.2.53 -p example.com > staging.jsonこのほか、親ゾーンに登録する予定の NS や DS をファイルから与えて、委任を登録する前の状態を検査する指定（-N・-D）も用意されています。DS を登録する前に「この DS を登録したら検証に通るか」を確かめられるので、DNSSEC の導入作業での事故を減らせます。
社内のゾーンを独自の鍵で署名している場合は、print・grok・graph にトラストアンカーを書いたファイルを与えて解析します。指定方法は dnsviz help grok などで確認してください。
変更の前後を比べる
作業前と作業後に同じ条件で probe を実行して JSON を保存し、grok の結果を比べると、作業によって増えた問題と消えた問題が分かります。
dnsviz probe -A -p example.com > before.json
# （設定を変更する）
dnsviz probe -A -p example.com > after.json
dnsviz grok -l warning -p -r before.json > before-grok.json
dnsviz grok -l warning -p -r after.json > after-grok.json
diff before-grok.json after-grok.json解析した日時や署名の期限など、毎回変わる値も差として出るので、エラーや警告の項目に注目して読みます。
つまずきやすい点
-Aでの解析は、手元から各権威サーバーへ直接 UDP と TCP の 53 番で問い合わせます。社内ネットワークでは外向きの DNS 通信が止められていることが多いので、その場合は外部に出られるサーバーで実行します。probeは1つの名前でも多くの問い合わせを送ります。他人のドメインを大量に、または短い間隔で調べるのは避け、自分が管理するドメインに使います。- 結果に出るのは「実行した時点、実行した場所から見た状態」です。キャッシュの影響を受けない分、利用者の見え方とは一致しないことがあります。利用者側の確認には delv などを併用します。
まとめ
dnsviz probe -Aで権威サーバーの応答を JSON に保存し、print・grok・graphで読み解きます。読み直しでは DNS への問い合わせは発生しません。printで問題の場所をつかみ、grok -l warningで理由を確かめ、graphで DS・鍵・署名のつながりを図で見ます。- ときどき失敗する症状は一部の権威サーバー、移転後の失敗は親ゾーンの DS、期限の警告は署名の自動更新を疑います。
-x・-N・-Dを使うと、社内のゾーンや DS 登録前の状態を検査できます。書式は手元の版のヘルプで確かめます。- 変更の前後で JSON を保存して
grokの結果を比べると、作業の影響を見落としにくくなります。