2026年6月11日

DNSKEYレコードの検証手順｜鍵の公開・署名・DSとの対応を順に確かめる

DNS・名前解決

DNSKEYレコードの検証は、「すべての権威サーバーが同じ鍵を返しているか」「DNSKEYの集まりがKSKで正しく署名されているか」「親ゾーンのDSがその鍵を指しているか」「検証するリゾルバで実際に検証が通るか」の4段階で進めると、抜けなく確かめられます。この記事では、DNSSECを有効にした直後や鍵を更新したあと、DNSサービスを移行したあとに行う確認の手順を、dig と delv のコマンド例と出力の読み方とあわせて説明します。障害が起きてからの修正ではなく、問題が表に出る前に見つけるための点検手順です。

DNSKEYレコードの読み方

まずはDNSKEYの中身を読めるようにしておきます。+multiline を付けると、各鍵の種類と番号がコメントとして表示されます。

dig example.com DNSKEY +multiline

example.com. 3600 IN DNSKEY 257 3 13 (
                (KSKの公開鍵・Base64)
                ) ; KSK; alg = ECDSAP256SHA256 ; key id = 2371
example.com. 3600 IN DNSKEY 256 3 13 (
                (ZSKの公開鍵・Base64)
                ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 34505

値は先頭から、フラグ・プロトコル・アルゴリズム・公開鍵の順です（公開鍵の部分は省略しています）。

フラグ: 257 は鍵署名鍵（KSK）、256 はゾーン署名鍵（ZSK）。1つの鍵で両方を兼ねる構成（CSK）では、フラグ257の鍵だけが並びます
プロトコル: 常に 3 です。ほかの値なら設定の誤りです
アルゴリズム: 8（RSASHA256）、13（ECDSAP256SHA256）、15（Ed25519）などが現在よく使われます。5（RSASHA1）や7（RSASHA1-NSEC3-SHA1）のようなSHA-1系は署名用として推奨されておらず、SHA-1による検証を既定で無効にしているOSもあるため、見つけたら移行を検討します
key id: 鍵の番号（キータグ）。DSや署名（RRSIG）はこの番号で鍵を指します

ステップ1：すべての権威サーバーで同じDNSKEYが返るか

権威サーバーが複数ある場合、1台だけ古い鍵を返していると、そのサーバーに当たったリゾルバでだけ検証が失敗します。キャッシュを通さず、サーバーごとに直接問い合わせて比べます。

for ns in $(dig +short example.com NS); do
  echo "== $ns"
  dig @"$ns" example.com DNSKEY +multiline +norecurse | grep "key id"
done

すべてのサーバーで、同じ組み合わせの key id が表示されれば問題ありません。違う場合は、セカンダリへのゾーン転送が遅れているか止まっています。ゾーンのシリアル番号（dig @サーバー example.com SOA +short の3番目の値）をサーバーごとに比べると原因が分かります。

ステップ2：DNSKEYの集まりがKSKで署名されているか

DNSKEYの集まり自体には、KSKによる署名（RRSIG DNSKEY）が付きます。この署名が正しいことが、ZSKを信頼する根拠になります。

dig @ns1.example.net example.com DNSKEY +dnssec +multiline +norecurse

RRSIG DNSKEY の行で、次の点を確かめます。

署名のキータグが、フラグ257の鍵（KSK）の key id と一致しているか
アルゴリズムの番号が、KSKのアルゴリズムと同じか
有効期限（14桁の日時、UTC）が先の日付で、署名開始日時が現在より前か

あわせて、AやCAAなど通常のレコードの署名（たとえば dig example.com A +dnssec の RRSIG A）のキータグがZSKを指しているかも見ておきます。署名のキータグに対応する鍵がDNSKEYに無い場合、鍵の更新で古い鍵を早く外しすぎた可能性があります。

自前で署名しているゾーンでは、有効期限の確認がとくに大切です。署名を更新する仕組みが止まると、期限が来た時点でゾーン全体の検証が失敗します。

ステップ3：親ゾーンのDSがKSKを指しているか

親ゾーンに登録されたDSが、今公開しているKSKを指しているかを照合します。BINDに付属する dnssec-dsfromkey を使うと、公開中のDNSKEYから正しいDSを計算できます。

# 親ゾーンに登録されている DS
dig example.com DS +short

# 公開中の DNSKEY から DS を計算する
dig example.com DNSKEY | dnssec-dsfromkey -f - example.com

DSの値は、キータグ・アルゴリズム・ダイジェスト種別・ダイジェストの順です。計算したDSと、親に登録されているDSのどれか1つが、4つの値すべてで一致していれば連鎖はつながっています。ダイジェスト種別は 2（SHA-256）が一般的です。dnssec-dsfromkey が出力するダイジェスト種別はBINDのバージョンによって異なり、オプションで指定もできるので、親に登録されている種別と同じものを比べてください。

一致しない場合は、レジストラに登録したDSが古いか、入力を誤っています。この状態ではすでに検証が失敗しているはずなので、DSの登録をし直す作業に進みます。

ステップ4：検証するリゾルバで検証が通るか

最後に、利用者と同じ立場で検証が通るかを確かめます。

# "; fully validated" と表示されれば検証成功
delv @1.1.1.1 example.com DNSKEY
delv @8.8.8.8 example.com A

# dig の場合は flags: の行に ad が付くか確認
dig @1.1.1.1 example.com A +dnssec

delv で ; unsigned answer と表示される場合は、親にDSが無く、署名が検証に使われていない状態です。DNSSECを有効にしたつもりなら、DSの登録が済んでいないか、まだ反映されていません。検証が失敗すると SERVFAIL が返ります。dig に +cd（検証なし）を付けて答えが返るかを比べると、DNSSECが原因かどうかを切り分けられます。

ステップ5：応答サイズとTCPでの応答を確かめる

見落とされがちなのが、DNSKEYの応答の大きさです。RSAの鍵を複数並べている場合や、鍵の更新中で新旧の鍵が同時に載っている場合、署名を含めた応答がUDPで送れる大きさを超えることがあります。2020年のDNSフラグデーでは、EDNSのバッファサイズとして1232バイトが推奨されました。これを超える応答は切り詰められ、リゾルバはTCPで問い合わせ直します。

# 応答サイズを確認（出力末尾の MSG SIZE rcvd）
dig @ns1.example.net example.com DNSKEY +dnssec +norecurse | grep "MSG SIZE"

# TCP でも応答が返るか
dig @ns1.example.net example.com DNSKEY +dnssec +norecurse +tcp

TCPの問い合わせが失敗する場合は、権威サーバー側のファイアウォールでTCPの53番ポートが閉じている可能性があります。UDPだけで答えられる小さな応答では気付かず、鍵の更新で応答が大きくなったときに初めて障害になる、というのが典型的なつまずき方です。ECDSA（アルゴリズム13）の鍵は短いので、応答サイズの面でも扱いやすい選択です。

点検のタイミングと記録

この点検は、次のタイミングで行うと効果があります。

DNSSECを有効にし、DSを登録した直後
KSKやZSKを更新したあと（とくにDSを差し替えたあと）
DNSサービスやDNSサーバーソフトウェアを移行・更新したあと
権威サーバーを追加・削除したあと

点検のたびに、key id・アルゴリズム・DSの値・署名の有効期限を記録しておくと、次に問題が起きたとき「いつから変わったか」をすぐにたどれます。図で連鎖を確認したいときは、DNSViz のような可視化ツールにドメインを入力すると、どの段階で問題があるかが色分けで表示されます。ツールの表示や判定の基準は更新されることがあります（2026年10月現在）。

まとめ

DNSKEYはフラグ（257=KSK、256=ZSK）・プロトコル（3）・アルゴリズム・公開鍵で構成され、key id で参照される
権威サーバーごとに直接問い合わせ、すべてで同じ鍵が返るかを確かめる
RRSIG DNSKEY のキータグがKSKを指し、期限内であることを確認する
dnssec-dsfromkey で計算したDSと、親に登録されたDSを4つの値で照合する
delv で fully validated になるか、応答が大きいときにTCPでも返るかまで確かめる