DNSSEC 驗證檢測工具
向 Google、Cloudflare 等多個公共 DNS 解析器查詢域名的 DNSKEY 記錄，檢測其 DNSSEC 簽名鏈是否驗證通過。
使用提示
- AD（Authenticated Data，已驗證資料）標誌只有在您查詢的 DNS 解析器自身執行了 DNSSEC 驗證時才會被設定。不支援 DNSSEC 的解析器無法給出有意義的判定結果。
- "DNSSEC 未啟用"並非錯誤——目前大多數域名仍未使用 DNSSEC，這不會直接影響搜尋排名或郵件送達率。
- 若判定為"驗證失敗"，請先確認在註冊商後臺登記的父區域 DS 記錄的金鑰標籤（Key Tag）與摘要是否與當前 DNSKEY 一致。
- DNSSEC 簽名（RRSIG）具有有效期。請同時確認區域管理軟體的自動重新簽名是否已停止執行。
- 剛啟用 DNSSEC 後，在 DS 記錄傳播到父區域完成之前，可能會暫時顯示為"驗證失敗"。
常見問題
"DNSSEC 未啟用"本身並不危險，目前絕大多數域名仍在沒有 DNSSEC 的情況下執行。不過作為防範 DNS 快取投毒的手段，如果條件允許，值得考慮啟用它。
使用強制執行 DNSSEC 驗證的解析器（許多企業網路及部分 ISP）的使用者，可能完全無法解析該域名（會被當作 SERVFAIL 處理）。除非是剛啟用 DNSSEC、DS 記錄尚在傳播中的臨時狀態，否則需要儘快修復。
在 DNSKEY 更新（金鑰輪換）後不久，新舊金鑰可能會在不同解析器的快取中短暫共存，導致驗證結果暫時出現差異。請稍等片刻後再次檢測。
兩者不同。DNSSEC 保證的是"域名解析響應未被篡改"，而 SSL/TLS 保證的是"通訊內容已加密，且連線物件確實持有該證書"。二者相互獨立，只啟用其中一項的情況也是存在的。
本工具僅檢測表層狀態：DNSKEY 是否已釋出，以及解析器是否報告 AD 標誌。如需對完整簽名鏈（RRSIG、NSEC/NSEC3 一致性等）進行嚴格分析，請配合使用 dnsviz.net 等專業工具。
閒話 ― DNS 為何需要一套防止"冒充"的機制
DNS 在 1983 年設計之初，並沒有一種加密手段來確認響應的真實發送者。解析器只是信任任何看起來帶有合理事務 ID 的 UDP 資料包——這是一種建立在"性善說"之上的協議，容易受到源 IP 偽造和 ID 猜測攻擊。2008 年，安全研究員 Dan Kaminsky 發現這一弱點可被用於以實際可行的速度進行快取投毒攻擊（將偽造記錄注入解析器快取），這一發現震驚了整個行業。
DNSSEC（DNS 安全擴充套件）正是對這一問題的標準化回應。它利用公鑰加密技術證明"該響應確實由區域的合法管理者簽名"。域名使用自己的 DNSKEY 對記錄進行簽名，而在父區域註冊的 DS 記錄則擔保該金鑰的摘要，從而從 DNS 根區域一直到具體域名，構建起一條不間斷的"信任鏈"。
DoH（基於 HTTPS 的 DNS）響應中的 AD（Authenticated Data）標誌，正是解析器代為完成這一 DNSSEC 驗證的結果。應用程式無需自行實現簽名驗證——只要向可信解析器查詢並看到 AD=true，即可間接確認響應未被篡改，前提是解析器與應用之間的通訊（HTTPS）本身已受到保護。