DNSSEC 不是把 DNS 查詢內容加密，也不會隱藏你的 IP。它的作用是讓支援驗證的 resolver 能確認：「這份 DNS 答案確實由該網域授權的 DNS 系統簽出，而且途中沒有被竄改。」
DNSSEC 最危險的情況不是沒開，而是 註冊商端還留著 DS 記錄，實際 DNS 服務商卻已換掉或停止簽署。此時支援 DNSSEC 驗證的網路會把答案判定為不可信，網站與信箱可能同時失效。
DNSSEC、DNSKEY 與 DS 分別做什麼？
| 名稱 | 放在哪裡 | 用途 |
|---|---|---|
| DNSKEY | 你的權威 DNS zone | 公開用來驗證簽章的金鑰資料 |
| RRSIG | 你的權威 DNS zone | DNS 記錄集合的數位簽章 |
| DS | 上層網域，例如 .com、.tw | 指向並驗證子網域 DNSKEY 的摘要 |
簡化後的信任鏈是：根網域信任 .tw，.tw 透過 DS 信任 example.tw 的 DNSKEY，resolver 再用 DNSKEY 驗證 A、MX 等記錄的 RRSIG。
DNSSEC 保護的是「答案真偽」，不是網站連線內容；網站仍需 HTTPS，Email 仍需 SPF、DKIM、DMARC。
先確認誰負責你的 DNS？
啟用前先查 NameServer：
dig example.com NS +short
你要在目前的 權威 DNS 服務商 建立 DNSSEC 金鑰與簽署，再把它提供的 DS 資料填到 網域註冊商。兩者有時是同一家公司，有時完全不同。
不要自行從畫面猜 Key Tag、Algorithm 或 Digest。應完整複製 DNS 服務商提供的 DS 欄位。
DNSSEC 正確啟用順序是什麼？
- 確認目前 A、AAAA、MX、TXT、CAA 等記錄都正確。
- 在權威 DNS 服務商啟用 DNSSEC。
- 取得服務商產生的 DS：Key Tag、Algorithm、Digest Type、Digest。
- 到網域註冊商提交 DS。
- 等上層網域發布後，從不同 resolver 驗證。
- 確認網站、Email 與 API 解析都正常。
有些整合式註冊商會自動完成 DS 發布；即使畫面只有一個開關，仍要在外部驗證，不要只相信後台顯示「已啟用」。
要怎麼用 dig 驗證？
macOS 或 Linux 可查：
dig example.com DNSKEY +dnssec
dig example.com A +dnssec
dig example.com DS +dnssec
再向會驗證 DNSSEC 的公共 resolver 查詢：
dig @1.1.1.1 example.com A +dnssec
dig @8.8.8.8 example.com A +dnssec
成功驗證時，回應 flags 常可看到 ad（Authenticated Data）。但只看到 DNSKEY 或 RRSIG，不等於整條信任鏈一定正確；仍要確認上層 DS 與目前 DNSKEY 對得上。
Windows 可先用瀏覽器的 DNSSEC 分析工具，或在 WSL 裡安裝 dig。企業環境若有自建 resolver，也要對內部 resolver 實測。
更換 DNS 服務商時怎麼避免全站失效？
這個操作必須把「DNS 記錄搬家」與「DNSSEC 信任鏈」一起規劃。
較安全的更換順序
- 在新 DNS 服務商完整建立並核對所有記錄。
- 先確認舊 NameServer 仍正常回答，不要急著刪 zone。
- 若無法做正式的 DNSSEC rollover，先在註冊商移除舊 DS。
- 等 DS 從上層網域移除並確認不再驗證舊金鑰。
- 更換 NameServer。
- 確認新 NameServer 全球可查、網站與信箱正常。
- 在新 DNS 服務商啟用 DNSSEC，再提交新的 DS。
- 驗證完成後才關閉舊 DNS zone。
若新舊供應商都支援協調式 rollover，可依雙方正式文件進行；不要自行同時貼多組不確定的 DS。
哪些情況先不要直接開？
- 不確定網域註冊商與 DNS 服務商分別是誰。
- 近期正在換 NameServer、搬站或調整 Email。
- DNS 服務商無法提供明確 DS 資料或正式操作文件。
- 沒有人能在異常時修改註冊商端 DS。
這不是說 DNSSEC 不值得使用，而是應先確認責任邊界與復原方式。
.tw 網域現在會自動有 DNSSEC 嗎？
TWNIC 自 2026 年 2 月 2 日起，對使用其 DNS 代管服務的網域預設啟用 DNSSEC。這不代表所有 .tw 網域都自動完成：如果你的 NameServer 在 Cloudflare、主機商或其他 DNS 供應商，仍依該服務商與註冊商流程處理。
判斷依據永遠是實際 NS、DNSKEY 與上層 DS，不是只看網域後綴。
DNSSEC 壞掉時會看到什麼？
常見現象包括：
- 有些網路完全打不開，有些不驗證的 resolver 卻正常。
dig回傳SERVFAIL。- 權威 DNS 直接查得到答案，經驗證 resolver 卻失敗。
- 網站、API、Email 同時出問題，但伺服器本身都在線。
排錯時比較：
# 直接問權威 DNS
dig @ns1.example-dns.com example.com A +dnssec
# 問會做 DNSSEC 驗證的 resolver
dig @1.1.1.1 example.com A +dnssec
若權威端正常而驗證 resolver 回 SERVFAIL，優先檢查 DS 與 DNSKEY 是否不一致。不要把 TTL、CDN 快取或主機防火牆當成第一個方向。
完成後檢查清單
- NameServer 是目前預期的 DNS 服務商
- DNSKEY 與 RRSIG 可查到
- 上層 DS 與現行 DNSKEY 相符
- Cloudflare、Google 與公司內部 resolver 都能解析
- 網站、MX 與必要 API 子網域皆正常
- 已記錄未來換 DNS 服務商時的 DS 移除／重建順序
如果你還不熟悉 NS 與 DNS 查詢，先讀 WHOIS、RDAP、nslookup 與 dig 查詢教學；正在搬站則搭配 網站搬家 DNS、Email、SSL 檢查清單。需要協助確認 DNS 責任邊界，可從 聯絡我們 提供網域與目前 NameServer，我們會先從公開解析結果協助判斷。
官方參考：ICANN DNSSEC 說明、Cloudflare DNSSEC 文件、TWNIC DNS 代管 DNSSEC 公告。