更換 DNS 後網域變成 SERVFAIL？檢查 DNSSEC 與註冊商 DS 紀錄

更換權威 DNS 後，部分使用者看到網域不存在或 SERVFAIL，但 DNS 後台明明有 A 紀錄。若原供應商的 DNSSEC 已啟用，註冊商留存的舊 DS 與新供應商金鑰不相符，驗證解析器可能拒絕回應；這只是可能原因之一，不能直接刪除 DS 下結論。

先保留現況與影響範圍

確認網域、目前權威名稱伺服器、DNS 供應商、註冊商與最近切換時間。記錄原 DS 全部欄位、目前 DNSSEC 狀態與重要 DNS 記錄，並確認郵件和其他子網域影響。DS 是父區與子區信任鏈的一環；修改可能影響整個網域的解析，應由持有雙方權限的管理者安排維護並備妥回復方案。

比較驗證與不驗證的查詢

在有 dig 的電腦，將 example.com 改成自己的網域，向同一個支援 DNSSEC 驗證的遞迴解析器查詢：

dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec +cd

第一個查詢若是 SERVFAIL，第二個在停用該查詢的驗證檢查後取得 A 答案，是 DNSSEC 驗證有問題的線索，但不證明一定是 DS 錯誤，也不證明答案可信。兩者都失敗時還要查授權伺服器與連線。不要把 +cd 當成正式修復，或用不驗證結果證明網域安全。詳見Cloudflare 官方疑難排解。

比對 DS 與目前的 DNS 提供者

執行 dig example.com DS +dnssec 查看遞迴解析器觀察到的 DS，再於註冊商核對實際設定，並與目前權威 DNS 供應商顯示的 DS 欄位逐一比對 key tag、演算法、digest type 與 digest。DNS 快取可能讓不同位置暫時看到不同結果；如有多筆 DS 或正在輪替金鑰，請供應商判讀整個信任鏈，勿自行刪掉看似多餘的紀錄。

修正與驗收

先與現任 DNS 供應商及註冊商確認正確的遷移或金鑰輪替程序與等待時間；只有確認影響與回復步驟後才修改 DS。移除 DS 會使委派暫時不受 DNSSEC 驗證保護，不能當作無風險操作。完成後從多個驗證解析器重查，確認不再 SERVFAIL，並測試網站與郵件相關解析；依 TTL 和父區更新時間持續觀察。若狀況惡化，請供應商依保存的信任鏈狀態協助恢復，不能只盲目貼回舊 DS。一般搬家解析排查可參考nslookup 比對 DNS。

核對權威區及等待更新

先確認實際名稱伺服器，將命令中的 ns1.example.net 換成該網域的權威伺服器，再觀察 DNSKEY：

dig example.com NS +short
dig example.com DS +dnssec
dig @ns1.example.net example.com DNSKEY +dnssec

DS 包含 key tag、演算法、digest type 與 digest；DNSKEY 是不同格式，不能直接將 digest 與公開金鑰文字逐字比較，應由供應商或驗證工具計算並檢查信任鏈。輪替期間可能同時有多筆 DS，不能只因 key tag 不同就刪除。分別記錄註冊商顯示值、父區對外 DS、現任供應商提供值與觀察時間。

註冊商顯示更新不代表父區和所有遞迴解析器立即更新。等待應考慮註冊商處理、父區發布以及 DS／DNSKEY 快取 TTL；期間持續以多個驗證解析器查詢，避免因暫時看到舊值而反覆修改。

仍失敗時如何恢復原狀

若等待後仍 SERVFAIL，保留結果與時間，請兩端供應商確認父區實際 DS、子區簽章與 DNSKEY。回復前必須確認舊權威 DNS 仍在線、舊簽章與對應金鑰仍有效，再依供應商安排名稱伺服器及 DS 變更順序與快取等待；只貼回舊 DS 而保留新權威 DNS 可能延長故障。若暫時移除 DS，管理者需明白 DNSSEC 驗證保護會暫停，並安排以正确信任鏈重新啟用及持續監測。