DNSSECとは？有効化前の確認とDS不一致で開かないときの対処

先に答え：DNSSECはDNS応答の出所と改ざんを検証する仕組み

DNSSECはDNSデータに電子署名を付け、検証側が「権威DNSから出た応答か」「途中で内容が変えられていないか」を確かめる仕組みです。RFC 4033は、DNSSECがデータの出所認証と完全性を提供する一方、通信内容の機密性は提供しないと説明しています。つまり、DNSSECを有効にしても通信が暗号化されるわけではなく、HTTPSの代わりにはなりません。

画像を拡大 ↗

DNSSEC、HTTPS、暗号化DNSの守る範囲を3列で比較した図。閉じる ×

似た用語を役割ごとに分けています。

一般的な利用では、DNS事業者がゾーンを署名し、ドメイン登録事業者側を通じて親ゾーンにDSレコードを登録します。ICANNは、ルートから子ゾーンへ署名をたどる関係を「信頼の連鎖」と説明しています。DNS事業者と登録事業者が同じ場合は自動化されることもありますが、別の場合はDSの値を自分で転記する手順が必要です。

DNSKEYとDSは、別の場所にある一組の情報

DNSKEYは署名検証に使う公開鍵の情報として対象ゾーン側に置かれます。DSはそのDNSKEYを要約した情報で、親ゾーン側に置かれます。検証するリゾルバーは、親側のDSと子側のDNSKEYをたどって応答を検証します。

画像を拡大 ↗

親ゾーンのDS、対象ゾーンのDNSKEY、署名付きDNS応答のつながり。閉じる ×

DSとDNSKEYの不一致が障害になる関係を簡略化しています。

DSだけを古いまま残して権威DNSの鍵を変えると、検証側は正しい署名を確認できません。Cloudflareの資料では、古いDSのTTLが切れる前にネームサーバーを変更すると、キャッシュされたDSと新しい鍵が一致せず、検証するリゾルバーがSERVFAILを返す危険が示されています。

有効化前に、管理場所と戻し方を記録する

次の項目が分からないまま「有効化」を押さないことが重要です。秘密鍵そのものを作業表や問い合わせ文へ貼り付ける必要はありません。

画像を拡大 ↗

DNSSEC有効化前に登録事業者、権威DNS、DS、DNSKEY、TTL、戻す条件を記録する表。閉じる ×

秘密鍵は作業表へ記録しません。

有効化後は、管理画面の「有効」の表示だけで終わらせず、外部からDS・DNSKEY・通常のA/AAAA等が取得できるかを確認します。Cloudflare Registrarでは自動反映に1〜2日かかる場合があると案内されています。利用する事業者の反映時間を確認し、完了前に別のDNS変更を重ねない方が原因を切り分けやすくなります。

ネームサーバー変更時は、DNSSECを別作業として扱う

DNSSECが有効なドメインを別のDNS事業者へ移すときは、Web向けAやCNAMEのコピーだけでは足りません。旧DSと新DNS側の鍵が一致しない時間を作らない移行方式が使えるか、両事業者の手順を確認します。

一般的な安全確認の流れは次のとおりです。

1. 現在のDS、DNSKEY、TTL、ネームサーバーを記録する。
2. 移行元・移行先の両方がDNSSECを維持した移行に対応するか確認する。
3. 対応しない場合は、移行元の案内に従い親側のDSを先に削除する。
4. DSのTTLが切れたことを確認してからネームサーバーを変更する。
5. 新DNSが正常に応答することを確認し、新しいDNSSECを有効化してDSを登録する。
6. 主要なDNSレコードとWeb・メールの動作を確認する。

これはCloudflareの一般的な移行例をもとにした作業順です。実際の操作名や自動化範囲は登録事業者・DNS事業者・TLDで異なります。対応資料が見つからない場合は、値を推測せず両社へ確認します。

SERVFAILが出たときは「DNSSEC原因か」を比較する

サイトが急に開かず、DNS問い合わせがSERVFAILになる場合、原因はDNSSECとは限りません。Cloudflareは、通常の検証付き問い合わせではSERVFAILだが、+cdで検証を無効にした問い合わせでは応答が得られる場合、DNSSEC設定不整合を疑う手順を示しています。

dig A example.com @1.0.0.1
dig A example.com @1.0.0.1 +dnssec +cd
dig DS example.com
dig DNSKEY example.com

画像を拡大 ↗

通常のDNS問い合わせではSERVFAIL、検証を無効にした比較では応答がある場合の切り分け図。閉じる ×

+cdの結果は安全な応答の証明ではなく、原因を絞る比較材料です。

このコマンド例は自分が管理するドメインの調査用です。+cdの結果が得られても、それ自体が安全な応答であることを証明するわけではありません。比較材料として使い、登録事業者にあるDSと権威DNSが示す値を照合します。

問い合わせ用テンプレート

対象ドメイン：example.com
発生日時：2026-10-12 15:20 UTC
直前の変更：ネームサーバー変更／DNSSEC有効化／DS更新（該当を記載）
通常のDNS問い合わせ：SERVFAIL／応答あり
+cdを付けた問い合わせ：応答あり／なし
現在のNS：＿＿＿＿
登録事業者側のDS：＿＿＿＿
権威DNS側のDNSSEC状態：＿＿＿＿
確認した回線・リゾルバー：＿＿＿＿
希望：DSとDNSKEYの一致、および安全な復旧順の確認

「とりあえずDSを削除」「とりあえず署名を停止」のどちらか一方だけを先に行うと、状態を悪化させる場合があります。復旧時も、親側のDSと子側の署名の関係、TTL、事業者の手順をそろえて判断します。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後に何を自分で変更できるかを確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。DNS・メール・計測の設定が通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝えて対応範囲を確認してください。

関連記事

[DNSレコードの種類と役割](/articles/dns-record-types-practical)・[DNSのTTLとサーバー切り替え](/articles/dns-ttl-before-server-move)