DNSSEC は「DNS サーバー側でゾーンに署名する」作業と「レジストラに DS レコードを登録する」作業の2段階で有効になります。順番を間違えたり、DNS 事業者を変えるときに DS を消し忘れたりすると、検証するリゾルバーからドメインが丸ごと引けなくなるため、手順そのものより順序と後片付けが重要です。この記事では、有効化の流れ、確認コマンド、トラブル時の切り分け、無効化や移転のときの注意点を説明します。
DNSSEC で何が守られ、何が守られないか
DNSSEC は、DNS の応答に電子署名を付け、受け取った側（検証リゾルバー）が「その応答が正規のゾーン管理者から来た改ざんされていないものか」を確かめられるようにする仕組みです。キャッシュポイズニングのように、偽の応答を混ぜて利用者を別のサーバーへ誘導する攻撃への対策になります。
信頼の連鎖は、ルートゾーン → TLD（.com や .jp）→ 自分のドメイン、という順に親が子の鍵を保証する形でつながります。自分のドメインの鍵（DNSKEY）を親の TLD に保証してもらうために登録するのが DS レコードです。
一方で、DNSSEC は通信内容を暗号化しません。問い合わせ内容を隠したい場合は DNS over HTTPS / TLS の領域です。また、Web サイトの HTTPS や WordPress 自体の脆弱性対策の代わりにもなりません。導入の目的が「DNS 応答の真正性の確認」であることを押さえておくと、期待外れを防げます。
有効化する前に確認すること
DNS 事業者とレジストラの対応状況
DNSSEC には、ゾーンを持っている DNS 事業者（権威 DNS）が署名に対応していること、レジストラが DS レコードの登録を受け付けること、TLD のレジストリが DNSSEC に対応していることの3つが必要です。主要な gTLD や .jp は対応していますが、レジストラによっては DS の登録画面がなかったり、サポートへの申請が必要だったりします。主要なクラウド DNS の多くは署名に対応していますが、対応状況や手順は変わることがあるため、各社の案内で確認してください（2026年10月現在）。
DNS 事業者とレジストラが同じ会社で、かつそのレジストラ管理下のドメインであれば、DS の登録まで自動で済むこともあります。たとえば Cloudflare で DNS とレジストラの両方を使っている場合はこの形になります。
近いうちに DNS 事業者を変える予定がないか
DNSSEC を有効にした状態で DNS 事業者を移ると、移転先の鍵が親の DS と一致せず検証に失敗します。移転を予定しているなら、移転を済ませてから有効化するほうが安全です。
TTL を把握しておく
DS レコードは親（TLD）のゾーンに置かれ、その TTL は TLD 側が決めます。.com などでは1日程度の値になっていることが多く、間違った DS を登録すると、修正しても古い DS がキャッシュから消えるまで影響が残ります。次のコマンドで現在の値を見ておきます。
# 親ゾーンに置かれた NS / DS とその TTL を確認
dig example.com NS +noall +answer
dig example.com DS +noall +answer有効化の手順
1. DNS 事業者側でゾーンの署名を有効にする
DNS 事業者の管理画面で DNSSEC を有効にします。多くのサービスでは、鍵の生成や署名の更新（再署名・鍵の交換）を事業者が自動で行います。画面の項目名は事業者ごとに異なり、変わることもあるため、「DNSSEC」「署名」といった項目を探してください。
Amazon Route 53 のように、署名用の鍵（KSK）の管理に別サービスの鍵（AWS KMS のカスタマー管理キー）を用意する必要があるサービスもあります。前提条件は各サービスのドキュメントで確認します。
有効にすると、DS レコードとして登録する値（キータグ、アルゴリズム番号、ダイジェストタイプ、ダイジェスト）が表示されます。アルゴリズムは 13（ECDSA P-256 / SHA-256）や 8（RSA/SHA-256）がよく使われ、ダイジェストタイプは 2（SHA-256）を使うのが一般的です。SHA-1 のダイジェスト（タイプ 1）は推奨されなくなっています。
自前の BIND などで運用している場合は、インラインサイニング等の設定で署名を行いますが、鍵の交換や署名の期限切れの管理まで自分で担うことになるため、運用体制を整えてから導入します。
2. 署名された応答が返っているか確かめる
DS を登録する前に、権威 DNS が DNSKEY と署名（RRSIG）を返しているかを確認します。
# DNSKEY が返るか（ns1.example-dns.net は自分の権威DNSに置き換え）
dig @ns1.example-dns.net example.com DNSKEY +multi
# A レコードに RRSIG が付いているか
dig @ns1.example-dns.net example.com A +dnssecここで DNSKEY が返らないうちに DS を登録すると、検証リゾルバーからは「署名があるはずなのに無い」状態に見えてしまいます。
3. レジストラに DS レコードを登録する
レジストラの管理画面で、DNS 事業者が表示した値をそのまま入力します。DS の値そのものを入れる方式と、DNSKEY（公開鍵）を入れてレジストラ側で DS を作る方式があります。どちらの形式を求められているかを確かめ、キータグやアルゴリズム番号を取り違えないようにします。
一部の TLD とレジストラでは、DNS 事業者が公開する CDS / CDNSKEY レコードを読み取って DS を自動で更新する仕組みにも対応しています。使えるかどうかは組み合わせ次第です。
4. 検証が通るかを確認する
DS が親ゾーンに反映されたら、検証するリゾルバーを使って確認します。
# 親に DS が載ったか
dig example.com DS +short
# 検証リゾルバー経由で ad フラグ（検証済み）が付くか
dig @1.1.1.1 example.com A +dnssec | grep flags
# delv（BIND 付属）で検証結果を表示
delv example.com Aflags: の行に ad が含まれ、delv で fully validated と表示されれば、信頼の連鎖がつながっています。ブラウザで使える DNSViz や Verisign の DNSSEC Analyzer では、連鎖のどこで切れているかを図や一覧で確認できます。
うまくいかないときの切り分け
DNSSEC の不具合は「一部の利用者だけが見られない」形で現れることが多いのが厄介な点です。検証を行うリゾルバー（Google Public DNS、Cloudflare の 1.1.1.1、多くの携帯キャリアや企業の DNS など）では SERVFAIL になり、検証しないリゾルバーでは普通に引けてしまいます。
# 通常の問い合わせで SERVFAIL、+cd（検証を無効化）で引けるなら DNSSEC が原因
dig @8.8.8.8 example.com A
dig @8.8.8.8 example.com A +cd原因は、よく見られる順に次のとおりです。
- DS と DNSKEY の不一致: 入力ミスや、鍵を作り直したのに DS を更新していないケース。
dig example.com DSのキータグと、dig example.com DNSKEYに含まれる鍵が対応しているかを DNSViz で確認し、正しい DS に差し替えます。 - DNS 事業者側で署名を止めたのに DS が残っている: 署名をやめた、または DNS 事業者を移ったのに、レジストラの DS を削除していないケース。DS を削除し、親の TTL が切れるまで待ちます。
- 署名の期限切れ: 自前運用で再署名が止まっているケース。RRSIG の有効期限を確認し、署名処理を再開します。
- 一部のネームサーバーだけ署名していない: 複数の DNS 事業者を併用している場合などに起こります。すべての NS に対して上の dig を実行して比べます。
無効化や DNS 事業者の移転で失敗しないために
DNSSEC で最も事故が起きやすいのは、有効化ではなく「やめるとき」と「移るとき」です。
無効化は有効化の逆順で行います。まずレジストラで DS を削除し、親ゾーンの DS の TTL ぶん（目安として1〜2日）待ってから、DNS 事業者側の署名を止めます。先に署名を止めると、キャッシュに残った DS と食い違って、その間は検証リゾルバーから引けなくなります。
DNS 事業者の移転では、いったん上の手順で DNSSEC を無効化し、移転を終えてから移転先で改めて有効化するのが分かりやすい方法です。両方の事業者の鍵を一時的に公開して無停止で移す方法もありますが、両事業者の対応が必要で手順も複雑になります。ネームサーバーの変更そのものの注意点は、下の関連記事も参考にしてください。
ドメインを第三者に譲渡する場合や、レジストラを移管する場合も、DS の扱いを事前に確認しておきます。移管の手続き中に DS が消えたり残ったりして、新しい環境と食い違うことがあるためです。
まとめ
- DNSSEC は「DNS 事業者での署名」と「レジストラへの DS 登録」の2段階で、署名が返ることを確かめてから DS を登録します。
- 確認は
dig +dnssecのadフラグ、delv、DNSViz で行います。 - 検証リゾルバーだけで SERVFAIL になる場合は、
+cdで比べて DNSSEC が原因かを切り分けます。 - 無効化は DS 削除 → TTL を待つ → 署名停止の順。DNS 事業者を移るときもこの順序を守ります。
- DNSSEC は暗号化ではなく応答の真正性の確認です。HTTPS やサイト自体の対策は別に必要です。