DNSSEC 設定は必要か｜有効にする手順と検証に失敗したときの見分け方・戻し方

• DNSSEC 設定は必要かといえば任意です。メールとWebサイトはDNSSECが無いままでもいつもどおり動きます
• 有効にするなら、DNSの事業者がゾーンに署名することとその鍵を指すDSレコードを上位のゾーンに置くことの両方が要ります。同じ会社で両方を持っていれば、管理画面のスイッチ1つで済むことがあります
• 困るのはDSレコードがあるのに署名の検証に通らない状態です。検証を行うDNSサーバーを使う相手からはメールの送り先もサイトのアドレスも引けないことがあります。いまの鍵に合うDSを登録し直すか、DSを外して戻します

DNSの言葉は次の意味で使います。

DNSSECを設定しなくてよい場合

DNSSECは、設定しなくて構いません。SiteKensaの診断も設定されていないことを問題にせず「参考」として出しています。

DNSSECで得られるのはDNSの応答が本物で書き換えられていないことを確かめられることです。RFC 4033 セクション12 は、この仕組みが署名によってデータの出所の認証と完全性を与えると書いています。同じRFCのセクション1は、秘匿性は与えないと書いています。問い合わせの中身が暗号化されるわけではありません。

確かめるのは検証を行うDNSサーバーです。RFC 4035 セクション4.3 は、検証の出発点からDSと鍵の連なりが無いと検証側が分かっている応答を「Insecure」と呼び、その署名は、検証できないとしています。DSレコードを置いていない sitekensa.com も、2026年10月23日に 1.1.1.1 へ問い合わせると status: NOERROR で答えが返りました。

いまの状態を確かめる

DNSSECの状態は、DSレコードがあるかどうかと検証に通るかどうかで分かれます。

DNSの事業者の画面でDNSSECを有効にしただけで、上位のゾーンにDSレコードが無いときは、1行目に当たります。

いちばん手早いのはSiteKensaの診断にドメイン名を入れることです。診断は、DSレコードの有無とドメイン本体のSOAに検証を行うDNSサーバーが、答えを返すかの両方を見ます。www.example.com のようなサブドメインを入れたときは、それを含むゾーンの頂点で判定し、そのことを結果の文に書きます。サブドメインが別のゾーンとして任されているなら、そのサブドメイン自身が頂点です。

コマンドで見るなら、macOSやLinuxのターミナルで次を実行します。jprs.co.jp の部分を自分のドメイン名に置き換えてください。出力は2026年10月23日にmacOSの dig 9.10.6 で実行したものです。

$ dig +short DS jprs.co.jp
63574 8 2 5D5518EC26E3D8EED9411BA2373A0B9DB7014A54CF5440BC0AA0468A F943973B

1行でも返ればDSレコードがあります。何も表示されないときは、+short を外して status: と ANSWER: を見ます。空の表示だけでは、DSが無いのか問い合わせに失敗したのかを見分けられません。

$ dig +noall +comments DS sitekensa.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32601
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

status: NOERROR で ANSWER: 0 なら、DSレコードはありません。status: SERVFAIL なら問い合わせに失敗しているので、時間を置いて引き直してください。

DSレコードは、ドメイン自身のゾーンではなく上位のゾーンに置かれます。RFC 4034 セクション5 は、DSが委任の上位の側にだけ現れ、上位のゾーンの権威あるデータだと定めています。別のゾーンとして任されていない www.jprs.co.jp のようなサブドメインで引くとゾーンが署名されていても何も返りません。引く名前はドメイン本体です。サブドメインを別のゾーンに分けて任せているときは、そのサブドメインの名前で引きます。

DSレコードがあったら、検証に通るかを見ます。

$ dig +noall +comments SOA jprs.co.jp @1.1.1.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15504
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

status: NOERROR で flags: に ad があれば検証に通っています。RFC 4035 セクション3.2.3 は、検証を行うDNSサーバーが、答えの部分を全部本物と判断したときに ad を立てるべきだとしています。status: SERVFAIL だったときは障害と検証の失敗を見分けるへ進んでください。

status: NOERROR なのに flags: に ad が無いときは、それだけで検証の失敗とも成功とも決められません。@1.1.1.1 を @8.8.8.8 に替えて別の検証を行うDNSサーバーでも引き、時間を置いて確かめ直してください。2026年10月23日にバリュードメインで有効にした検証用の .com のドメインでは、有効にした直後に 1.1.1.1・8.8.8.8・9.9.9.9 が、DSがあるのに ad の無い NOERROR を返した時間がありました。3社がそろって ad を付けたのは保存の約1時間後です。1ドメイン1回の観察で、理由は分かっていません。それを過ぎても ad が付かないままなら、問い合わせに添える材料をそろえてDNSの事業者へ問い合わせてください。

Windows Server 2022 の nslookup ではDSレコードを確かめられませんでした。2026年9月1日にWindows Server 2022（ja-JP）で確かめたところ、-type=DS を種類として解釈せず、既定のAレコードを引いた結果を返しました（NSレコードの不一致の記事に記録があります）。Windowsだけで作業しているなら、診断を使ってください。

ステップ 1/3：DNSの事業者と登録事業者が対応しているか確かめる

DNSSECの作業にはDNSの事業者と登録事業者が関わります。ゾーンに署名するのはDNSの事業者で、ドメイン本体のDSレコードを上位のゾーンへ届けるのは登録事業者です。DSは、上位のゾーンのデータです（RFC 4034 セクション5）。

両方のヘルプで「DNSSEC」を探し、次を確かめます。

1. DNSの事業者が、そのゾーンの署名に対応しているか
2. 登録事業者が、そのドメインの種類 (.com や .jp) でDSレコードの登録に対応しているか
3. 2社が違う会社なら、登録事業者の画面にDSレコードを入れる欄があるか

バリュードメインは、同社で管理しているドメインで同社のネームサーバー（ns1〜ns5.value-domain.com、ns11〜ns13.value-domain.com）を使っている場合に限って、DNSSECを設定できると案内しています。他社で管理しているドメインと同社の無料ネームサーバーを使っているドメインでは使えません。対応している種類は対応ドメインの一覧にあります（DNSSEC設定）。

自分のドメインが当たるかは、ネームサーバーの名前で見ます。ターミナルで dig +short NS <自分のドメイン名> を実行し、返った名前が ns1〜ns5.value-domain.com か ns11〜ns13.value-domain.com なら、同社のネームサーバーを使っています。One Panel のドメイン詳細でも、ネームサーバーの欄に「バリュードメイン」と出ます。同社の無料ネームサーバーと見分けるには、ステップ 2/3 の「DNSSEC設定」の画面を開きます。2026年10月23日に条件に当たる .com のドメインで開いたときは、この画面にネームサーバー (ns11〜ns13.value-domain.com) とネームサーバーのタイプが並び、スイッチで有効にできました。

この画面にスイッチが出ないときや有効にできないときは、そのドメインでDNSSECを使えるかを同社に問い合わせてください。

有効にする前に、ゾーンにワイルドカード（ホスト名が * のレコード）が無いかも見てください。バリュードメインは、ワイルドカードを置いたままDNSSECを有効にするとそのレコードのホスト名で名前解決ができなくなると書いています。有効にする前にワイルドカードを消し、使うホスト名を1件ずつ登録するよう案内しています（同じページ）。ほかの事業者で同じことが起きるかは確かめていません。

ワイルドカードがあるかは、DNS設定の画面で名前が * の行を探せば分かります。従来のコントロールパネルのテキスト欄なら a * 123.123.123.5 のように2つ目の語が * の行、One Panel の一覧なら名前の欄が * の行です。消すときは、その行を消して、使っているホスト名 (www など) の行を1件ずつ書いてから保存します。

ステップ 2/3：DNSの管理画面で有効にし、DSレコードを登録する

バリュードメインの場合

公式の手順は次のとおりです（DNSSEC設定）。

1. ホーム画面の「ドメイン」から「ドメイン管理」を開く
2. 管理ドメインの一覧で、設定するドメイン名をクリックする
3. 「DNSSEC設定」を開き、編集をクリックする
4. スイッチを切り替えて「保存」をクリックする
5. 「DNSSECの設定を更新しました」と出れば画面での設定は終わり

2026年10月23日に検証用の .com のドメイン1件でこの手順を行いました。保存すると画面の「上位レジストラでの設定DSレコード」の欄にDSの値が自動で入りました。保存から約1分後には .com のゾーンにDSレコード（アルゴリズム13、TTL 86400秒）が載っていました。このドメインではDSを自分で登録する作業はありませんでした。

同社は、有効にしてもインターネット上にすぐには反映されないので、時間を空けて動作を確かめるよう書いています（同じページ）。

DNSの事業者と登録事業者が違う場合

DSを登録する前に、ゾーンから鍵が返ることを確かめます。鍵が無いのにDSだけを置くと検証に失敗する状態を自分で作ることになります。

$ dig +noall +answer +multi DNSKEY jprs.co.jp @1.1.1.1
				) ; ZSK; alg = RSASHA256 ; key id = 51576
				) ; KSK; alg = RSASHA256 ; key id = 63574

jprs.co.jp は自分のドメイン名に置き換えます。KSK の行が返れば鍵があります。出力は、鍵の本体を省いて番号の行だけを載せています。空のときは、DSを登録する前にDNSの事業者の画面で署名が有効になっているかを見直してください。

鍵が返ったら、DNSの事業者の画面に出ている値を登録事業者の画面に入れます。DSを入れる事業者も鍵を入れる事業者もあり、欄の名前も事業者ごとに違います。この記事ではバリュードメイン以外の画面を確かめていません。両方の事業者のヘルプで確かめてください。

ステップ 3/3：外から引いて、検証に通るか確かめる

いまの状態を確かめるのコマンドをもう一度実行します。完了の形は次のとおりです。

• dig +short DS で、DNSの事業者の画面に出ている値と同じDSレコードが返る
• dig +noall +comments SOA <ドメイン名> @1.1.1.1 が status: NOERROR で、flags: に ad がある

有効にした直後は、1回の確認で決めないでください。先のバリュードメインのドメインでは、保存の約10分後から約1時間、1.1.1.1 などに問い合わせると SERVFAIL が返る回が断続的にありました（問い合わせた3社のどれでも出ました）。同じ時間帯にDNSの事業者のサーバーは、同じ名前に署名のある応答と無い応答を混ぜて返していました。原因は、特定していません。観察は、1ドメイン1回分なので、ほかの事業者や別の日にも同じことが起きるかは分かりません。

間を空けて何度か確かめます。SERVFAIL が続くときは、次の節の障害と検証の失敗を見分けるへ進みます。+cd を付けると答えが返り、DSと鍵の番号も同じなら、DNSの事業者の側で切り替えている途中の可能性があります。待つ時間の手がかりは、上の1ドメイン1回の観察 (約1時間) しかありません。それを過ぎても続くときは、問い合わせに添える材料をそろえてDNSの事業者へ問い合わせてください。

「DNSSECの検証に失敗しています」と出たとき

DSレコードがあるのに署名の検証に通らない状態です。RFC 4035 セクション5.5 は、再帰の問い合わせに答えるために検証して、署名をどれも検証できなかったとき、DNSサーバーが SERVFAIL を返すと定めています。そうしたDNSサーバーを使う相手からは、このドメインのメールの送り先やサイトのアドレスを引けないことがあります。検証を行わないDNSサーバーを使う相手からは引けるので、「一部の相手だけ届かない」という形で表に出ることがあります。

SiteKensaの診断では、この状態のときにほかの項目が「調べられませんでした」になることがあります。その理由をDNSSECの検証の失敗として書き換えて表示します。レコードが無いという意味ではないので、先にDNSSECを直してください。

障害と検証の失敗を見分ける

SERVFAIL は、DNSの事業者のサーバーが答えないときにも返ります。見分けるには、検証を止める指定 (+cd) を付けて引き直します。RFC 4035 セクション5.5 は、署名をどれも検証できなかった応答の中身を返すのは問い合わせにCDビットが立っているときに限ると定めています。

検証に失敗するように作られた公開の確認用ドメイン dnssec-failed.org で実行した出力です。この節と次の節のコマンドは、dnssec-failed.org を自分のドメイン名に置き換えて打ちます。

$ dig +noall +comments SOA dnssec-failed.org @1.1.1.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13533
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 09 6e 6f 20 53 45 50 20 6d 61 74 63 68 69 6e 67 20 74 68 65 20 44 53 20 66 6f 75 6e 64 20 66 6f 72 20 64 6e 73 73 65 63 2d 66 61 69 6c 65 64 2e 6f 72 67 2e ("..no SEP matching the DS found for dnssec-failed.org.")

$ dig +cd +noall +comments +answer SOA dnssec-failed.org @1.1.1.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44662
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

2つ目の出力は、答えの行を省いて先頭の3行だけを載せています。

OPT=15 の行は、DNSサーバーが添えた拡張エラーの欄で、この例では失敗の理由が入っています。RFC 8914 セクション2 は、この番号の欄を拡張エラーとして定めています。先頭の 00 09 はコード9で、同じRFCのセクション4.10 は、「上位にDSがあるが、それに合う扱える鍵が、子のゾーンに見つからない」と定義しています。

DSと鍵が合っているか見る

DSレコードの最初の数字は、指している鍵の番号です。RFC 4034 セクション5.1.1 は、この欄がDSの指す鍵の番号 (Key Tag) だと定めています。ゾーンの鍵の番号と見比べます。

$ dig +short DS dnssec-failed.org
42069 13 2 62726F6B656E20636861696E206F662074727573742073656E642068 656C7021
$ dig +cd +noall +answer +multi DNSKEY dnssec-failed.org @1.1.1.1
				) ; KSK; alg = ECDSAP256SHA256 ; key id = 50719
				) ; ZSK; alg = ECDSAP256SHA256 ; key id = 32784

DSは 42069 を指していますが、ゾーンの鍵（KSK の行）は 50719 です。DSがいまの鍵を指していません。DSが複数返ったときは、どれか1つが KSK の番号と同じかを見ます。

番号が同じでも、それだけではDSと鍵が合っている証明になりません。番号が同じなのに失敗するときは、この記事の範囲では原因を絞れません。DNSの事業者へ問い合わせるときは、次を添えてください。

• 起きはじめた日時とDNSSECを有効にした日時
• 問い合わせたDNSサーバー (1.1.1.1 など) とその日時
• +cd なしと +cd ありの出力
• dig +short DS の出力
• DNSKEY の KSK の行の key id
• 有効にしたあとに、ネームサーバーやDNSの事業者を変えたかどうか

直すか、戻すか

番号が違っていたなら、いまの鍵を指すDSレコードを登録し直します。DNSの事業者の画面に出ている最新のDSの値を登録事業者の画面の値と見比べ、違っていれば入れ替えます。古い値を消す前に、画面の値を控えておいてください。

すぐに直せないなら、DSレコードを外して戻します。RFC 6781 セクション4.2.1.2 は鍵を緊急に替える方法の1つとして、上位のゾーンからDSを外すとそのゾーンは Insecure になり、DSが遠くのキャッシュから消えたあとで鍵と署名を外す、という順序を示しています。DSを外したあとも、DSがキャッシュに残っているあいだは検証が行われます。署名を止めるのは後にしてください。

キャッシュに残る長さの目安は、上位のゾーンがDSに付けたTTLです。TTLはそのレコードをキャッシュしてよい時間です（RFC 1035 セクション3.2.1）。上位のゾーンのサーバーへ直接聞くと元のTTLが出ます。

$ dig +norecurse +noall +answer DS jprs.co.jp @a.dns.jp
jprs.co.jp.		7200	IN	DS	63574 8 2 5D5518EC26E3D8EED9411BA2373A0B9DB7014A54CF5440BC0AA0468A F943973B

この例では7200秒（2時間）です。.com の場合は @a.gtld-servers.net に聞きます。先のバリュードメインのドメインでは86400秒（24時間）でした。

バリュードメインのようにDNSの事業者と登録事業者が同じでスイッチ1つで切り替える画面について、スイッチを切ったときにDSと署名がどの順に外れるかは確かめていません。上の順序をその画面で守れるかも分かりません。同社は、無効にしてもすぐには反映されないと書いています。DSと鍵が合わないときや戻したいときは、スイッチを切る前に同社へ問い合わせてください。問い合わせに添える材料に加えて、DNSSEC設定の画面の「上位レジストラでの設定DSレコード」の値を添えます。

DNSSECを有効にしたままDNSの事業者を変えるとき

ネームサーバーを別の事業者へ移すと新しい事業者のゾーンは古い鍵で署名されていません。上位のゾーンに古い鍵を指すDSが残っていると検証に失敗します。

RFC 6781 セクション4.3.5.2 は、移る前の事業者が協力しない場合について、変更のあいだはゾーンを Insecure にするしかないとしています。DSを外すこととネームサーバーを変えることを頼み、それが行き渡ってから、移った先で署名したゾーンを指すDSを入れ直す順序です。

バリュードメインは、DNSSECを有効にしたままネームサーバーを変えるなら次のどちらかを強く勧めています（DNSSEC設定）。

1. 変える前にDNSSECを無効にし、目安として72時間ほど空けてからネームサーバーを変える
2. 変更先のネームサーバーで先にDNSSECを有効にしてから、ネームサーバーを変える

ネームサーバーの変え方そのものと変える前に確かめることは、NSレコードの不一致の記事にあります。

診断の表示ごとにすること

サブドメインを入れたとき、診断は、それを含むゾーンの頂点で判定し、結果の文にどの名前で確かめたかを書きます。直したら、もう一度診断で確かめてください。