DNSSEC 透過數碼簽署建立 DNS 信任鏈，讓解析器確認紀錄來自授權 DNS 服務，而不是被偽造或竄改。它不會加密查詢，也不能代替 HTTPS；設定時最重要的是讓 Cloudflare 金鑰和註冊商的 DS 記錄一致。
先分清 DNS 服務商與網域註冊商
Cloudflare 負責權威 DNS 和簽署區域，網域註冊商則把 DS 提交到上層網域。開始前記下註冊商、目前名稱伺服器及誰有權修改 DS。
DNSSEC 保護的是信任鏈
權威 DNS 會用私密金鑰簽署紀錄並公開 DNSKEY；上層網域保存對應 DS 摘要。解析器沿著根網域、頂級網域和你的網域逐層驗證。任何一層的摘要與實際金鑰不符，都可能令支援 DNSSEC 的解析器回傳失敗。
啟用前先確認網站正常
先檢查 A、AAAA、CNAME、MX、TXT 和名稱伺服器是否正確，並保存 DNS 匯出或截圖。DNSSEC 不會修正錯誤紀錄；若網站本身已有間歇解析問題，啟用後會增加排查難度。先讓普通 DNS 狀態穩定。
在 Cloudflare 產生簽署資料
進入網域的 DNS 設定並啟用 DNSSEC。Cloudflare 會簽署區域、發佈公開金鑰並顯示 DS 所需資料，包括 Key Tag、演算法、摘要類型和 Digest。不要自行推算或改寫值，應完整複製控制台提供的內容。
在註冊商加入 DS 記錄
若網域不在 Cloudflare Registrar，通常需要到原註冊商的 DNSSEC 頁面新增 DS。把每個欄位放入相對應位置，避免把 Digest 貼進 Key Tag。Cloudflare 常用的演算法 13 亦可能顯示為 ECDSA Curve P-256 with SHA-256。
不要手動新增普通 DNS 類型的 DS
DS 記錄屬於父區域的委派資料，不是一般放在 Cloudflare DNS 紀錄清單中的網站紀錄。若只在自己的區域新增一個看似相同的資料，並不會建立完整信任鏈。必須由註冊商或上層 DNS 操作。
等待上層網域更新
註冊商接受 DS 後，狀態未必即時確認。更新速度受註冊商、Registry 和 TTL 影響。等待期間不要重複建立多份不同 DS，也不要因數分鐘未生效便關閉服務。先查看 Cloudflare 狀態和公開查詢結果。
驗證 DS、DNSKEY 和簽章
確認父區域能查到 DS、權威伺服器能提供 DNSKEY 和 RRSIG，並用 DNSSEC 分析工具檢查信任鏈。也要測試郵件、子網域和不同公共解析器。
發生 SERVFAIL 先查金鑰不匹配
若部分網絡突然無法開啟網站，但未驗證 DNSSEC 的解析器仍正常，常見原因是舊 DS 指向不再使用的金鑰。不要先改網站 IP 或重裝 WordPress。比較父區域 DS 與目前 Cloudflare 提供的值，找出信任鏈斷點。
遷移名稱伺服器要特別小心
從舊 DNS 服務商遷移到 Cloudflare 前，若原有 DNSSEC 仍啟用，舊 DS 可能與 Cloudflare 金鑰不符。一般流程是先移除舊 DS、等待其 TTL 完全過期，再更換名稱伺服器及啟用新的 DNSSEC。未等過期便切換可能導致連線失敗。
關閉 DNSSEC 的順序不能倒轉
如需回復未簽署狀態，先在註冊商移除 DS，並保持 Cloudflare 區域簽署，直至父區域的 DS TTL 過期；之後才停用簽署。若先關閉 Cloudflare DNSSEC 而父區域仍宣告信任，解析器會尋找已不存在的有效簽章。
Cloudflare Registrar 的流程較自動
網域若由 Cloudflare Registrar 管理，DS 提交通常由平台透過 CDS/CDNSKEY 處理，確認可能需要一至兩天。不要因未即時顯示便建立矛盾設定。以 DNS 設定頁的確認狀態和公開信任鏈為準。
DNSSEC 不取代其他安全措施
DNSSEC 無法阻止 WordPress 密碼被盜、主機漏洞、惡意外掛或錯誤 DNS 修改。仍要保護註冊商帳戶、啟用雙重驗證、鎖定網域轉移、使用 HTTPS 並保留 DNS 變更紀錄。控制面帳戶安全同樣重要。
結語
Cloudflare DNSSEC 的核心流程是：先確認普通 DNS 正常，在 Cloudflare 產生簽署資料，於註冊商加入完全一致的 DS，再驗證整條信任鏈。遷移或停用時尊重 DS TTL 和正確順序，便能避免因金鑰不匹配造成網站斷線。
