DSレコードが子ゾーンの鍵（DNSKEY）と一致していないと、DNSSECを検証するリゾルバ（Google Public DNS や Cloudflare の 1.1.1.1 など）はそのドメインを「改ざんの疑いあり」として SERVFAIL を返し、サイトもメールも一部の利用者から見えなくなります。直し方は、正しいDNSKEYから作ったDSをレジストラで登録し直すか、急ぎの場合はDSをいったん削除してDNSSECを外すかのどちらかです。この記事では、症状の確かめ方、DSとDNSKEYの照合方法、原因ごとの直し方と作業順序を説明します。
症状の見分け方：DNSSECが原因かどうか
DSの誤りによる障害には、「ある人には見えて、ある人には見えない」という特徴があります。DNSSECを検証しないリゾルバを使っている環境では普通に名前解決できるため、問題に気付くのが遅れがちです。次のように、検証ありと検証なしで結果を比べます。
# 検証するリゾルバに問い合わせる（失敗すると status: SERVFAIL）
dig @1.1.1.1 example.com A
# 同じ問い合わせを検証なし（+cd = Checking Disabled）で行う
dig @1.1.1.1 example.com A +cd通常の問い合わせが SERVFAIL で、+cd を付けると答えが返る場合は、DNSSECの検証失敗が原因です。新しめのリゾルバと dig では、応答に拡張DNSエラー（EDE、RFC 8914）が表示されることがあり、原因のヒントになります。たとえば EDE: 9 (DNSKEY Missing) はDSに対応する鍵が見つからない、EDE: 6 (DNSSEC Bogus) は検証に失敗した、という意味です。
より詳しく調べるには、BINDに付属する delv を使います。検証の過程でどこが失敗したかを表示してくれます。ブラウザで確認するなら、DNSViz のような可視化ツールで信頼の連鎖（親ゾーンのDS → 子ゾーンのDNSKEY → 署名）のどこが切れているかを図で確認できます。
DSとDNSKEYを照合する
DSは自分のゾーンではなく、親ゾーン（.com や .jp などのレジストリ）に登録されています。まず、親ゾーンに今どんなDSが載っているかと、自分のゾーンが公開しているDNSKEYを並べて確認します。
# 親ゾーンに登録されている DS（キータグ・アルゴリズム・ダイジェスト種別・ダイジェスト）
dig example.com DS +short
# 自分のゾーンの DNSKEY。+multiline で各鍵の key id（キータグ）が表示される
dig example.com DNSKEY +multiline
# 公開中の DNSKEY から、正しい DS を計算する（BIND の dnssec-dsfromkey）
dig example.com DNSKEY | dnssec-dsfromkey -f - example.comDSの4つの値は次のとおりです。
- キータグ: 対応する鍵の識別番号。
DNSKEY +multilineの出力のkey idと一致する必要があります - アルゴリズム: 鍵の種類。8（RSASHA256）、13（ECDSAP256SHA256）などで、DNSKEYのアルゴリズムと同じ値になります
- ダイジェスト種別: 2（SHA-256）が一般的です
- ダイジェスト: 鍵から計算したハッシュ値
照合するのは、DNSKEYのうちフラグが257の鍵（KSK、鍵署名鍵）です。dnssec-dsfromkey が出力したDSと、親ゾーンに登録されているDSのどれか1つが一致していれば、連鎖はつながっています。どれとも一致しなければ、そこが原因です。
よくある原因と直し方（多い順）
1. DNSサービスを移行したのに古いDSが残っている
もっとも多い原因です。DNSSECを有効にしていたDNSサービスから別のサービスへネームサーバーを切り替えると、新しいサービスは別の鍵で署名する（または署名しない）ため、親ゾーンに残った古いDSと一致しなくなります。
直し方は、レジストラの管理画面で古いDSを削除し、新しいサービスでDNSSECを有効にしてから、そのサービスが表示するDS情報を登録することです。移行前であれば、先にDSを外してから移行し、移行後に新しいDSを登録する順番にすると、障害を避けられます。
2. DSの値の入力ミス
レジストラの画面にDSを手入力した際の、ダイジェストのコピー漏れ、アルゴリズムやダイジェスト種別の選択違いです。たとえばダイジェスト種別で SHA-1 を選んだのに SHA-256 のダイジェストを貼り付けると、検証は失敗します。dnssec-dsfromkey の出力、またはDNSサービスが表示するDS情報と、1文字ずつ照合して入力し直します。レジストラによっては、DSではなく公開鍵（DNSKEY）そのものの入力を求める場合があるので、画面の指示を確認してください。
3. 鍵の更新（KSKロールオーバー）でDSの差し替えを忘れた
自前で署名している場合、KSKを新しくしたのに親ゾーンのDSを更新しないまま古い鍵を削除すると、DSが指す鍵が消えて連鎖が切れます。この場合は、新しいKSKからDSを計算して登録します。今後の更新では「新しいDSを登録する → 親ゾーンで反映を確認する → 古いDSのTTLが過ぎるのを待つ → 古い鍵を外す」の順を守ります。
4. DNSサービス側で署名をやめたのにDSが残っている
DNSサービスの設定でDNSSECをオフにしたのに、レジストラのDSを消し忘れた状態です。親は「このゾーンは署名されている」と主張しているのに署名が無いため、検証に失敗します。DNSSECを使い続けるなら署名を再開し、やめるならDSを削除します。
修正の作業順序と待ち時間
修正方法を選ぶときは、「早く復旧させたい」のか「DNSSECを維持したまま直したい」のかで分けます。
- 早く復旧させたい場合: DSを削除します。ゾーンは「署名なし」として扱われ、親ゾーンでDSが消え、リゾルバにキャッシュされた古いDSのTTLが切れると名前解決が戻ります。落ち着いてから、正しいDSで有効化し直します。
- 維持したまま直したい場合: 子ゾーンのDNSKEYが正しく公開されていることを確認してから、そこから計算したDSを登録し、古いDSを削除します。
どちらの場合も、レジストラで変更してから親ゾーンに反映されるまでには時間がかかり、反映後もリゾルバのキャッシュがDSのTTL分残ります。親ゾーンのDSのTTLは dig example.com DS の出力で確認できます。反映したかどうかは、親ゾーンの権威サーバーに直接問い合わせると、キャッシュに惑わされずに確認できます。
# .com の場合：親の権威サーバーに直接 DS を問い合わせる
dig @a.gtld-servers.net example.com DS +norecurse
# 修正後：検証するリゾルバで ad フラグ（検証成功）が付くか確認
dig @1.1.1.1 example.com A +dnssec.jp など他のトップレベルドメインでは、dig jp NS +short で親の権威サーバーを調べてから同じように問い合わせます。修正後、flags: の行に ad が付けば検証に成功しています。DSを削除してDNSSECを外した場合は ad は付かず、通常の応答が返れば復旧です。
設定変更の前には、現在のDSの値と、DNSサービスのDNSSEC設定画面の内容を控えておくと、問題が起きたときに戻せます。DSの登録方法や画面はレジストラによって大きく異なります（2026年10月現在）。
まとめ
- 検証あり・
+cd（検証なし）で結果が分かれれば、DNSSECの検証失敗が原因 - 親ゾーンのDSと、子ゾーンのKSK（フラグ257）から
dnssec-dsfromkeyで計算したDSを照合する - 多い原因は、DNSサービス移行時の古いDSの残存、入力ミス、鍵更新時の差し替え漏れ、署名停止後の消し忘れ
- 急ぐならDSを削除して復旧し、そのあと正しいDSで有効化し直す。反映とキャッシュの待ち時間を見込む
- 移行や鍵更新では、DSの登録・削除の順番を先に決めてから作業する