2026年6月17日

DSレコードのTTLを変更する方法｜親ゾーンが決める値と、自分で変えられるケース

DNS・名前解決

DSレコードのTTLは、多くの場合ドメインの持ち主が自由に変えられる値ではありません。DSは自分のゾーンではなく親ゾーン（.com や .jp のレジストリ）に置かれるため、TTLは親ゾーンの運用者が決めます。自分で変えられるのは、サブドメインを別のDNSに委任していて、親側のゾーンも自分で管理している場合です。この記事では、DSのTTLを誰が決めているのかの確かめ方、自分で変えられるケースの設定方法、変えられない場合に鍵の更新やDNSSECの無効化でTTLをどう見込むかを説明します。

DSレコードのTTLは誰が決めているのか

DNSSECでは、親ゾーンに登録したDSが子ゾーンの鍵（DNSKEY）を指すことで、信頼の連鎖がつながります。DSはゾーンの切れ目の「親の側」に属するレコードなので、問い合わせに答えるのも、TTLを決めるのも親ゾーンの権威サーバーです。

一般的なドメインでは、次の流れでDSが親ゾーンに載ります。

利用者がレジストラの管理画面でDSの値（キータグ・アルゴリズム・ダイジェスト種別・ダイジェスト）を登録する
レジストラがその値をレジストリに送る
レジストリが親ゾーンにDSを載せる。このときTTLはレジストリのゾーン全体の方針で決まる

レジストラの画面にDSの入力欄はあっても、TTLの欄が無いのはこのためです。仮に自分のDNSサービスのゾーンにDSという種類のレコードを書いても、それは親ゾーンのDSとは別物で、DNSSECの検証には使われません。

現在のDSのTTLを確かめる

まずは今のTTLを正しく読み取ります。普段使っているリゾルバに問い合わせると、キャッシュの残り時間が表示されて値が小さく見えることがあります。元のTTLを知りたいときは、親ゾーンの権威サーバーに直接問い合わせます。

# .com の場合：親の権威サーバーに直接 DS を問い合わせる（2列目がTTL）
dig @a.gtld-servers.net example.com DS +norecurse

# .jp などほかのTLDは、先に親の権威サーバー名を調べる
dig jp NS +short
dig @a.dns.jp example.jp DS +norecurse

# 参考：リゾルバ経由（キャッシュの残り時間が出る）
dig example.com DS

執筆時点（2026年10月現在）に親の権威サーバーへ問い合わせたところ、.com のDSは86400秒（1日）、.jp のDSは7200秒（2時間）でした。この値はTLDごとに異なり、レジストリの方針で変わることもあるため、作業の前に上のコマンドで自分のドメインのTLDを確認してください。

自分でDSのTTLを変えられるケース

親ゾーンを自分で管理している場合は、DSのTTLを自分で決められます。典型的なのは、example.com は自分のDNSサービスで管理し、sub.example.com だけを別のDNSサービスやサーバーに委任して、そちらでDNSSECの署名をしている構成です。この場合、DSは example.com のゾーンの中にあり、ほかのレコードと同じようにTTLを付けられます。

BINDなど自前の権威サーバーの場合

親ゾーン（example.com）のゾーンファイルで、委任のNSと並べてDSを書きます。TTLは行ごとに指定できます。

; example.com のゾーンファイル（親側）
sub      3600  IN  NS  ns1.sub-dns.example.net.
sub      3600  IN  NS  ns2.sub-dns.example.net.
sub      3600  IN  DS  12345 13 2 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF

DSの値はダミーです。実際の値は、子ゾーンのKSK（フラグが257の鍵）から計算したものを使います。変更の前にはゾーンファイルをバックアップし、SOAのシリアル番号を上げ、named-checkzone example.com /etc/bind/db.example.com で文法を確かめてから読み込み直します。親ゾーン自体を署名している場合は、DSも署名の対象になるため、再署名が行われる設定になっているかも確認します。

クラウドのDNSサービスの場合

Amazon Route 53 や Cloudflare など、レコードの種類にDSを選べるDNSサービスでは、親ゾーン側にDSを作る際にTTLを指定できます。どの画面でどう指定するかはサービスや時期によって異なり、Cloudflare のように自動設定のTTLを選べるサービスもあります。DSの種類を選べないサービスでは、サブドメインのDNSSEC委任そのものができないので、サービスのドキュメントで対応状況を確認してください。

TTLを変えるときの順序と考え方

自分でTTLを変えられる場合でも、短くしたい理由の多くは「鍵を差し替えるときの待ち時間を減らしたい」ことです。ここで注意したいのは、TTLを短くした効果が出るのは、変更前の長いTTLのキャッシュが切れたあとだという点です。

鍵の更新などの作業を予定したら、まずDSのTTLを短い値（例：300〜3600秒）に変える
変更前のTTLが過ぎるまで待つ。これで、リゾルバには短いTTLのDSしか残らなくなる
鍵の更新やDSの差し替えを行う
作業が落ち着いたら、TTLを元の長さに戻す

短いTTLのまま運用し続けると、リゾルバの問い合わせが増え、親ゾーンの権威サーバーが止まったときの影響も受けやすくなります。DSは頻繁に変えるレコードではないため、普段は長め、作業の前後だけ短く、という使い分けが現実的です。

TTLを変えられない場合の作業計画

一般的なドメインでDSのTTLを変えられないときは、TTLを短くする代わりに、そのTTL分を待つ前提で作業の順番を組みます。

KSKを更新する場合

新しいKSKのDSを先に追加し、古いDSと並べて載せた状態にします。親ゾーンで新しいDSが見えることを権威サーバーへの問い合わせで確かめ、さらに古いDSのTTL（.com なら1日）が過ぎてから古いDSと古い鍵を外します。新旧の鍵をしばらく並べておくのは、リゾルバのキャッシュに古いDSしか無い間も検証を通すためです。

DNSSECを無効にする場合

レジストラでDSを削除し、親ゾーンからDSが消えたことを確認してから、DSのTTLが過ぎるのを待ちます。その後で子ゾーンの署名を止めます。順番を逆にして先に署名を止めると、キャッシュに残ったDSと署名の無いゾーンが食い違い、検証するリゾルバからSERVFAILが返ります。

DNSSECを新しく有効にする場合

最初にDSを登録するときは、DSの値ではなく「DSが存在しない」という結果がキャッシュされている点に注意します。この否定応答の保持時間は親ゾーンのSOAから決まります。新しいDSが見えるまでに少し時間がかかっても、親の権威サーバーで登録が確認できていれば、待てば反映されます。

CDS・CDNSKEYによる自動更新とTTL

レジストリによっては、子ゾーンに置いたCDS・CDNSKEYレコードを読み取ってDSを自動で更新する仕組み（RFC 7344、RFC 8078）に対応しています。DNSサービスの中には、これを使って鍵の更新を自動化するものもあります。ただし自動化されても、親ゾーンに載るDSのTTLは引き続き親ゾーンが決めます。自動更新に任せる場合も、反映までの待ち時間はTLDごとに異なると考えておいてください。対応しているTLDや運用はレジストリごとに異なり、変わることもあります。

まとめ

DSは親ゾーンに置かれるレコードで、TTLは通常レジストリが決める。レジストラの画面にTTLの欄が無いのはこのため
元のTTLは、親の権威サーバーに +norecurse で直接問い合わせて確かめる。TLDごとに値が異なる
親ゾーンも自分で管理している委任サブドメインなら、DSのTTLを自分で指定できる
TTLを短くする効果は、変更前のTTLが過ぎてから出る。作業の前に下げ、終わったら戻す
変えられない場合は、KSKの更新では新旧のDSを並べ、無効化ではDS削除→TTL経過→署名停止の順を守る