CloudflareでDNSSECを有効化、DS反映前の移管は避ける

|著者: QUASA編集チーム|2 分で読めます
CloudflareでDNSSECを有効化、DS反映前の移管は避ける

CloudflareでDNSSECを有効にするには、ドメインの登録先を確認する。Cloudflare Registrarなら管理画面から有効化し、DSの登録は自動で進む。外部レジストラなら、Cloudflareが生成したDSの値を登録先へ渡す。いずれも操作直後を完了とせず、親ゾーンに期待するDSが公開され、検証リゾルバーで名前解決できることを確かめる。

権威DNSをこれからCloudflareへ移す場合は、先に旧事業者のDSを削除する。古いDSをキャッシュするリゾルバーが残る間にネームサーバーを切り替えると、新しい鍵と照合できず、名前解決がSERVFAILになる場合がある。DSが親ゾーンから消えたことに加え、削除前のDSのTTLが満了したことを切り替えの条件にする。

権威DNSの移行では、旧DSのTTL満了を待つ

旧DSの失効を待ってからCloudflareの権威ネームサーバーへ委任を変更する関係

別の権威DNSでDNSSECを使っているドメインは、レジストラで旧DSを削除してからCloudflareのネームサーバーへ委任を変更する。CloudflareのDNSSEC移行手順は、旧DSのTTL満了、NS変更、旧NSのキャッシュ失効、新しいDNSSECの有効化とDS登録という順序を示している。待機時間は対象ドメインのDSとNSのTTLを基準に判断する。

DSは親ゾーンに置かれ、子ゾーンが公開するDNSKEYへ検証の経路をつなぐ。旧DSを参照するリゾルバーが、新しいCloudflareの権威サーバーから異なる鍵を受け取ると、この経路を検証できない。Cloudflare側にAやMXなどのレコードを用意していても、検証に失敗したリゾルバーはその応答を利用者へ返せない。

親ゾーンの状態は「dig DS example.com +trace」で調べられる。example.comは対象ドメインに置き換え、結果のDSがどの権威サーバーから返されたかを見る。削除後に親ゾーンで旧DSが見えなくなっても、以前の応答を保持するリゾルバーが直ちに更新されるとは限らないため、元のTTLが尽きるまで待つ。

移行元が外部DNSKEYの公開に対応するなら、複数の署名者を使って検証の連続性を保つ移行方法もある。これは両側の鍵と署名を協調させる構成であり、通常のNS変更にそのまま適用できる手順ではない。対応を確認できない運用では、旧DSを外して待つ順序が明確だ。

Cloudflare RegistrarではDS登録が自動で進む

登録先がCloudflare Registrarなら、「Manage Domains」で対象ドメインの「Manage」を開き、「Configuration」から「Enable DNSSEC」を選ぶ。Cloudflare Registrarの公式手順によると、有効化は無料で、Cloudflare RegistrarがCDSとCDNSKEYを読み取ってレジストリへ情報を送り、初回の反映には1～2日かかる場合がある。

有効化の操作と、親ゾーンにDSが公開されることは別の段階だ。「DNS」内の「Settings」でDNSSECの状態がconfirmedになったか確認する。登録情報のDNSSEC欄にsignedDelegationと表示されることも手掛かりになるが、実際の名前解決はDNSへの問い合わせで確かめる。

Cloudflare Registrarを利用する場合でも、直前まで別の権威DNSを使っていたなら旧DSの扱いは変わらない。旧DSが親ゾーンから削除され、そのキャッシュのTTLも満了してからNSを変更する。Cloudflareの権威DNSへの委任が落ち着いた後に新しいDNSSECを有効化すれば、移行前の鍵を参照する期間と新しい署名を使う期間を分けられる。

外部レジストラでは表示されたDSを登録する

Cloudflareで生成されたDSの各項目を外部レジストラへ正確に登録する関係

登録先がCloudflare Registrar以外なら、対象ゾーンの「DNS」から「Settings」を開いてDNSSECを有効にし、表示される「DS record」の値を確認する。Cloudflareはゾーンに署名し、公開鍵とDS情報を生成する。通常はレジストラのDNSSEC設定にその値を入力して、レジストリを通じて親ゾーンへ公開してもらう。

DSの入力欄が分かれている場合は、Key Tag、Algorithm、Digest Type、Digestを対応する欄へ写す。これらは署名鍵を特定するための一組の値なので、別のドメインの値を流用したり、Digestの一部を省いたりしない。レジストラの選択肢にCloudflareが示す方式が見当たらなければ、似た名称の方式を推測で選ばず、対応する表記を確認する。

DSはCloudflareの通常のDNSレコード一覧へ追加するレコードではない。親ゾーンが公開する情報であり、Cloudflareの画面で署名が有効になっていても、登録側の作業が終わったとは限らない。登録方式や処理時刻はレジストラによって異なるため、保存後は画面の状態だけでなく、実際に公開されたDSを確認する。

例外として、CloudflareのDNSSEC手順では、Cloudflare Registrarを使うドメインに加え、.chと.czのドメインについてもDSを自動追加すると案内している。対象ドメインで自動登録が働く場合も、親ゾーンに公開された値をCloudflareの表示と照合する。自動処理か手動入力かよりも、公開結果の一致が重要になる。

親ゾーンのDSと検証結果を分けて確認する

親ゾーンのDSとCloudflareの鍵が一致する場合の認証済み応答と、古いDSによるSERVFAILの違い

まず「dig DS example.com +trace」で親ゾーンから返るDSを調べ、Cloudflareの「DS record」に表示された値と照合する。「dig +short DS example.com」は値を素早く見るのに便利だが、問い合わせ先のリゾルバーに残ったキャッシュを見ている可能性がある。+traceでは応答元を追えるため、親ゾーンへの登録状況を区別しやすい。

次に、DNSSECを検証するリゾルバーへ、実際に利用する名前とレコード種別を問い合わせる。Aレコードを持つドメインなら「dig A example.com +dnssec」を使い、応答ヘッダーのadフラグを見る。Cloudflareの検証手順では、DS、RRSIG、DNSKEYとadフラグの確認に加え、検証失敗時に+cdで切り分ける方法を示している。

adは、問い合わせたリゾルバーが応答を認証したことを示す。表示を短くする+shortを付けるとヘッダーが見えないため、adを確認するときは付けない。+dnssecは署名情報を要求する指定であり、その指定だけで検証が成功したと判断するものではない。DNSKEYやRRSIGが見える場合も、親ゾーンのDSから続く検証結果を別に見る。

通常の問い合わせがSERVFAILになり、同じ名前を「dig A example.com +dnssec +cd」で問い合わせると応答が得られるなら、DNSSEC検証の失敗を疑う。+cdは検証を抑えて原因を切り分けるための指定で、復旧操作ではない。公開中のDSが古い鍵を指していないか、Cloudflareの値と一致するか、権威NSが想定どおりかを調べる。

停止や再移行でもDSを先に処理する

CloudflareでDNSSECを止めるときや、権威DNSを別の事業者へ移すときも、親ゾーンのDSとそのキャッシュを先に考える。外部レジストラなら登録済みDSを削除し、Cloudflare側の署名は旧DSのTTLが満了するまで維持する。署名を先に失わせると、古いDSを保持する検証リゾルバーは応答を認証できなくなる。

Cloudflare Registrarでは管理画面からDNSSECを無効にできるが、DSの公開が消える時刻を利用者が指定できるわけではない。NSや署名鍵を続けて変更する作業では、親ゾーンに期待するDSまたはDSがない状態が公開されているか、旧DSのTTLが満了したかを確かめる。そのうえで移行先の権威NSと、検証リゾルバーからの名前解決を確認する。

関連記事：

共有:

関連記事

ニュースレターを購読

Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。

0