DNSKEY レコードの検証では、「親ゾーンの DS が自ゾーンの DNSKEY と一致しているか」「DNSKEY に有効な署名（RRSIG）が付いているか」「検証するリゾルバーが実際に成功しているか」の3点を順に確かめます。この記事では、dig と delv を使ってこの3点をコマンドで確認する方法と、失敗していたときの原因の読み方を説明します。DNSSEC を有効にした直後や、鍵の更新・DNS サービスの移行のあとに、設定が正しいかを自分で判断できるようになるのが目標です。
DNSKEYと関連レコードの関係
DNSSEC では、次のレコードが鎖のようにつながって信頼を伝えます。
- DNSKEY: ゾーンの公開鍵。一般に、鍵署名用の KSK（flags が 257）とゾーン署名用の ZSK（flags が 256）がある。1本の鍵で両方を兼ねる構成（CSK）もある
- RRSIG: 各レコードの集合に付く署名。DNSKEY の集合は KSK（または CSK）で署名される
- DS: 親ゾーン（.com や .jp など）に登録する、KSK のハッシュ値
検証は「親の DS → 自ゾーンの KSK → DNSKEY の集合 → ZSK → 各レコードの署名」という順に進みます。どこか1か所でも一致しないと、検証するリゾルバーは名前解決そのものを失敗（SERVFAIL）として扱います。つまり DNSSEC の不備は「一部の利用者からサイトが見えない」という障害になるため、検証は設定作業の一部として扱う必要があります。
手順1: DNSKEYを取得して鍵の種類を確認する
まず権威ネームサーバーから DNSKEY を取得します。
# 権威ネームサーバーを調べる
dig example.com NS +short
# 権威サーバーに直接 DNSKEY を問い合わせる（署名も表示）
dig @ns1.example-dns.net example.com DNSKEY +dnssec +multi+multi を付けると、各鍵の行に KSK / ZSK の区別、アルゴリズム、鍵ID（key tag）がコメントとして表示されます（表示形式は dig のバージョンで多少異なります）。ここで確認するのは次の点です。
- flags が 257 の鍵（KSK または CSK）が少なくとも1本ある
- アルゴリズムが想定どおりか。よく使われるのは 8（RSASHA256）と 13（ECDSAP256SHA256）
- 鍵ID を控えておく。次の手順で DS と照合する
権威サーバーが複数ある場合は、すべてに同じ問い合わせをして結果が揃っているかも見ます。一部のサーバーだけ古い鍵を返していると、問い合わせ先によって検証が成功したり失敗したりします。
手順2: 親ゾーンのDSとDNSKEYを照合する
# 親ゾーンに登録されている DS を確認
dig example.com DS +short結果は「鍵ID アルゴリズム ダイジェスト種別 ダイジェスト値」の順に並びます。鍵ID とアルゴリズムが、手順1で控えた KSK のものと一致しているかを確認します。
ダイジェスト値まで照合したい場合は、DNSKEY から DS を計算して比べます。BIND に含まれる dnssec-dsfromkey を使う例です。
# DNSKEY から SHA-256 の DS を計算して表示する
dig @ns1.example-dns.net example.com DNSKEY +noall +answer | dnssec-dsfromkey -a SHA-256 -f - example.com出力された DS と、dig example.com DS +short の結果が一致すれば、親子の鎖はつながっています。オプションはツールのバージョンによって異なることがあるため、手元の man dnssec-dsfromkey で確認してください（2026年10月現在）。
DS が返らない場合は、レジストラに DS がまだ登録されていない状態です。この場合は検証の対象外（署名はあっても「安全でない」扱い）となり、名前解決は失敗しません。
手順3: DNSKEYの署名（RRSIG）の期限を確認する
手順1の出力に含まれる、DNSKEY を対象とした RRSIG の行を見ます。RRSIG には署名の有効期限と開始日時が 20261101000000 のような形式（UTC）で入っています。
- 有効期限がすでに過ぎている、または数日以内に迫っている
- 開始日時が未来になっている（署名したサーバーの時計がずれている）
どちらかに当てはまる場合、署名の自動更新が止まっている可能性があります。マネージド DNS では通常サービス側で自動更新されますが、BIND などで自分で署名している場合は、署名処理やタイマーが動いているかを確認します。
手順4: 検証するリゾルバーで結果を確かめる
最後に、DNSSEC を検証する公開リゾルバーで実際の結果を見ます。
# 検証成功なら、応答ヘッダーの flags に ad が付く
dig @1.1.1.1 example.com A +dnssec
# 検証を無効にして（+cd）問い合わせる
dig @1.1.1.1 example.com A +cd
# delv はローカルで検証し、結果を表示する
delv example.com A判断の目安は次のとおりです。
adフラグが付く: 検証成功- 通常の問い合わせは SERVFAIL だが、
+cdを付けると答えが返る: DNSSEC の検証に失敗している adが付かず答えは返る: DNSSEC が有効になっていない（DS 未登録など）
delv は検証に成功すると「validated」を含む行を表示し、失敗するとその理由を出力します。どの段階で失敗したかの手がかりになります。
コマンドに加えて、DNSViz などの可視化ツールを使うと、親から子までの鎖がどこで切れているかを図で確認できます。表示内容はツールの更新で変わることがあるため、結果の読み方は各ツールの説明を参照してください。
検証に失敗する主な原因
DSが古い鍵のまま残っている
鍵の更新（ロールオーバー）や DNS サービスの移行のあと、レジストラの DS を更新し忘れるのが最も多い原因です。手順2で DS の鍵ID が現在の KSK と一致しないなら、新しい DS をレジストラに登録します。
DNSサービスを移行したのに旧サービスの鍵に対応するDSが残っている
移行先では別の鍵で署名されるため、旧サービスの鍵に対応する DS が残っていると検証に失敗します。移行時は、DS を外して十分な時間（DS の TTL 以上）待ってから移行し、移行後に新しい DS を登録する手順が一般的です。
署名の期限切れ・時刻のずれ
手順3で見つかる問題です。署名を作るサーバーの時刻同期（NTP など）と、自動再署名の設定を確認します。
応答サイズとTCPの問題
DNSKEY の応答は大きくなりやすく、UDP で届かないときは TCP に切り替わります。ファイアウォールで DNS の TCP（ポート53）を閉じていると、環境によって検証が失敗します。権威サーバー側で TCP の53番が開いているかを確認してください。
修正するときの注意
DS の変更は親ゾーンでキャッシュされるため、直してもすぐには反映されません。障害時に DS を削除して DNSSEC を一時的に止める方法もありますが、それでもキャッシュが消えるまでは失敗が続きます。作業前には現在の DS と DNSKEY の値を控え、変更は TTL を考慮した時間の余裕をもって進めてください。
まとめ
- DNSKEY の検証は「DS と KSK の一致」「DNSKEY の署名の有効期限」「検証リゾルバーでの結果」の3段階で確認する
dig +multiで鍵ID を確認し、dig DSやdnssec-dsfromkeyの結果と照合するadフラグと+cdの比較、delvの出力で、検証の成否と失敗箇所を判断できる- 失敗の多くは鍵の更新や移行時の DS の更新漏れ。作業前に値を控え、TTL の分だけ余裕を見る