關於網域與DNS
什麼是DNSSEC?驗證結果的意義與限制
說明有效、未設定、驗證失敗與無法判定的差異,以及DS、DNSKEY和註冊資訊的差異。
更新日期: 2026年10月9日
DNSSEC透過數位簽章協助驗證DNS資料是否由負責區域發布,但不會加密DNS通訊。
在NetKarte中
在DNSSEC檢查輸入網域或主機名稱,完成驗證後搜尋。應查看狀態與驗證結果,不能僅因存在DS或DNSKEY就判定驗證成功。
NetKarte使用Cloudflare的驗證解析器。當DS、DNSKEY與SOA回應正常、存在DS與DNSKEY,且三個回應均帶有AD(Authenticated Data)時,顯示「有效」。NetKarte不會獨立驗證所有簽章。
未回傳DS且相關查詢正常回應時顯示「未設定」。此判斷不要求AD,也不表示NetKarte本身驗證了附簽章的不存在證明。帶有特定DNSSEC延伸錯誤的SERVFAIL顯示為「驗證失敗」,證據不足時顯示「判定不能」。查詢本身失敗時,也可能顯示取得錯誤。
注意事項
DNSSEC驗證DNS資料真實性,但不加密查詢。驗證成功也不保證網站整體安全,TLS憑證與Application Security屬於不同層面。
先讀狀態,再看記錄
輸入名稱後,先確認輸入主機名稱與判定區域。子網域可能透過SOA找到另一個區域。先讀狀態及驗證結果,再看DS和DNSKEY。
DS的Key Tag、Algorithm、Digest Type、Digest要按同一記錄閱讀;DNSKEY的Flags、Protocol、Algorithm、Key Tag也一樣。換鑰等過程可能出現多筆DS或金鑰,不能憑數量判斷異常。目前不顯示公鑰全文。
與註冊資訊不同的原因
網域查詢顯示註冊服務公開資料,DNSSEC檢查使用目前DNS回應及解析器驗證。來源與區域可能不同,資訊缺失不等於驗證失敗。失敗時,將判定區域與狀態告知DNS管理員,以檢查簽章及父區域DS。
參考資料
- IETF / RFC Editor: RFC 4033: DNS Security Introduction and Requirements (外部網站)確認日期: 2026-10-09
- IETF / RFC Editor: RFC 4034: Resource Records for the DNS Security Extensions (外部網站)確認日期: 2026-10-09
- IETF / RFC Editor: RFC 4035: Protocol Modifications for DNSSEC (外部網站)確認日期: 2026-10-09
- IETF / RFC Editor: RFC 8484: DNS Queries over HTTPS (外部網站)確認日期: 2026-10-09