DNSSEC の署名チェック手順｜自分のゾーンの RRSIG・DS と DNSKEY の対応・期限切れの兆候を確かめる

DNSSEC の署名チェックは、「外から見て検証が通るか」「親ゾーンの DS と自分の DNSKEY が対応しているか」「すべての権威DNSが有効な署名を返しているか」「署名の期限が近づいていないか」の4点を順に確かめるのが基本です。この記事では、DNSSEC を有効にしたドメインの管理者が、自分のゾーンの署名が正しく機能しているかを delv・dig・DNSViz・ゾーン検証ツールで点検する手順と、見つかった問題ごとの直し方を説明します。

リゾルバー側で検証を有効にする手順は同じサイトの「DNSSEC の検証手順」で扱っています。この記事は署名する側（ゾーンを持つ側）の点検に絞っています。

署名チェックで見るもの

DNSSEC では、ゾーン内の各レコードの集まりに RRSIG（署名）が付き、その署名を DNSKEY（公開鍵）で検証します。DNSKEY が本物であることは、親ゾーン（例えば .com）に登録した DS レコードで保証されます。どこか1か所でも対応が崩れると、検証するリゾルバーはそのドメインを SERVFAIL として扱い、利用者からはサイトやメールが届かないように見えます。

署名の問題は、署名を作るプログラムの停止、鍵の入れ替えや DNS 事業者の移転の手順の誤り、一部の権威DNSへの反映漏れなどで起きます。いずれも、気づいたときには影響が出ていることが多いため、定期的な点検が役に立ちます。

手順1：外から見て検証が通るかを確かめる

まず全体像として、検証が通るかを確かめます。BIND に付属する delv は、ルートのトラストアンカーを使って自分で検証し、結果を表示します。

delv example.com SOA

出力に「fully validated」と表示されれば、ルートから自分のゾーンまでの信頼の連鎖が通っています。「resolution failed」などと表示される場合は、手順2以降で原因を絞ります。

検証を行うリゾルバー経由で確かめる方法もあります。

dig +dnssec @9.9.9.9 example.com SOA

フラグ欄に ad があれば、そのリゾルバーで検証に成功しています。SERVFAIL になる場合は、+cd（検証を無効にする指定）を付けて再度問い合わせ、応答が返るなら DNSSEC の検証で失敗していると判断できます。

視覚的に確かめたいときは、DNSViz（dnsviz.net）でドメインを解析すると、ルートから自分のゾーンまでの鍵と署名の関係が図で表示され、問題のある箇所に警告が付きます。

手順2：DS と DNSKEY の対応を確かめる

親ゾーンに登録された DS と、自分のゾーンで公開している DNSKEY が対応しているかを確認します。

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

# 自分のゾーンの DNSKEY（+multi で鍵の種類と key id が表示される）
dig +multi DNSKEY example.com

+multi の出力では、各 DNSKEY の行に KSK か ZSK か、アルゴリズム、key id（鍵タグ）がコメントとして表示されます。DS の1つ目の数字は key tag なので、DS の key tag と一致する KSK が DNSKEY の中にあるかを見ます。

さらに、DNSKEY から DS を計算して比べると確かです。BIND の dnssec-dsfromkey を使う例です。

dig +noall +answer DNSKEY example.com > dnskey.txt
dnssec-dsfromkey -2 -f dnskey.txt example.com

-2 は SHA-256 のダイジェストを出す指定です。出力された DS の値が、親ゾーンの DS と一致していれば対応は正しく取れています。オプションの名前は BIND の版によって異なることがあるため、手元の dnssec-dsfromkey -h で確認してください。ldns を使っている環境なら ldns-key2ds でも同じ計算ができます。

手順3：すべての権威DNSの署名を確かめる

権威DNSが複数あるとき、1台だけ古いゾーンや署名されていないゾーンを返していると、リゾルバーによって結果が変わる分かりにくい障害になります。権威DNSに1台ずつ直接問い合わせて比べます。

for ns in $(dig +short NS example.com); do
  echo "== $ns"
  dig +norec +dnssec +noall +answer @"$ns" example.com SOA
done

各サーバーで、SOA のシリアル番号が同じであること、RRSIG が付いていること、署名の期限（後述）が同じ程度であることを確かめます。セカンダリーのシリアル番号が古いままなら、ゾーン転送（AXFR や IXFR）が止まっていないかを確認します。

存在しない名前の応答も確かめる

DNSSEC では、存在しない名前に対しても「存在しないこと」を NSEC または NSEC3 レコードと署名で証明します。

dig +dnssec @9.9.9.9 no-such-name.example.com A

ステータスが NXDOMAIN で、ad が付き、権威セクションに NSEC か NSEC3 とその RRSIG が含まれていれば正常です。ここで SERVFAIL になる場合は、否定応答の署名に問題があります。

手順4：署名の期限を確かめる

RRSIG には有効期間があり、署名を作るプログラムが定期的に作り直さないと期限が切れます。期限切れは、署名側のプロセスが止まっていたり、自動署名の設定が外れていたりしたときに起きる、気づきにくい障害です。

dig +noall +answer で RRSIG を表示すると、9列目が期限、10列目が開始時刻（いずれも UTC の YYYYMMDDHHMMSS 形式）です。次のスクリプトは、各権威DNSの SOA に付いた RRSIG の期限を調べ、指定した日数以内に切れるものがあれば警告します。GNU の date を使う前提です。

#!/bin/sh
# 使い方: ./rrsig-check.sh example.com 5
ZONE="$1"
DAYS="${2:-5}"
LIMIT=$(( $(date -u +%s) + DAYS * 86400 ))
STATUS=0

for ns in $(dig +short NS "$ZONE"); do
  for exp in $(dig +norec +dnssec +noall +answer @"$ns" "$ZONE" SOA | awk '$4 == "RRSIG" {print $9}'); do
    ts=$(echo "$exp" | sed -E 's/^(....)(..)(..)(..)(..)(..)$/\1-\2-\3 \4:\5:\6/')
    exp_s=$(date -u -d "$ts" +%s)
    if [ "$exp_s" -lt "$LIMIT" ]; then
      echo "WARN: $ns の RRSIG が $ts (UTC) に期限切れになります"
      STATUS=1
    else
      echo "OK: $ns 期限 $ts (UTC)"
    fi
  done
done
exit $STATUS

cron や監視ツールから定期的に実行し、終了コードが1のときに通知するようにしておくと、期限切れの前に気づけます。SOA 以外に、DNSKEY や主要なレコード（A、MX、TLSA など）も対象にするとより安心です。

開始時刻（10列目）が未来になっている場合は、署名したサーバーの時計がずれている可能性があります。署名側のサーバーで NTP の同期状態を確認してください。

手順5：ゾーンファイル全体を検証する

ゾーンファイルを自分で管理している場合は、署名済みのゾーン全体を検証ツールにかけられます。

# BIND
dnssec-verify -o example.com db.example.com.signed

# ldns
ldns-verify-zone db.example.com.signed

Knot DNS の kzonecheck にも DNSSEC の検証機能があります。どのツールも、署名の欠け、期限切れ、NSEC/NSEC3 の連鎖の不整合などを報告します。クラウドの DNS サービスなどでゾーンファイルを直接扱えない場合は、手順1〜4の外からの点検と DNSViz を組み合わせます。

問題が見つかったときの直し方

• DS と DNSKEY が対応していない：鍵の入れ替えや DNS 事業者の移転の後に起きやすい問題です。現在の KSK に対応する DS をレジストラーの管理画面などで登録し、対応する鍵の無くなった古い DS を削除します。登録しても、リゾルバーのキャッシュに古い DS が残っている間（親ゾーンの DS の TTL の間）は失敗が続くことがあるため、すぐに解消しなくても慌てずに経過を見ます。鍵の入れ替えの途中であれば、古い鍵を先に消さず、新旧の DS と DNSKEY が併存する期間を設けるのが手順の基本です。
• 署名の期限が近い・切れている：署名を作るプログラム（BIND の dnssec-policy、Knot DNS の自動署名、OpenDNSSEC など）が動いているかを確かめ、再署名させます。期限切れの状態が続くと検証するリゾルバーから引けなくなるため、優先して対応します。
• 一部の権威DNSだけ古い：ゾーン転送のエラーをログで確認し、セカンダリーにゾーンを再転送させます。
• どうしても短時間で直せない：最後の手段として、親ゾーンの DS を削除して DNSSEC を一時的に無効にする方法があります。ただし DS の TTL の間は影響が残り、再有効化にも手順が必要です。判断の前に、現在のゾーンと鍵のバックアップを取っておいてください。

DNS 事業者の管理画面の表記や自動署名の機能は、事業者ごと・時期ごとに異なります（2026年10月現在）。作業前に利用している事業者の案内を確認してください。

まとめ

• delv の「fully validated」や公開リゾルバーの ad で、外から検証が通るかを最初に確かめる。
• 親ゾーンの DS と自分の DNSKEY の key tag・ダイジェストが対応しているかを確かめる。
• 権威DNSに1台ずつ問い合わせ、シリアル番号と RRSIG がそろっているか、否定応答も署名されているかを見る。
• RRSIG の期限を定期的に調べ、期限が近づいたら通知する仕組みを置く。
• ゾーンファイルを持っているなら、dnssec-verify や ldns-verify-zone でゾーン全体を検証する。

• DNSSEC を有効にする手順
• DNSViz の使い方