CloudflareでDNSSECを設定する手順と注意点

DNSSECの概念（初心者向け）

ここではDNSSECが何を保証するのかと、その限界を短く説明します。初心者がまず押さえるべきポイントを明確にします。

DNSSECが守るものと守らないもの

保護対象と制限を簡潔に示します。

• 守るもの: DNS応答の整合性と真正性（応答が権威ゾーン発のもので改ざんされていないこと）を検証します。
• 守らないもの: DNSクエリの機密性（通信の暗号化）は提供しません。TLSやHTTPSなど別レイヤでの保護が必要です。
• 注意点: 親ゾーン（TLD）との不整合や鍵管理ミスは名前解決不能（SERVFAIL）を招きます。

主要コンポーネントとその役割

各要素の役割を短く説明します。

• DNSKEY: 子ゾーンに公開鍵を置きます。ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）の運用方式はゾーンやサービスにより異なります。
• DS: 親ゾーンに置かれるダイジェストで、子のDNSKEYを指し示します。これが親側にあることで信頼の連鎖が始まります。
• RRSIG: 個々のレコードではなく、同一の名前・タイプのレコード集合（RRset）に対する署名です。署名はRRsetレベルで付与されます。
• NSEC / NSEC3: 存在しない名前の証明に使うレコードで、ゾーンの列挙防止方式や挙動に違いがあります。

導入判断とリスク（運用者向けの視点）

導入の利点と、運用で注意すべきリスクを整理します。運用者は導入前に影響範囲と手順を明確にする必要があります。

導入効果（なぜ導入するか）

導入で得られる主要な利点を示します。

• DNS応答の改ざんやキャッシュポイズニングのリスクを低減します。
• DNSの信頼チェーンが整備されることで、検証可能な名前解決を提供できます。

導入前の必須準備

実務で最低限整えるべき項目を列挙します。

• ゾーンがCloudflareで管理されているか（Cloudflareのネームサーバーが設定済みか）を確認する。
• レジストラがDSレコード登録に対応しているかを確認する。TLDや契約により対応が異なるため、事前確認が必須です。
• Cloudflareとレジストラ双方の管理権限を用意する。オンコール連絡先と作業ウィンドウを決める。
• 変更前のゾーン設定（NS、TTL、現在のDNSSEC状態）をエクスポートまたは記録する。
• 切り戻し手順と連絡フローを用意する。TTLを下げるなどの事前対策も検討する。

推奨・非推奨のアルゴリズムとダイジェスト

古いアルゴリズムを避け、実務的に推奨される選択肢を示します。

• 推奨（優先して検討する）: Ed25519（可能なら、レジストラの対応確認必須）、ECDSA P-256（ECDSAP256SHA256、一般的に広いサポート）、RSASHA256（互換性が高いが鍵長に注意）。
• 非推奨: SHA-1 を用いるダイジェスト（DSダイジェストタイプ 1）は避ける。SHA-1 に依存するアルゴリズムも旧式です。
• DSダイジェストタイプの番号例: 1＝SHA-1（非推奨）、2＝SHA-256（推奨）、4＝SHA-384（利用可能なら推奨）。
• 備考: 使用するアルゴリズムはレジストラのサポートに依存します。事前に対応状況を確認してください。

Cloudflare DNSSEC 設定手順（運用者向け）

ここではCloudflare側の操作と、レジストラ側での登録手順を運用者目線で順を追って示します。UIは変わることがあるため、画面上のラベルを確認しながら作業してください。

Cloudflareでの有効化とDS情報の取得

Cloudflareダッシュボードでの基本的な流れと注意点を示します。

1. Cloudflareにログインし、対象ドメインを選択します。
2. 「DNS」タブを開き、DNS設定の中の「DNSSEC」セクションを探します。
3. 「DNSSECを有効にする（Enable DNSSEC）」をクリックして有効化します。
4. 有効化後、Cloudflareが表示するDS情報（Key Tag／Algorithm／Digest Type／Digest）を取得します。
5. 表示された値はそのままレジストラに登録するための正確な情報です。空白や改行が混入しないように注意してコピーします。

注意事項: Cloudflare側はRRsetに対して署名を付けます。Cloudflareの表示値を改変して登録しないでください。Cloudflare Registrarを使用している場合、親への反映が自動化されることが「場合による」ため、動作を過信せず必ず後続の検証を行ってください。

レジストラでのDS登録手順と注意点

レジストラごとに入力フォームが異なります。一般的な登録方法と実務上の落とし穴を説明します。

• レジストラ管理画面で「DNSSEC」または「DSレコード追加」を選ぶ。
• Cloudflareが示した Key Tag、Algorithm、Digest Type、Digest をフィールドに正確に入力する。
• コピー時に余計な空白や改行、区切り文字（スペースやコロン）を入れない。
• レジストラが分割入力を要求する場合は、分割の方式に合わせて貼り付ける。
• レジストラが特定のアルゴリズムをサポートしているか事前に確認する。未サポートの場合は別のアルゴリズムを選ぶ必要がある。

例: レジストラ入力のフィールド名と期待値のサンプル（実運用ではCloudflareダッシュボードの実値を利用してください）

DS自動登録の扱い（Cloudflare Registrar等）

Cloudflare Registrarなどでは一部TLDでDSの親反映が自動化されることがあります。ただしこれはTLDと契約条件に依存します。自動であっても必ずTLD権威サーバへ直接問い合わせて反映を検証してください。

検証コマンドと出力例（運用での確実な確認手順）

設定後の検証は複数の観点から行います。ここではコマンド例と出力例を示し、どこを見ればよいかを説明します。

TLD権威サーバへ直接問い合わせる方法

親ゾーン（TLD）の権威サーバへ直接問い合わせると反映状況を確実に確認できます。gTLDの例では a.gtld-servers.net などが利用できます。

返る値は「KeyTag Algorithm DigestType Digest」の形式です。何も返らなければDSは登録されていません。

代表的なコマンド例と出力の読み方

ここでは検証用の基本コマンドと、成功・失敗の簡易例を示します。 を実際のドメイン名に置き換えてください。

• 親のDS確認（TLD権威サーバへ直接）

• 子のDNSKEY確認（権威サーバへ）

• リゾルバ経由での検証（ADフラグの確認）

出力ヘッダに "ad" が含まれていれば、問い合わせたリゾルバが検証済みと判断しています。ただし、ADフラグはそのリゾルバにおける状態であり、TLD側の反映確認とは別です。

• 失敗例（親と子が不一致で検証エラー）

SERVFAIL は親のDSと子のDNSKEYが不一致などで検証が失敗していることを示す典型的な症状です。

• delv / drill の利用例

これらは詳しい検証ログを出力するため、トラブルシュートで有用です。

オンラインツールでの可視化

可視化ツールで問題箇所を把握します。代表的なツールは次の通りです。

• DNSViz（可視化と問題箇所の指摘） — 第三者ツール
• Verisign Labs DNSSEC Analyzer — 第三者ツール
• ZoneMaster — オープンソースの検査ツール

公式ドキュメントとオンライン解析結果を組み合わせて、親子の不整合、署名欠落、NSEC/NSEC3の問題などを特定してください。

よくあるトラブルとロールバック（運用向け）

運用で頻出する障害と、緊急時の優先対応フローを示します。影響範囲が大きいため順序と連絡体制を明確にしてください。

よくある障害と対処例

主な障害パターンと初動の対処をまとめます。

• 親にDSが無い
• 検証: TLD権威サーバへ直接問い合わせて確認する。

• 対処: レジストラでの登録状況を確認し、サポートへ連絡する。

• DS不一致（誤登録）

• 検証: 親のDSと子のDNSKEYのダイジェストを比較する。

• 対処: レジストラでDSを修正または削除し、Cloudflare側のDNSKEYが期待通りか確認する。

• 署名欠落（RRSIGが無い／不正）

• 検証: 権威サーバでDNSKEYとそれを署名するRRSIGが存在するか確認する。
• 対処: CloudflareのDNSSEC設定を確認し、必要ならサポートへ連絡する。

緊急ロールバック手順と想定時間（運用目線）

緊急時に迅速に復旧するための手順と概算時間を示します。実際の時間はレジストラやTLDの反映に依存します。

1. 初動（検出→診断）: 0–15分で障害確認と影響範囲特定。
2. 初期対応（暫定回避）: 15–60分で対処方針決定。対処の候補は以下。
3. レジストラに連絡して該当DSを一時削除してもらう（最も即効性があることが多い）。
4. Cloudflare側でDNSSECを無効化する。ただし親に不整合なDSが残ると根本解決にならない場合がある。
5. 反映と確認: レジストラ側の操作後、数分〜最大48時間程度で世界中の検証値が安定する。多くのケースでは数分〜数時間で改善が見られますが、最悪はTTLやキャッシュの影響で最大48時間程度を想定してください。
6. 後処理（復旧→原因調査）: 復旧確認後、原因分析と再発防止を実施。変更履歴と通信ログを保存する。

役割例（参考）:

• DNS運用担当: コマンド実行・Cloudflare操作（初動担当）
• レジストラ担当: DSの修正・削除依頼窓口
• SRE/オンコール: 影響調査とサービス切り戻し判断
• コミュニケーション担当: 利害関係者への状況連絡と情報共有

実務チェックリスト（作業前／作業中／作業後）

事前準備・実行中・実行後で確認すべき項目をまとめます。

• 作業前: 管理権限確認、エクスポート（NS/TTL/既存DNSSEC状態）、連絡先一覧、切り戻し手順の確認。
• 作業中: CloudflareでDS取得→レジストラへ登録→TLD権威サーバでDS確認。ログと時間を記録。
• 作業後: dig/drill/delvやDNSVizで検証、監視アラートの確認、TTLを元に戻す場合は段階的に実施。

参考（公式／第三者）

公式情報と第三者情報を区別して示します。運用判断はまず公式ドキュメントを確認してください。

• 公式（Cloudflare）: Universal DNSSEC — Cloudflare のDNSSECに関する公式解説
  https://www.cloudflare.com/ja-jp/learning/dns/dnssec/universal-dnssec/

• 公式（IANA）: DNSSEC Algorithm Numbers / DS Digest Types（アルゴリズムやダイジェストの正式番号確認に使用）
  https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

• 第三者ツール: DNSViz、Verisign Labs、ZoneMaster（可視化・解析用、結果は解釈が必要）

第三者の解説記事やユーザブログは実例が参考になりますが、登録や運用の決定は公式情報に基づいて行ってください。

まとめ

導入前にリスクと準備を明確にし、Cloudflareでの有効化→レジストラ登録→TLD権威サーバでの直接確認、という順序を必ず守ってください。検証は複数の手段で行い、問題発生時はレジストラへDSの一時削除依頼が最速の回避策となることが多いです。運用ではアルゴリズムやダイジェストのサポート状況を事前確認し、SHA-1系は避ける運用を推奨します。

• 事前準備: 管理権限、レジストラ対応確認、切り戻しフローの整備。
• 実行順序: Cloudflareで有効化 → DS取得 → レジストラへ登録 → TLD権威サーバで検証。
• 緊急対応: 初動で原因特定→必要ならレジストラにDS削除依頼またはCloudflareの無効化→復旧確認→原因分析。

参考リンクは公式優先で確認し、レジストラの挙動（自動反映の有無など）は必ず自身で検証してください。