delv example.com NS を実行すると、NS レコードとその TTL に加えて、その答えが DNSSEC で検証できたかどうかを1回で確認できます。署名されたゾーンなら、RRSIG に含まれる「元の TTL」と署名の有効期限も同じ出力に並ぶため、キャッシュの残り時間と本来の設定値を見比べられます。この記事では、delv で NS と TTL をまとめて確かめる手順と、出力の読み方、権威サーバーを指定するときの注意点を説明します。
delv とは
delv は BIND に付属する DNS の問い合わせツールで、dig と同じパッケージ（Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils）に含まれています。dig との最大の違いは、受け取った答えを delv 自身が DNSSEC で検証する点です。問い合わせ先のキャッシュサーバーが検証を行っていなくても、delv は組み込みのルートのトラストアンカーから署名のつながりをたどり、結果を表示します。
問い合わせ先を @ で指定しない場合は、/etc/resolv.conf に書かれたサーバーを使います。名前の解決自体はそのサーバーに任せ、検証に必要な DNSKEY や DS も同じサーバーから取得する、という動きです。
基本の使い方
# NS を引き、検証結果と TTL を確認する
delv example.com NS
# SOA も確認する（シリアルや各種タイマーを見る）
delv example.com SOA
# 問い合わせ先のキャッシュサーバーを指定する
delv @1.1.1.1 example.com NS
# 長い RRSIG を読みやすく折り返す
delv example.com NS +multiline出力はおおむね次のような形です（値は例で、環境によって異なります）。
; fully validated
example.com. 84290 IN NS ns1.example.net.
example.com. 84290 IN NS ns2.example.net.
example.com. 84290 IN RRSIG NS 13 2 86400 20261101000000 20261011000000 12345 example.com. (署名データ)1行目が検証結果、続く行が NS レコードと、その署名（RRSIG）です。RRSIG の表示は +nodnssec で省けます。
1行目の検証結果を読む
delv の出力の先頭には、答えの信頼度がコメントとして表示されます。
; fully validated：ルートから対象ゾーンまで署名のつながりが検証できた答えです。; unsigned answer：ゾーンが DNSSEC で署名されていない答えです。署名していないドメインでは正常な表示で、問題ではありません。- 検証に失敗した場合：失敗した旨と理由（署名が無効、信頼のつながりが切れている、など）が表示され、レコードは表示されません。
表示される文言は版によって多少異なることがあります。検証に失敗したときは、-i を付けて検証を無効にした結果と比べます。
delv example.com NS -i-i を付けると答えが返り、付けないと失敗する場合は、名前解決そのものではなく DNSSEC の設定（DS と DNSKEY の不一致、署名の期限切れなど）が原因だと判断できます。失敗の段階を詳しく追いたいときは、+vtrace で検証の過程を表示できます。
TTL を読むときの注意
delv が表示する TTL は、問い合わせたキャッシュサーバーが返した値です。キャッシュサーバーは保存してからの経過時間を差し引いて答えるため、表示されるのは「残り時間」で、ゾーンに設定した値そのものではありません。上の例の 84290 は、残り約23時間という意味です。
署名されたゾーンでは、RRSIG の中に設定上の TTL が記録されています。RRSIG の各項目は、対象の種別、アルゴリズム番号、ラベル数、元の TTL、有効期限、署名日時、鍵のタグ、署名者、署名の順に並びます。上の例では 86400 が元の TTL で、ゾーンには1日と設定されていることがわかります。delv の1回の出力で、残り時間と設定値の両方を確認できるのはこのためです。
同じ行の有効期限（例では 20261101000000、UTC の年月日時分秒）も確認しておくと、署名の自動更新が止まっていないかの点検になります。期限が近いのに新しい署名に置き換わらない場合は、署名を行っている DNS 事業者やサーバーの設定を確認します。
署名されていないゾーンでは RRSIG が無いため、設定上の TTL は権威サーバーに dig で直接問い合わせて確認します。
dig @ns1.example.net example.com NS +norecurseNS と各サーバーのアドレスをまとめて確認する
NS の一覧を出したら、それぞれのネームサーバーのアドレスも引いておくと、委任先の名前が正しく解決できるかを一度に点検できます。delv の通常の出力は「名前、TTL、クラス、種別、値」の順に並ぶので、awk で NS の行だけを取り出せます。
zone=example.com
delv "$zone" NS | awk '$4 == "NS" {print $2, $5}'
delv "$zone" NS | awk '$4 == "NS" {print $5}' | while read -r ns; do
echo "== $ns"
delv "$ns" A | awk '$4 == "A" {print $2, $5}'
delv "$ns" AAAA | awk '$4 == "AAAA" {print $2, $5}'
done各ネームサーバーで先頭の検証結果を見たい場合は、awk を通さずにそのまま実行します。ネームサーバーが別のドメインにある場合、そのドメインが署名されていなければ unsigned answer になりますが、対象ゾーンの検証には影響しません。
親ゾーンに登録されている DS も、同じ流れで確認できます。
delv example.com DSDS は親ゾーン（.com など）に置かれるレコードで、子ゾーンの DNSKEY を指しています。DNSSEC を使っていないのに DS が残っていると、検証を行うリゾルバでは名前解決に失敗します。DNS 事業者を移したあとに fully validated でも unsigned answer でもなく失敗が表示される場合は、まずここを確認します。
権威サーバーを指定するときの注意
delv で @ に権威サーバーを指定すると、検証に必要な親ゾーンの DS やルートの DNSKEY もそのサーバーに問い合わせることになります。権威サーバーは自分のゾーン以外の答えを返さないため、検証に失敗することがあります。権威サーバーの生の値を見たいときは dig の +norecurse を使い、delv は検証結果の確認に使う、と役割を分けると混乱しません。
新しめの BIND（9.20 系など）の delv には、内部で再帰問い合わせを行う +ns という指定があり、キャッシュサーバーを介さずにルートから名前解決と検証を行い、その過程を表示します。手元の delv に指定があるかは delv -h やマニュアルで確かめてください。
つまずきやすい点
- 古い delv では、組み込みのルートのトラストアンカーが現在のものと合わず、検証に失敗することがあります。ルートの鍵は計画的に更新されており、新しい鍵への移行作業も進められているため（2026年10月現在）、OS のパッケージを最新に保ってください。
/etc/resolv.confの問い合わせ先がローカルのスタブリゾルバ（例：127.0.0.53）の場合、DNSSEC の検証に必要なレコードを十分に中継できず失敗することがあります。その場合は@1.1.1.1などのキャッシュサーバーを指定して比べます。- ネットワークによっては大きな DNS 応答や TCP での問い合わせが止められており、署名付きの応答を受け取れないことがあります。別の回線や別のキャッシュサーバーで再現するかを確かめます。
まとめ
delv ドメイン NSで、NS と TTL、DNSSEC の検証結果を1回で確認できます。- 表示される TTL はキャッシュの残り時間です。署名されたゾーンなら RRSIG の「元の TTL」で設定値を、有効期限で署名の更新状況を確かめられます。
- 検証に失敗したら
-iで検証なしの結果と比べ、DNSSEC が原因かを切り分けます。 - 権威サーバーの生の値は dig の
+norecurseで確認し、delv は検証の確認に使います。 - 古い delv は検証に失敗することがあるため、パッケージを更新してから使います。