DNSSEC のトラブルは、多くの場合「一部の利用者だけサイトやメールに届かない」という形で現れます。原因の切り分けは、検証を行う公開リゾルバで SERVFAIL が返るか、検証を止める +cd を付けると答えが返るかを見るところから始まります。この記事では、症状の読み方、よくある原因を起こりやすい順に、それぞれの確認コマンドと直し方を説明します。
DNS 事業者の乗り換えや鍵の更新といった「作業のあとに壊れた」ケースの手順は、姉妹記事（DNS移転・鍵更新・DS登録編）で扱います。ここでは、いま目の前で起きている検証エラーの診断に絞ります。
まず症状を見分ける：「検証失敗」か「そもそも署名が効いていない」か
「DNSSEC が動作しない」には、性質のまったく違う2つの状態が含まれます。
- 検証失敗（bogus）：署名の鎖のどこかが壊れていて、検証するリゾルバが応答を捨てて
SERVFAILを返す状態です。Google Public DNS（8.8.8.8）や Cloudflare（1.1.1.1）を使う利用者からはドメインが引けなくなるため、サイトもメールも止まります。急ぎの対応が要るのはこちらです。 - 未保護（insecure）：DNS 事業者側で署名は有効にしたものの、親ゾーンに DS レコードが登録されていないなどで、鎖がつながっていない状態です。名前解決は普通にできるので気づきにくいのですが、DNSSEC の保護は効いていません。
どちらなのかは、次の3つのコマンドでほぼ判定できます。example.com は自分のドメインに置き換えてください。
# 1. 検証するリゾルバに普通に問い合わせる
dig example.com A @8.8.8.8
# 2. 検証を無効にして（CDビット）同じ問い合わせをする
dig example.com A @8.8.8.8 +cd
# 3. 検証済みの印（adフラグ）が付くかを見る
dig example.com A @1.1.1.1 +dnssec1 が status: SERVFAIL で、2 が status: NOERROR と正しい IP を返すなら、原因は DNSSEC の検証失敗です。レコードの値そのものは正しく、署名の鎖が壊れています。1 も 2 も同じように失敗するなら、DNSSEC 以前に権威サーバーや NS の設定を疑います。
3 の出力の flags: 行に ad があれば検証に成功しています。エラーは出ないのに ad が付かないなら「未保護」の状態です。
拡張エラー（EDE）で原因の手がかりを得る
Cloudflare の 1.1.1.1 など、Extended DNS Errors（RFC 8914）に対応したリゾルバは、SERVFAIL に理由を添えて返します。比較的新しい dig（BIND 9.16 系以降が目安）なら、出力の OPT PSEUDOSECTION に EDE: 行が表示されます。
; EDE: 7 (Signature Expired)
; EDE: 9 (DNSKEY Missing)
; EDE: 6 (DNSSEC Bogus)主なコードの意味は次のとおりです。6 は「検証に失敗」という総称、7 は署名の有効期限切れ、8 は署名の有効期間がまだ始まっていない、9 は DS に対応する DNSKEY が見つからない、10 は署名（RRSIG）が無い、です。リゾルバによって返すコードの細かさは違うので、手がかりの一つとして扱ってください。
図で確認できるツールも併用する
コマンドに加えて、DNSViz（dnsviz.net）のように親ゾーンから自ゾーンまでの鎖を図で表示するサービスを使うと、どの段で切れているかが一目で分かります。BIND に付属する delv も便利で、delv example.com A と打つと、検証に成功すれば fully validated、失敗すれば理由つきのエラーが表示されます。
原因1：親ゾーンの DS と自ゾーンの DNSKEY が一致していない
もっとも多いのがこのパターンです。DS レコードはドメインの登録事業者（レジストラ）経由で親ゾーンに登録され、DNSKEY は DNS 事業者が持つ鍵から作られます。管理する会社が別々なので、片方だけが変わるとずれが生じます。DNS 事業者を乗り換えた、DNSSEC を一度無効にして再度有効にした（その際に新しい鍵が作られた）、といった操作のあとに起こりがちです。
確認は、DS が指している鍵のタグ（key tag）と、実際に公開されている DNSKEY のタグを比べます。
# 親ゾーンに登録されている DS（左から key tag / アルゴリズム / ダイジェスト種別 / ハッシュ）
dig example.com DS +short
# 自ゾーンの DNSKEY（+multi で key id が表示される）
dig example.com DNSKEY +multi
# 公開中の DNSKEY から DS を計算して、登録済みの DS と比べる（BIND 付属ツール）
dig +noall +answer example.com DNSKEY | dnssec-dsfromkey -f - example.comDNSKEY の出力で key id = 12345 のように表示される番号（フラグ 257 の鍵、いわゆる KSK）と、DS の先頭の数字が一致しているか、さらにハッシュ値が一致しているかを見ます。一致しなければ、レジストラの管理画面で DS を DNS 事業者が表示している最新の値に差し替えます。DNS 事業者の画面には、DS の値またはその元になる公開鍵が表示されているはずです。
DS の差し替えが反映されるまでには、親ゾーンでの DS の TTL ぶん（gTLD では1日程度のことが多い）、古い情報がリゾルバに残る場合があります。
原因2：署名（RRSIG）の有効期限が切れている
自前の BIND・Knot DNS・PowerDNS などでゾーンに署名している場合に起こります。署名には有効期限があり、自動での再署名が止まっていると、ある日突然すべての問い合わせが検証失敗になります。EDE 7 が返る場合はまずこれを疑います。
# 権威サーバーに直接聞いて RRSIG の有効期限を確認する
dig @ns1.example.com example.com SOA +dnssec +norecurseRRSIG 行に並ぶ2つの14桁の数字は、署名の有効期限と開始時刻（UTC）です。前の数字が現在時刻より過去なら期限切れです。
直し方は、署名を作り直して、再署名の自動化が止まった理由を潰すことです。BIND 9.16 以降の dnssec-policy を使っているなら、rndc dnssec -status example.com で鍵の状態を確認し、named のログで鍵ファイルの読み込みや書き込みのエラーが出ていないかを見ます。鍵ファイルのディレクトリの権限変更や、ディスクの空き不足が引き金になることがあります。
原因3：権威サーバーの一部だけ古い・署名のないゾーンを返している
NS が複数あり、セカンダリへのゾーン転送が止まっている、あるいは一部のサーバーだけ署名前のゾーンを配っている、というケースです。リゾルバはどの NS に聞くか毎回選ぶため、症状が「ときどき失敗する」形になります。
# NS を一覧して、それぞれに直接問い合わせる
dig example.com NS +short
dig @ns1.example.com example.com SOA +norecurse +short
dig @ns2.example.com example.com SOA +norecurse +short
dig @ns2.example.com example.com DNSKEY +norecurse +shortSOA のシリアル番号が NS ごとに違う、特定の NS だけ DNSKEY を返さない、といった差があればそのサーバーが原因です。ゾーン転送の設定（転送元の許可、通知、ファイアウォール）を見直します。
原因4：存在しない名前や一部のレコードだけ検証に失敗する
トップページは表示できるのに、新しく作ったサブドメインや存在しない名前の問い合わせだけ SERVFAIL になる場合は、「存在しないこと」の証明（NSEC / NSEC3）に問題がある可能性があります。署名ソフトの不具合や、署名後のゾーンを手で編集したことが原因になりえます。
dig no-such-name.example.com A @8.8.8.8
dig no-such-name.example.com A @8.8.8.8 +cd前者だけが失敗するなら、ゾーンを署名し直して様子を見ます。マネージド DNS を使っている場合は、事業者のサポートに上記の結果を添えて問い合わせるのが近道です。
原因5：自分のサーバー側のリゾルバに問題がある
外部の利用者には問題がなく、WordPress を動かしているサーバーから外部 API への接続や更新の確認だけが失敗する、という場合は、そのサーバーが使っている検証リゾルバ（Unbound など）を疑います。
- 時刻のずれ：サーバーの時計が大きく狂っていると、正しい署名でも「期限切れ」や「まだ有効でない」と判定されます。
timedatectlで時刻同期が有効かを確認します。 - トラストアンカーが古い：ルートゾーンの鍵（トラストアンカー）を手で固定していると、ルート鍵の更新についていけません。配布パッケージの自動更新の仕組み（Unbound なら
auto-trust-anchor-fileなど）を使います。 - 大きな応答が届かない：DNSSEC の応答はサイズが大きく、途中の機器が UDP の大きなパケットや断片化されたパケットを落とすと失敗します。
dig example.com DNSKEY +dnssec +tcpが成功し、TCP なしでは失敗するなら、TCP 53 番の許可や EDNS のバッファサイズを見直します。
応急処置：サイトが止まっているときは DS を外す順番を守る
検証失敗でサイトやメールが止まっていて、原因の特定に時間がかかりそうなときは、DNSSEC をいったん外して復旧させるのが現実的です。そのときの順番が大切です。
- まずレジストラで DS レコードを削除する
- 親ゾーンの DS の TTL が過ぎるまで待つ
- そのあとで DNS 事業者側の署名を無効にする
逆に、DS を残したまま先に署名（DNSKEY）を止めると、「DS はあるのに鍵がない」状態になり、かえって全面的な検証失敗を招きます。DS を外したあとは「未保護」の状態になるので、原因を直したら改めて DNSSEC を有効にし、新しい DS を登録し直してください。
修正後、公開リゾルバに古い失敗結果が残っている場合は、Google Public DNS の「Flush Cache」ページや、Cloudflare の 1.1.1.1 のキャッシュ削除ページから個別に消去を依頼できます（2026年10月現在）。各ページの表記や手順は変わることがあるので、画面の案内に従ってください。
作業前に控えておきたいこと
DNS の変更は、どの操作も影響範囲がドメイン全体に及びます。作業前に、現在の DS・DNSKEY・主要なレコードを dig で取得してテキストに保存しておくと、元に戻すときの手がかりになります。自前の権威サーバーなら、ゾーンファイルと鍵ファイルのバックアップも取っておきます。鍵ファイル（秘密鍵）は Web から見える場所や Git リポジトリに置かないでください。
まとめ
- 「DNSSEC が動作しない」は、検証失敗（SERVFAIL）と未保護（ad フラグなし）の2種類に分けて考える
dig @8.8.8.8とdig @8.8.8.8 +cdの結果の違いで、DNSSEC が原因かどうかを判定できる- 原因で多いのは、DS と DNSKEY の不一致、署名の期限切れ、一部の権威サーバーの不整合の順
- EDE のコード、DNSViz、delv を併用すると、壊れている段を特定しやすい
- 応急処置で外すときは「DS を先に削除し、TTL を待ってから署名を止める」の順番を守る