DNS 事業者の移転や DNSSEC の設定変更では、NS・DS・DNSKEY の TTL と検証結果を、作業の前・最中・後の3回に分けて delv でまとめて確認すると、待ち時間の見積もりと失敗の早期発見を同時に行えます。delv は答えを自分で DNSSEC 検証し、署名（RRSIG）に記録された「元の TTL」も表示するため、キャッシュサーバー越しでも設定上の TTL がわかるからです。この記事では、作業の段階ごとに delv で何を確かめるか、待ち時間の決め方、検証に失敗したときの切り分けを説明します。
変更作業で delv が役に立つ理由
DNSSEC を使っているドメインで設定を誤ると、検証を行うキャッシュサーバー（Google Public DNS や Cloudflare の 1.1.1.1 など）を使う利用者だけが名前解決に失敗し、SERVFAIL になります。検証をしないキャッシュサーバーでは普通に引けるため、「一部の人だけサイトが開かない」という分かりにくい症状になりがちです。
delv は BIND に付属するツールで、dig と同じパッケージ（Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils）に入っています。出力の先頭に ; fully validated（検証に成功）や ; unsigned answer（署名されていない）といった検証結果が表示されるので、「署名のつながりが切れていないか」を答えごとに確かめられます。
作業前：NS・DS・DNSKEY をまとめて記録する
変更を始める前に、関係するレコードを一度に取得してファイルに残します。あとで「元は何だったか」を確かめる材料になり、待ち時間の見積もりにも使います。
zone=example.com
out="delv-${zone}-$(date +%Y%m%d-%H%M).txt"
for t in NS DS DNSKEY SOA; do
echo "== $t"
delv "$zone" "$t" +multiline 2>&1
done | tee "$out"記録したら、次の3点を読み取ります。
- 各種別の RRSIG にある「元の TTL」。RRSIG の値は、対象の種別、アルゴリズム番号、ラベル数、元の TTL、有効期限、署名日時、鍵のタグ、署名者の順に並びます。行頭の TTL はキャッシュの残り時間なので、設定値は RRSIG の4番目の値で確かめます。
- DS の署名者。DS の RRSIG の署名者は自分のゾーンではなく親ゾーン（example.com なら
com.）になっているはずです。DS の TTL は親ゾーン側が決めていて、利用者は変えられません。 - DS と DNSKEY の対応。DS の先頭の数字は鍵のタグで、DNSKEY のどれか（通常は KSK）と一致している必要があります。
+multilineを付けると DNSKEY の行に鍵の種類や鍵のタグがコメントで表示されることが多く、照合しやすくなります（表示は版によって異なります）。
親ゾーンに登録された NS の TTL は、キャッシュサーバー越しの delv では確認しにくい値です。必要なら dig で親ゾーンのサーバーに直接問い合わせます（例：dig @a.gtld-servers.net example.com NS +norecurse の AUTHORITY セクション）。
待ち時間の決め方
作業の各段階で、次の段階に進む前に待つ時間は、変更したレコードの TTL で決まります。
- NS を切り替えたあと：親ゾーン側と子ゾーン側の NS の TTL のうち長いほう。子ゾーン側は事前に短くしておけます。
- DS を削除・追加したあと：DS の TTL（親ゾーン側の値）。
- DNSKEY を追加・削除したあと：DNSKEY の TTL。
いずれも最低限の目安で、キャッシュサーバーの実装によっては多少長く残ることがあります。余裕を持って、目安の時間に数時間を足して計画します。
作業中：複数のキャッシュサーバーで検証結果を比べる
各段階のあと、主要な公開キャッシュサーバーそれぞれに問い合わせて、検証結果と NS がどう見えるかを並べます。キャッシュサーバーごとにキャッシュの状態が違うため、1か所だけでは判断できません。
zone=example.com
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
echo "== $r"
delv @"$r" "$zone" NS +nodnssec 2>&1 | grep -v '^$'
done@ に指定したキャッシュサーバーからレコードと鍵を取り寄せ、検証は手元の delv が行います。結果が fully validated と unsigned answer で混在するのは、移行中なら珍しくありません。注意が必要なのは、検証の失敗が表示される場合です。
よくある変更の流れと確認点
DNSSEC をいったん外してから事業者を移転する
署名の引き継ぎに対応していない事業者間で移る場合の、比較的安全な順序です。
- レジストラで DS を削除し、
delv example.com DSで DS が存在しない旨の否定応答になることを確かめます。 - 作業前に控えた DS の TTL が過ぎるのを待ち、
delv example.com NSがunsigned answerになることを確かめます。 - NS を新しい事業者に切り替え、NS の TTL が過ぎるのを待ちます。旧事業者のゾーンはこの間も残しておきます。
- 新しい事業者で署名を有効にし、
delv example.com DNSKEYで鍵が公開されたことを確かめてから、レジストラに新しい DS を登録します。 - DS の登録後、複数のキャッシュサーバーで
fully validatedになることを確かめます。
順序を入れ替えて、DS が残ったまま旧事業者の署名を止めたり、NS を署名していない事業者へ切り替えたりすると、DS の TTL の間は検証を行うキャッシュサーバーで名前解決に失敗します。
署名を維持したまま移転する
旧・新の事業者がお互いの鍵を公開し合う方法（マルチサイナーと呼ばれ、RFC 8901 で整理されています）なら、DNSSEC を外さずに移れます。ただし両方の事業者が鍵の取り込みに対応している必要があり、手順も事業者ごとに異なります。各事業者の公式の手順に従い、各段階で上のループを実行して検証の失敗が出ていないかを確かめます。
鍵を更新する
KSK を更新する場合は、新しい鍵を DNSKEY に追加し、DNSKEY の TTL が過ぎてから新しい DS を登録し、DS の TTL が過ぎてから古い DS と古い鍵を外します。子ゾーンが CDS・CDNSKEY というレコードで DS の更新を親に伝える仕組みもありますが、対応しているレジストリやレジストラは一部です（2026年10月現在）。使えるかどうかはレジストラの案内で確かめてください。
検証に失敗したときの切り分け
まず -i を付けて検証を外した結果と比べます。-i 付きでは答えが返るなら、原因は名前解決ではなく DNSSEC の設定です。その場合は、起こりやすい順に次を確かめます。
- 旧事業者の鍵を指す DS が親ゾーンに残っている。作業前の記録の DS と、現在の DNSKEY の鍵のタグを照合します。直すにはレジストラで DS を差し替えます。
- 新しい事業者で署名がまだ有効になっていないのに DS を登録した。
delv example.com DNSKEYで鍵が返るかを確かめ、返らなければ DS をいったん外します。 - DS のアルゴリズムやダイジェストの種類が、公開している鍵と合っていない。DS を事業者の管理画面に表示された値で登録し直します。
- 署名の有効期限が切れている。RRSIG の有効期限（UTC）を確かめ、署名を行う事業者やサーバーに更新が止まっていないかを問い合わせます。
- 手元のネットワークで大きな DNS 応答や TCP の問い合わせが止められている。別の回線や別のキャッシュサーバーで再現するかを確かめます。
どの段階で失敗しているかを詳しく見たいときは、+vtrace で検証の過程を表示します。また、@ に権威サーバーを指定すると親ゾーンの DS などを取得できず失敗することがあるため、検証の確認ではキャッシュサーバーを指定してください。古い delv は組み込みのトラストアンカーが古く失敗することもあるので、パッケージは最新にしておきます。
まとめ
- 変更の前に NS・DS・DNSKEY・SOA を delv でまとめて記録し、RRSIG の「元の TTL」から設定上の TTL を読み取ります。
- 次の段階へ進む前の待ち時間は、変更したレコードの TTL で決まります。DS の TTL は親ゾーン側の値です。
- 作業中は複数のキャッシュサーバーに delv で問い合わせ、検証の失敗が出ていないかを並べて確かめます。
- DNSSEC を外して移る場合は、DS の削除と TTL の経過を先に済ませてから NS を切り替えます。
- 失敗したら
-iで DNSSEC が原因かを切り分け、DS と DNSKEY の対応から順に確かめます。