2026年6月14日

DNSSEC の検証手順：サーバーのリゾルバで署名検証を有効にし、正しく働いているか確かめる

DNS・名前解決

DNSSEC の検証を担うのは、名前解決を行うリゾルバです。WordPress を動かしているサーバーのリゾルバで検証を有効にすれば、改ざんされた DNS 応答を受け取ったときに名前解決を失敗させ、偽のサーバーへ接続するのを防げます。この記事では、検証が今どうなっているかの確認から、Unbound・systemd-resolved・BIND での有効化、動作確認、他人のドメインの設定ミスで名前解決が止まったときの扱いまでを順に説明します。

自分のドメインに署名して DS を登録する「公開する側」の作業は、ここでは扱いません。この記事は「検証する側」の手順です。

なぜサーバー側で検証するのか

WordPress は、プラグインやテーマの更新確認、外部 API との通信、メールの送信などで、日常的に名前解決を行っています。リゾルバが DNSSEC を検証していない場合、キャッシュポイズニングなどで偽の応答が入り込んでも気づけません。HTTPS の証明書検証が最後の防波堤になりますが、証明書を使わない通信や、メールの暗号化を DNS の情報に頼る仕組み（DANE）では、DNS の正しさがそのまま安全性に関わります。

一方で、検証を有効にすると「署名が壊れているドメインは引けなくなる」という新しい失敗のしかたが加わります。これは検証が働いている証拠ですが、相手側の設定ミスでも起きるため、後半で扱う対処方法もあわせて知っておく必要があります。

手順1：いま検証が効いているかを確かめる

まず、サーバーがどのリゾルバを使っているかを確認します。

cat /etc/resolv.conf
resolvectl status   # systemd-resolved を使っている場合

次に、署名されているドメインと、検証に失敗するよう意図的に壊されたテスト用のドメインを引き比べます。

# 署名されているドメイン。flags に ad が付くか
dig isc.org A +dnssec

# 署名が壊れているテスト用ドメイン。SERVFAIL になるか
dig dnssec-failed.org A

1つ目で flags: に ad が付き、2つ目が SERVFAIL になれば、使っているリゾルバは検証しています。2つ目に普通の応答（NOERROR と IP アドレス）が返るなら、検証は効いていません。テスト用ドメインは第三者が提供しているもので、提供状況は変わることがあります（2026年10月現在）。

手順2：時刻が合っているかを確かめる

DNSSEC の署名には有効期間があり、リゾルバは自分の時計で期間内かどうかを判断します。サーバーの時刻が大きくずれていると、正しい署名まで期限切れや未来のものと判断され、あらゆるドメインが引けなくなります。

timedatectl
# 「System clock synchronized: yes」になっているか

同期されていない場合は、chrony や systemd-timesyncd などで時刻同期を有効にしてから先に進みます。仮想サーバーでは、再起動後に時刻がずれたまま起動する例もあるため、検証を有効にする前に確認しておくと切り分けが楽になります。

手順3：リゾルバで検証を有効にする

設定を変える前に、既存の設定ファイルをバックアップしてください。

Unbound を使う場合

サーバー上で Unbound を動かし、自分自身（127.0.0.1）から使う構成は、検証リゾルバとして扱いやすい形です。

# /etc/unbound/unbound.conf の例
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    # ルートゾーンのトラストアンカー（自動更新される）
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    # 検証に失敗した理由をログに出す
    val-log-level: 2
    # 拡張エラー（EDE）を応答に含める
    ede: yes

Debian 系などでは、パッケージがすでにトラストアンカーの設定を別ファイルに入れていることがあります。二重に書くと起動に失敗するため、/etc/unbound/unbound.conf.d/ の中も確認してください。ede は比較的新しい版で追加された項目です。設定後は unbound-checkconf で確認してから再起動します。

systemd-resolved を使う場合

# /etc/systemd/resolved.conf
[Resolve]
DNSSEC=allow-downgrade

allow-downgrade は、上流のリゾルバが DNSSEC に対応していないと判断したときに検証をやめる設定で、yes は常に検証を求めます。systemd-resolved の DNSSEC 対応は、上流の DNS サーバーや経路の機器との相性で問題が起きることが知られており、既定値を無効にしている配布版もあります。サーバー用途では、ローカルに Unbound を置いて検証させ、systemd-resolved はそれを参照するだけにする構成のほうが、挙動を把握しやすくなります。

BIND をリゾルバとして使う場合

// named.conf の options 内
options {
    dnssec-validation auto;
};

auto は、BIND に組み込まれたルートのトラストアンカーを使い、自動で更新する設定です。最近の版では既定値が auto ですが、古い設定ファイルを引き継いでいると no が残っていることがあるため、明示しておくと確実さが増します。named-checkconf で構文を確認してから反映します。

手順4：検証の結果を読み分ける

有効化したら、次の4つの結果を順に確かめます。

dig @127.0.0.1 isc.org A +dnssec          # ① 署名あり・正常
dig @127.0.0.1 dnssec-failed.org A        # ② 署名が壊れている
dig @127.0.0.1 dnssec-failed.org A +cd    # ③ 検証を外して引く
dig @127.0.0.1 example.net A +dnssec      # ④ 署名の有無を確かめたい任意のドメイン

①は ad 付きの NOERROR、②は SERVFAIL が期待どおりの結果です。③の +cd は「検証しないで返して」という指定で、②で失敗したドメインが③で引けるなら、失敗の原因は検証であると判断できます。④で ad が付かずに NOERROR が返る場合は、そのドメインが署名されていないだけで、異常ではありません。

拡張エラーを返すリゾルバでは、②の出力に EDE: で始まる行が付き、「DNSSEC Bogus」のような理由が表示されます。より詳しく追いたいときは、BIND に付属する delv が便利です。delv は自分で検証を行い、どの段階で失敗したかを表示します。

delv @127.0.0.1 isc.org A +vtrace

手順5：AD フラグをアプリに渡すかを決める

多くのアプリケーションは AD フラグを見ていません。検証リゾルバは、検証に失敗した応答を SERVFAIL にして返すため、AD フラグを使わなくても偽の応答は届かなくなります。

AD フラグが必要になるのは、Postfix の DANE のように、アプリが検証結果を見て動作を変える場合です。glibc 2.31 以降では、/etc/resolv.conf に options trust-ad がないと、リゾルバから受け取った AD フラグがアプリに渡る前に消されます。リゾルバが同じサーバーの 127.0.0.1 にあるときだけ、このオプションを付けるようにしてください。離れた場所のリゾルバの AD フラグは、途中で書き換えられても見分けられないためです。

手順6：他人のドメインの設定ミスで止まったとき

検証を有効にしていると、取引先や外部サービスのドメインが DS の更新漏れなどで検証に失敗し、そのドメインだけ引けなくなることがあります。本来は相手側で直すべき問題ですが、業務上どうしても待てない場合は、そのドメインだけ一時的に検証を外す仕組み（ネガティブトラストアンカー）があります。

# Unbound：一時的に検証の対象から外す／元に戻す
sudo unbound-control insecure_add example.net
sudo unbound-control insecure_remove example.net

# BIND：期限つきで外す
sudo rndc nta -lifetime 1h example.net

外したドメインは改ざんへの備えがない状態になるため、範囲は問題のドメインに限り、外した日時と理由を記録して、相手側の修正を確かめたら戻します。リゾルバ全体の検証を止めて回避するのは避けてください。

運用で見ておきたいこと

ルートゾーンの鍵（KSK）は、長い間隔で入れ替えられます。ICANN は KSK-2017 から KSK-2024 への切り替えを計画として公表しており（2026年10月現在）、トラストアンカーの自動更新が働いていないリゾルバは、切り替え後に検証へ失敗するおそれがあります。dig . DNSKEY +multi で表示される鍵と、リゾルバが持つトラストアンカー（Unbound なら root.key）を見比べ、新しい鍵が取り込まれているかを確認しておくと安心です。あわせて、SERVFAIL の件数をログや監視で追っておくと、検証の失敗が急に増えたときに気づけます。

まとめ

DNSSEC の検証はリゾルバの仕事で、サーバーのリゾルバで有効にすれば偽の応答を受け取らずに済む
署名ありのドメインで ad、壊れたテスト用ドメインで SERVFAIL になるかで、検証の有無を確かめる
時刻のずれは全面的な名前解決の失敗につながるため、有効化の前に同期を確認する
+cd や delv、拡張エラーで、失敗の原因が検証かどうかを切り分ける
他人のドメインの問題は、範囲を絞った一時的なネガティブトラストアンカーで扱い、記録して戻す