DNSSECを有効にしてレジストラにDSレコードを登録したのに、dig で見てもDSが出てこない、DNSSECのチェックツールで「DSが無い」と表示される。このときは、DSがどこで止まっているかを順番に確かめるのが近道です。DSは自分のDNSではなく親ゾーン（.com や .jp など）に置かれるレコードなので、問い合わせ先を間違えると「無い」ように見えることもあります。この記事では、問い合わせ方の確認から、レジストラ・レジストリ・ドメインの状態のどこで止まっているかの切り分けまでを、よくある順に説明します。
すでにDSは出ているのに検証エラー（SERVFAIL）になる場合は、DSとDNSKEYの不一致を直す作業になり、この記事とは別の手順になります。ここでは「DSが親ゾーンに現れない」状態に絞ります。
DSはどこにあるのか
DNSSECでは、自分のゾーン（example.com）にDNSKEYレコード（公開鍵）を置き、その鍵の要約値であるDSレコードを親ゾーンに登録します。親ゾーンがDSを返すことで、「example.com の正しい鍵はこれ」という信頼の連鎖がつながります。
利用者がDSを直接親ゾーンに書くことはできません。通常は次の経路をたどります。
- DNSサービス（Cloudflare、Route 53 など）で署名を有効にし、DSの値（またはDNSKEY）を表示させる
- その値をレジストラの管理画面に登録する
- レジストラがレジストリ（TLDの管理者）に送信する
- レジストリが親ゾーンにDSを追加し、親ゾーンの権威サーバーが返すようになる
どの段階で止まっていても、外から見た症状は「DSが出てこない」で同じです。そのため、外側から順に確かめていきます。
確認1：問い合わせ先が親ゾーンになっているか
最も多いのが、確認方法の誤りです。自分のDNSサービスの権威サーバーに DS を問い合わせても、DSは返りません。DSは親ゾーン側のデータだからです。
まず、キャッシュDNS経由と親ゾーンの権威サーバーへの直接の問い合わせの両方で確かめます。
# キャッシュDNS経由（キャッシュの影響を受ける）
dig example.com DS +short @1.1.1.1
# 親ゾーンの権威サーバーを調べて直接問い合わせる（.com の例）
dig com NS +short
dig @a.gtld-servers.net example.com DS +norec+trace を使うと、ルートから順にたどった結果のどこでDSが返っているかを一度に見られます。
dig example.com DS +trace親ゾーンの権威サーバーに直接聞いてDSが返るなら、DSはすでに反映されています。キャッシュDNSだけが古い応答を返している状態なので、確認5に進んでください。
親ゾーンの権威サーバーでもDSが返らない場合は、登録がレジストリまで届いていません。次の確認2以降を見ます。
確認2：レジストラの画面で登録が完了しているか
レジストラの管理画面で、DS（DNSSEC）の設定欄に値が保存されているかを確認します。画面の名称は「DNSSEC」「DSレコード」「署名鍵」などレジストラによって異なり、変更されることもあります（2026年10月現在）。
確認したい点は次のとおりです。
- 入力した値が保存され、処理中や失敗の表示になっていないか
- レジストラが求めているのがDSの値か、DNSKEYの値か。DNSKEYを登録させ、DSはレジストラ側で計算する方式のところもあります
- 鍵タグ（Key Tag）、アルゴリズム番号、ダイジェストタイプ、ダイジェストの4つを取り違えていないか
- エラーメールや通知が届いていないか
入力値は、DNSサービスが表示するDSと、実際に公開されているDNSKEYから計算したDSが一致しているかで確かめられます。BINDに付属する dnssec-dsfromkey を使うと、公開中のDNSKEYからDSを計算できます。
dig example.com DNSKEY +multiline
dig example.com DNSKEY +noall +answer > dnskey.txt
dnssec-dsfromkey -a SHA-256 -f dnskey.txt example.com+multiline の出力では、各鍵の行に KSK か ZSK か、アルゴリズム、key id（鍵タグ）がコメントとして表示されます。DSに登録するのはKSK（フラグが257の鍵）のものです。ZSKの値を登録していると、レジストラが受け付けても検証はつながりません。
確認3：レジストラとTLDがそのアルゴリズムに対応しているか
DNSSECのアルゴリズムには、RSASHA256（8）、ECDSAP256SHA256（13）、ED25519（15）などがあります。DNSサービスが新しいアルゴリズムで署名していても、レジストラの入力欄やレジストリがそのアルゴリズムやダイジェストタイプを受け付けない場合、登録が保留されたり、黙って無視されたりすることがあります。
対応状況はレジストラやTLDによって異なり、変わることもあるため、レジストラのヘルプで対応アルゴリズムを確認してください。対応していない場合は、DNSサービス側で受け付けられるアルゴリズムに変更できるかを調べます。
また、TLDによってはDNSSECそのものに対応していないものや、特定の種類のドメインで手続きが異なるものもあります。
確認4：ドメインの状態がDSの更新を止めていないか
ドメインには、変更を止めるためのステータスが付くことがあります。WHOIS（RDAP）の結果で、ドメインの状態を確認します。
whois example.com | grep -i statusclientUpdateProhibited や serverUpdateProhibited が付いていると、DSを含む登録情報の更新が受け付けられないことがあります。前者はレジストラ側のロックなので管理画面で一時的に解除でき、後者はレジストリ側のロックなのでレジストラに解除手続きを相談します。
ほかにも、ドメインの移管中、登録者情報の確認待ち、期限切れ間際などの状態では、DSの更新が保留されることがあります。
確認5：反映待ちの時間が過ぎているか
レジストラからレジストリへの送信は即時のところもあれば、一定の間隔でまとめて処理するところもあります。さらに、親ゾーンの権威サーバーが更新されるまでの時間、キャッシュDNSに残っている「DSが無い」という否定応答の保持時間も加わります。
否定応答の保持時間は親ゾーンのSOAレコードの値で決まります。次のコマンドで親ゾーンのSOAを確認できます。
dig com SOA +noall +answer親ゾーンの権威サーバーで返るようになっていれば、待てばキャッシュDNSでも見えるようになります。逆に、登録から1日以上たっても親ゾーンの権威サーバーに出てこない場合は、確認2〜4のどこかで止まっている可能性が高いので、レジストラのサポートに、登録した値とドメイン名、dig +trace の結果を添えて問い合わせます。
反映された後の確認
DSが親ゾーンに現れたら、検証がつながったかを確かめます。検証するキャッシュDNSに問い合わせ、応答のフラグに ad が付けば検証に成功しています。
dig example.com A +dnssec @1.1.1.1 | grep flags
delv example.com A視覚的に確かめたい場合は、DNSViz や Verisign Labs の DNSSEC Analyzer で、ルートから自分のゾーンまでの連鎖が途切れていないかを確認できます。
SERVFAIL が返るようになった場合は、DSは届いたものの内容がDNSKEYと合っていません。ドメインが検証するリゾルバから引けなくなっている状態なので、DSを正しい値に直すか、いったんDSを外して時間をおいてから設定し直します。どちらの作業でも、登録内容の控えを取ってから進めてください。
まとめ
- DSは親ゾーンのデータ。自分のDNSに問い合わせても返らないので、親ゾーンの権威サーバーか
+traceで確認する - 親ゾーンで返っていればキャッシュ待ち。返っていなければレジストラ・レジストリのどこかで止まっている
- レジストラでは、DSかDNSKEYのどちらを求めているか、KSKの値か、4つの項目に誤りが無いかを確かめる
- アルゴリズムの対応状況と、
clientUpdateProhibitedなどのドメインの状態も原因になる - 反映後は
adフラグや DNSViz で連鎖を確認し、SERVFAILならDSの値を見直す