2026年6月11日

DNSSEC が動作しない場合のトラブルシューティング（DNS移転・鍵更新・DS登録編）

DNS・名前解決

DNSSEC は、設定した直後よりも「DNS 事業者を乗り換えた」「レジストラを移管した」「鍵を更新した」といった作業のあとに壊れることが多い仕組みです。原因はほぼ共通していて、親ゾーンの DS レコードと自ゾーンの鍵（DNSKEY）の切り替えの順番やタイミングがずれたことにあります。この記事では、作業別に壊れ方と確認方法、安全な手順を説明します。

いま起きている SERVFAIL の一般的な診断（+cd での切り分けや EDE の読み方）は、姉妹記事（SERVFAIL 診断編）で扱っています。こちらは「作業の前後で何が起きるか」と「次に壊さない手順」に重点を置いています。

誰が何を管理しているかを整理する

DNSSEC の鎖には、立場の違う3者が関わります。

DNS 事業者（またはあなたの権威サーバー）：ゾーンに署名し、DNSKEY と署名（RRSIG）を配信します。
レジストラ：ドメインを登録した会社です。あなたから受け取った DS の情報をレジストリに取り次ぎます。
レジストリ：.com や .jp などのトップレベルを運営する組織です。親ゾーンに DS を掲載します。

DS は「このドメインの正しい鍵はこれです」という親からの保証です。DNS 事業者とレジストラが別の会社だと、DNS 事業者側で鍵が変わっても DS は自動では変わりません。トラブルの大半はここから生まれます。

作業の前に、現状を記録しておきます。あとで比較したり、元に戻したりする基準になります。

# 現在の NS・DS・DNSKEY を保存しておく（example.com は自分のドメインに置き換える）
dig example.com NS +short      > before_ns.txt
dig example.com DS +short      > before_ds.txt
dig example.com DNSKEY +multi  > before_dnskey.txt

DS の TTL（キャッシュされる時間）は、親ゾーンの権威サーバーに直接聞くと分かります。.com なら gTLD のサーバー、.jp なら JPRS のサーバーに問い合わせます。

# 親ゾーンのサーバーを調べてから、そこに DS を直接聞く
dig com NS +short
dig @a.gtld-servers.net example.com DS +norecurse

応答の2列目の数字が TTL（秒）です。gTLD では1日程度のことが多く、この時間が各作業での「待ち時間」の基準になります。

ケース1：DNSSEC を有効にしたのに「有効になっていない」

DNS 事業者の管理画面で DNSSEC をオンにしただけでは、鎖はつながりません。レジストラで DS を登録して初めて有効になります。

確認は簡単です。dig example.com DS +short が何も返さなければ DS は未登録です。dig example.com A @1.1.1.1 +dnssec の flags: に ad が付かないことでも確認できます。

対処は、DNS 事業者の画面に表示される DS の値（key tag・アルゴリズム・ダイジェスト種別・ダイジェスト）をレジストラの管理画面に登録することです。レジストラによっては DS ではなく公開鍵（DNSKEY）の入力を求め、DS を自動計算する場合もあります。入力欄の名前や必要な項目は事業者ごとに違うので、レジストラのヘルプを確認してください。

なお、一部のレジストリや DNS 事業者は、CDS / CDNSKEY レコードを使って DS を自動で更新する仕組みに対応しています。使えるかどうかは TLD とレジストラの組み合わせで決まり、対応状況は変わり続けています（2026年10月現在）。自動化を前提にせず、登録後に dig で反映を確認する習慣をつけておくと安心です。

ケース2：DNS 事業者を乗り換えたらドメインが引けなくなった

最も影響が大きいのがこのケースです。DNSSEC を有効にしたまま NS を新しい事業者に切り替えると、親ゾーンには旧事業者の鍵を指す DS が残ったままになります。新しい事業者は別の鍵で署名する（あるいは署名しない）ため、検証するリゾルバからは「DS と鍵が合わない」と判定され、SERVFAIL になります。

すでにこの状態になっている場合の復旧は、次のどちらかです。

新しい事業者で DNSSEC を有効にし、表示された新しい DS にレジストラで差し替える
急ぐ場合は、レジストラで DS をいったん削除する（名前解決は「未保護」の状態で戻る）

どちらも、親ゾーンの DS の TTL が切れるまでは古い DS を覚えたリゾルバが残るため、すぐには全員に効きません。

次に乗り換えるときの安全な手順

署名の鍵を旧事業者から新事業者へ引き継げない一般的なマネージド DNS の場合、次の順番が無難です。少しの間 DNSSEC の保護がない期間が生じますが、ドメインが引けなくなる事態は避けられます。

新しい事業者にゾーンを作り、レコードを移して、新しい NS に直接 dig で問い合わせて内容を確認する
レジストラで DS を削除する
親ゾーンの DS の TTL と少しの余裕を待つ
レジストラで NS を新しい事業者のものに切り替える
NS の TTL を待ち、旧事業者を経由した問い合わせがなくなったことを確認する
新しい事業者で DNSSEC を有効にし、新しい DS をレジストラに登録する
dig +dnssec で ad フラグを確認し、旧事業者のゾーンを片付ける

保護のない期間を作らない方法として、両方の事業者が互いの鍵を載せ合う「マルチサイナー」構成（RFC 8901）もあります。ただし両事業者がこの運用に対応している必要があり、手順も複雑なので、対応可否を各事業者のドキュメントで確認したうえで検討してください。

ケース3：レジストラを移管したら DS が消えた・残った

ドメインを別のレジストラへ移管すると、DS がそのまま引き継がれる場合と、移管の過程で削除される場合があります。どちらになるかはレジストリと両レジストラの扱いによります。

特に注意したいのは、旧レジストラが提供していた DNS サービスを使っていた場合です。移管とともに旧レジストラの DNS が停止すると、DS は残ったまま署名するサーバーがなくなります。移管の前に DNS を移すのか、移管後に移すのかを決め、ケース2の順番を当てはめてください。移管の前後で dig example.com DS +short と NS を確認し、記録しておいた値と比べます。

ケース4：鍵の更新（ロールオーバー）のあとに検証が失敗する

自前の BIND や Knot DNS などで署名している場合、鍵の更新はタイミングの管理がすべてです。

ZSK（ゾーン署名鍵）の更新：DS は関係しません。新しい鍵を先に DNSKEY として公開し、DNSKEY の TTL を待ってから新しい鍵で署名を始め、古い署名の TTL が切れてから古い鍵を外します。この順番を飛ばすと、キャッシュに残った古い DNSKEY と新しい署名が合わずに失敗します。
KSK（鍵署名鍵）の更新：DS の差し替えが伴います。新しい KSK を公開し、レジストラで新しい DS を登録し、親ゾーンでの古い DS の TTL が過ぎてから古い KSK を外します。DS の差し替えを確認せずに古い KSK を外すのが典型的な失敗です。

BIND 9.16 以降の dnssec-policy を使えば、鍵の生成から公開、削除までを自動で進められます。ただし KSK の更新では、親ゾーンに新しい DS が載ったことを named に伝える必要があります。rndc dnssec -status example.com で鍵の状態を確認し、DS の掲載を確認したら rndc dnssec -checkds で知らせる、あるいは親ゾーンを自動で確認させる設定を使う、といった方法があります。オプションの書き方はバージョンで差があるため、使っている BIND のリファレンスマニュアルで確認してください。

アルゴリズムの変更（たとえば古い RSA 系から ECDSA へ）は、通常の鍵更新より手順が多く、順番を誤ると検証失敗になります。いきなり本番で行わず、検証用のドメインで流れを確かめてから進めてください。

ケース5：セカンダリだけ古い署名を配っている

鍵の更新や再署名のあと、セカンダリの権威サーバーへのゾーン転送が止まっていると、一部の NS だけが古い署名を返し続けます。いずれ期限が切れて、その NS に当たった問い合わせだけが失敗します。

# 各 NS の SOA シリアルと署名の有効期限を比べる
for ns in $(dig example.com NS +short); do
  echo "== $ns"
  dig @"$ns" example.com SOA +dnssec +norecurse | grep -E "SOA|RRSIG"
done

シリアルや RRSIG の日付が NS ごとにそろっているかを見ます。ずれていれば、転送の許可設定、NOTIFY、ファイアウォールを確認します。

作業後の監視を仕組みにする

作業のあとしばらくは、外部から定期的に確認すると、問題を早く見つけられます。次のスクリプトは、検証するリゾルバで失敗し、検証を外すと成功する、という「DNSSEC 起因の失敗」を検出したら終了コード1で知らせる例です。cron や監視ツールから呼び出す形に合わせて調整してください。

#!/bin/sh
# 使い方: ./check_dnssec.sh example.com
domain="$1"
st=$(dig "$domain" SOA @8.8.8.8 +time=5 +tries=2 | awk '/status:/{print $6}' | tr -d ',')
st_cd=$(dig "$domain" SOA @8.8.8.8 +cd +time=5 +tries=2 | awk '/status:/{print $6}' | tr -d ',')
if [ "$st" = "SERVFAIL" ] && [ "$st_cd" = "NOERROR" ]; then
  echo "DNSSEC validation failure: $domain"
  exit 1
fi
echo "ok: $domain ($st)"

自前で署名している場合は、これに加えて RRSIG の有効期限が近づいていないかも監視対象にすると、再署名の停止に早く気づけます。

まとめ

作業後の DNSSEC トラブルの多くは、DS（レジストラ側）と DNSKEY（DNS 事業者側）の切り替えのずれが原因
作業前に NS・DS・DNSKEY を記録し、親ゾーンの DS の TTL を確認しておく
DNS 事業者の乗り換えは「DS を外す → TTL を待つ → NS を切り替える → 新しい DS を登録する」の順が無難
レジストラの移管では、DS と DNS サービスの扱いを事前に確認する
鍵の更新は TTL を基準に段階的に進め、KSK の更新では DS の差し替えを確認してから古い鍵を外す