DNSSEC を有効にしたドメインの DNS サービス（権威 DNS）を切り替えるときは、親ゾーンの DS と、実際に応答するネームサーバーの署名が、どの時点でも食い違わないように順序を組むことが要点です。食い違いが起きると、検証を行うリゾルバーを使う利用者からはドメイン全体が SERVFAIL になり、Web サイトもメールも届かなくなります。この記事では、多くの環境で使える「いったん署名を外して移る」方法を中心に、両方の事業者が対応している場合の「複数署名者で移る」方法、各段階で何を確かめるかを説明します。
ここでの「切り替え」は、DNSSEC を有効にしたまま DNS サービスを別の事業者や自前のサーバーへ移すことを指します。署名の鍵だけを定期的に入れ替える作業（鍵ローテーション）とは手順が異なります。
なぜ順序を誤ると止まるのか
検証を行うリゾルバーは、親ゾーン（例：.com）から受け取った DS をもとに、子ゾーンの DNSKEY を信頼し、その DNSKEY で各レコードの署名（RRSIG）を検証します。DS も DNSKEY もキャッシュされるため、次のような状態が一時的に生まれます。
- 親には旧事業者の鍵に対応する DS が残っている（またはキャッシュに残っている）
- 利用者のリゾルバーは、新事業者のネームサーバーから応答を受け取る
- 新事業者の DNSKEY は旧事業者の DS と一致しない、または署名が無い
DS がある以上、リゾルバーは署名を要求します。署名が無い、あるいは DS と鍵が一致しない応答は「改ざんの疑いあり」と判断され、SERVFAIL になります。DNSSEC の切り替えで障害が起きる原因のほとんどは、この状態を作ってしまうことです。
始める前に確かめておくこと
作業前に、今の状態と待ち時間の目安を把握します。
# 親ゾーンのネームサーバーを調べる（例は .com）
dig +short NS com.
# 親ゾーンに登録されている DS と、その TTL
dig DS example.com @a.gtld-servers.net +norecurse
# 親ゾーンに登録されている NS と、その TTL
dig NS example.com @a.gtld-servers.net +norecurse出力の2列目が TTL（秒）です。DS と NS の TTL は親ゾーンの運営者が決めており、利用者は変更できません。TLD によって値が異なるため、自分のドメインの値を実際に確かめ、これを待ち時間の基準にします。あわせて、次の準備を済ませます。
- ゾーンのバックアップ：旧事業者の管理画面からゾーンファイルを書き出すか、すべてのレコードを一覧にして保存します。
- 新事業者にゾーンを作成：レコードを登録し、まだ署名は有効にしません。
- 新しいネームサーバーで応答を比べる：切り替え前に、新しいネームサーバーへ直接問い合わせて、旧ネームサーバーと同じ応答が返ることを確かめます。
dig +short www.example.com A @ns1.old-provider.example
dig +short www.example.com A @ns1.new-provider.example
dig +short example.com MX @ns1.new-provider.example方法1：いったん署名を外してから移る
両方の事業者が特別な機能に対応していなくても使える、最も一般的な方法です。移行中に署名の無い期間ができますが、名前解決は止まりません。
手順1：レジストラで DS を削除する
レジストラ（ドメインの登録事業者）の管理画面で DS を削除します。この時点では旧事業者の署名は有効のままにしておきます。削除が親ゾーンに反映されたかは、先ほどの dig DS ... @a.gtld-servers.net で DS が返らなくなることで確かめます。反映までの時間はレジストラやレジストリによって異なります。
手順2：DS の TTL が切れるまで待つ
親ゾーンから DS が消えても、各地のリゾルバーには古い DS がキャッシュされています。作業前に確かめた DS の TTL に余裕を加えた時間だけ待ちます。この間も旧事業者の署名を止めないことが大切です。キャッシュに DS が残っているリゾルバーは、引き続き署名を検証するためです。
手順3：ネームサーバーを切り替える
DS の TTL が過ぎたら、レジストラでネームサーバーを新事業者のものに変更します。親ゾーンの NS の TTL が切れるまでは、旧ネームサーバーに問い合わせるリゾルバーも残ります。旧事業者のゾーンは、NS の TTL に余裕を加えた時間が過ぎるまで削除しないでください。
手順4：新事業者で署名を有効にし、DS を登録する
新しいネームサーバーへの切り替えが落ち着いたら、新事業者で DNSSEC の署名を有効にします。DNSKEY と RRSIG が返ることを確かめてから、新事業者が示す DS の値をレジストラに登録します。
# 新しいネームサーバーが署名付きで応答するか
dig +dnssec example.com SOA @ns1.new-provider.example
dig example.com DNSKEY @ns1.new-provider.example +multilineDS の登録は署名の確認より後に行います。順序を逆にすると、署名の無いゾーンに DS が付き、手順の冒頭で説明した障害が起きます。
方法2：複数署名者の構成で署名を保ったまま移る
RFC 8901 で整理されている、2つの事業者が同じゾーンにそれぞれ署名する構成を使うと、署名を外さずに移れます。ただし、相手の事業者の DNSKEY を自分のゾーンに追加できる機能が両方に必要です。対応している事業者は限られ、項目名や手順も事業者ごとに異なるため、各事業者の資料で対応状況を確認してください（2026年10月現在）。
流れは次のとおりです。
- 新事業者でゾーンを作成し、署名を有効にする。
- 旧事業者のゾーンに新事業者の DNSKEY を、新事業者のゾーンに旧事業者の DNSKEY を追加する。
- レジストラに新事業者の DS を追加し、旧事業者の DS と並べて登録する。
- DS と DNSKEY の TTL が切れるのを待ってから、ネームサーバーを切り替える。
- NS の TTL が切れた後、旧事業者の DS と DNSKEY を外し、旧事業者のゾーンを削除する。
この方法は手順が多く、片方の事業者の鍵の自動更新が移行中に走ると相手側の DNSKEY が古くなる、といった落とし穴もあります。移行の期間だけ鍵の更新を止められるかも、事前に確かめておきます。
各段階で検証が通っているかを確かめる
どちらの方法でも、各手順の後に検証を行うリゾルバーでの結果を確かめます。
# 検証付きで引けるか（flags に ad が付けば検証成功）
dig example.com SOA @9.9.9.9 +dnssec
# 失敗したときは、検証を外した結果と比べる
dig example.com SOA @9.9.9.9 +cd
# BIND 付属の delv で、信頼の連鎖をたどって検証する
delv example.com SOA+cd を付けると引けるのに、付けないと SERVFAIL になる場合は、DNSSEC の検証で失敗しています。DS と DNSKEY の対応や署名の有効期限を確かめ、必要なら直前の手順に戻します。DNSViz のような可視化ツールを使うと、親の DS と子の DNSKEY のどこが食い違っているかを図で確かめられます。
万一 SERVFAIL が広がった場合の戻し方も決めておきます。最も早い応急処置は、レジストラで DS を削除し、署名の無い状態に戻すことです。ただし、DS のキャッシュが切れるまで影響は続くため、移行は利用者の少ない時間帯に始め、各手順の間に十分な待ち時間を取る計画にします。
よくあるつまずき
- レジストラの変更と同時に進めてしまう：レジストラの移管で DS が引き継がれない、または意図せず残る場合があります。DNS サービスの切り替えとレジストラの移管は、別の日に分けて行うのが安全です。
- CDS・CDNSKEY による自動更新を見落とす：一部のレジストリやレジストラは、子ゾーンが公開する CDS レコードを読んで DS を自動で更新します。旧事業者が古い CDS を出し続けていると、意図しない DS に書き換わることがあります。
- サブドメインの委任：子ゾーンを別のネームサーバーに委任し、その子ゾーンも署名している場合は、子ゾーン側の DS も新事業者のゾーンに登録し直します。
まとめ
- DNSSEC の切り替えでは、親の DS と実際に応答するネームサーバーの署名が食い違わない順序を守る。
- 一般的な方法は、DS を削除して TTL が切れるのを待ち、ネームサーバーを切り替えてから新しい署名と DS を有効にする流れ。
- 両方の事業者が相手の DNSKEY を追加できるなら、複数署名者の構成で署名を保ったまま移れる。
- 待ち時間は親ゾーンの DS と NS の TTL を dig で確かめて決め、旧事業者のゾーンは NS の TTL が切れるまで残す。
- 各手順の後に、検証するリゾルバーでの結果と
+cdの結果を比べ、戻し方を事前に決めておく。