DNSSEC を導入してドメインのセキュリティを強化する設定手順と運用の注意点

DNSSEC の導入は「DNS 事業者でゾーンの署名を有効にする → 表示された DS レコードをレジストラに登録する → 検証が通ることを確認する」の3段階で終わります。作業自体は短時間で済みますが、本当に気をつけるべきなのは導入後の運用で、特に DNS 事業者の乗り換えや DNSSEC の無効化を誤った順番で行うと、サイトもメールも名前解決できなくなります。この記事では、WordPress サイトのドメインに DNSSEC を導入する手順と、導入で守れるもの・守れないもの、運用で事故を防ぐための順番を説明します。

DNSSEC で守れるもの・守れないもの

DNSSEC は、ドメインの DNS 情報にデジタル署名を付け、問い合わせたリゾルバがその署名を検証できるようにする仕組みです。

守れるもの:

• キャッシュポイズニングなどで偽の IP アドレスを返され、訪問者が偽サイトへ誘導される攻撃
• 経路上での DNS 応答の書き換え
• DANE（メールサーバーの証明書を DNS で示す仕組み）など、DNSSEC を土台にする仕組みの前提

守れないもの:

• 通信の盗み見: DNSSEC は暗号化しません。暗号化は DoH や DoT の役割です。
• WordPress 本体への攻撃: 脆弱なプラグインや弱いパスワードによる乗っ取りには効果がありません。
• レジストラや DNS 事業者のアカウントの乗っ取り: 管理画面に入られれば、署名ごと書き換えられます。アカウントの二要素認証や、レジストラが提供するロック機能を併用します。

つまり DNSSEC は「訪問者が本物のサーバーにたどり着けること」を強める対策で、サイトのセキュリティ対策の一部として位置づけるのが適切です。

導入前に確認すること

レジストラと DNS 事業者の対応

DNSSEC には2つの事業者が関わります。

• DNS 事業者（ゾーンを置いている所）: ゾーンに署名する役割。Cloudflare、Amazon Route 53 などのマネージド DNS の多くが署名機能を持っています。
• レジストラ（ドメインを登録した所）: 親ゾーン（.com や .jp など）に DS レコードを登録する役割。

両者が別の会社の場合、レジストラ側に DS レコードを入力する画面があるかを確認します。レジストラによっては、自社の DNS を使っている場合にしか DNSSEC に対応していないこともあります。対応状況や画面の名称は事業者ごとに異なり、変更もあるため、各社のヘルプで確認してください（2026年10月現在）。

現在の状態を確認する

# 親ゾーンに DS が登録されているか（何も返らなければ未登録）
dig +short DS example.com

# ゾーンに DNSKEY があるか（署名が有効か）
dig +short DNSKEY example.com

# ネームサーバーの確認
dig +short NS example.com

DS が未登録で DNSKEY もなければ、DNSSEC は未導入の状態です。DS だけが残っていて DNSKEY がない場合は、過去の移行作業の残骸で検証が失敗している可能性があるため、先に後述の手順で直します。

手順1：DNS 事業者で署名を有効にする

マネージド DNS では、DNS の設定画面にある DNSSEC の項目から署名を有効にします。有効にすると、レジストラに登録するための DS レコードの情報が表示されます。

• 鍵タグ（Key Tag）: 数字
• アルゴリズム: 13（ECDSA P-256）などの番号
• ダイジェストの種類: 2（SHA-256）が一般的
• ダイジェスト: 長い16進数の文字列

Route 53 のように、署名用の鍵を別のサービス（AWS KMS）で管理する方式の事業者もあります。署名の有効化とあわせて、事業者が案内する前提条件を確認してください。

自前の BIND で署名する場合

自前の権威 DNS で運用している場合、比較的新しい BIND では dnssec-policy を使うと、鍵の生成・署名・再署名を自動で行えます。設定変更の前には、設定ファイルとゾーンファイルのバックアップを取ってください。

zone "example.com" {
    type primary;
    file "/var/lib/bind/db.example.com";
    dnssec-policy default;
    inline-signing yes;
};

sudo named-checkconf && sudo rndc reconfig
sudo rndc dnssec -status example.com

# 公開された DNSKEY から DS を作る
dig @127.0.0.1 DNSKEY example.com | dnssec-dsfromkey -2 -f - example.com

inline-signing の要否や default ポリシーの中身は BIND の版によって異なるため、利用中の版のドキュメントで確認してください。

手順2：レジストラに DS を登録する

レジストラの管理画面で、手順1の値を DS レコードとして入力します。DNS 事業者とレジストラが同じ会社（Cloudflare Registrar など）の場合は、自動で登録されることがあります。

入力でつまずきやすいのは次の点です。

• ダイジェストの前後に空白が入っている、一部が欠けている
• アルゴリズムやダイジェストの種類の番号を取り違えている
• DS ではなく DNSKEY の公開鍵の値を入力する画面だった（レジストラによって入力形式が異なります）

登録後、親ゾーンに反映されるまで数分から数時間かかります。

手順3：検証が通ることを確認する

# DS が親ゾーンに出ているか
dig +short DS example.com

# 検証するリゾルバ経由で、flags に ad が付くか
dig +dnssec example.com A @1.1.1.1

# BIND 付属の delv で検証結果を表示する
delv example.com A

dig の応答の flags に ad が付けば、リゾルバが検証に成功しています。delv では fully validated と表示されます。SERVFAIL が返り、+cd を付けると答えが返る場合は、DS と DNSKEY が一致していません。DNSViz で信頼の連鎖を図にすると、どこで切れているかが分かります。

確認できたら、WordPress サイトが普段どおり開くか、メールの送受信ができるかもあわせて確かめます。

運用で事故を防ぐための順番

DNSSEC の障害の多くは、導入時ではなく変更時に起きます。

DNS 事業者を乗り換えるとき

旧事業者の署名に合わせた DS を残したまま、ネームサーバーを新事業者に切り替えると、新しいゾーンの署名と DS が一致せず、検証するリゾルバからはドメイン全体が見えなくなります。安全な順番の一例は次のとおりです。

1. レジストラで DS を削除する
2. DS の TTL（.com などでは1日程度のことが多い）が過ぎるまで待つ
3. ネームサーバーを新事業者に切り替える
4. 新事業者で署名を有効にし、新しい DS を登録する

この方法では、2〜4の間は DNSSEC のない状態になります。それを避けたい場合は、新旧両方の鍵を並べて切り替える方式（マルチサイナー）に対応している事業者かどうかを確認します。

DNSSEC をやめるとき

先に DS を削除し、その TTL が過ぎてから DNS 事業者側の署名を無効にします。逆の順番にすると、DS が残っているのに署名がない状態になり、検証が失敗します。

その他の注意点

• ドメインの移管: レジストラを移るときに DS が引き継がれるかを移管前に確認します。
• 署名の期限切れ: 自前運用では、署名の自動更新が止まると数日〜数週間後に突然解決できなくなります。rndc dnssec -status や外部の監視で定期的に確認します。
• CAA レコードとの組み合わせ: 証明書を発行できる認証局を CAA レコードで限定しておくと、DNSSEC で守られた CAA を認証局が参照するため、不正な証明書の発行を防ぐ効果が高まります。

まとめ

• DNSSEC の導入は「署名を有効にする → DS をレジストラに登録する → 検証を確認する」の3段階
• 守れるのは偽の DNS 応答による誘導で、暗号化や WordPress 本体の防御は別の対策が必要
• レジストラと DNS 事業者のアカウントには二要素認証などをかける
• 事業者の乗り換えと DNSSEC の取りやめは、DS を先に削除して TTL を待つ順番で行う
• dig +dnssec の ad フラグ、delv、DNSViz で、導入後も定期的に状態を確かめる

• CAA レコードで SSL 証明書の発行元を制御する方法
• DNSViz で DNSSEC の状態を確認する方法