DNSSEC 驗證檢測工具
向 Google、Cloudflare 等多個公共 DNS 解析器查詢域名的 DNSKEY 記錄，檢測其 DNSSEC 簽名鏈是否驗證通過。
診斷 DNSSEC 的信任鏈
本工具把某個網域的 DNSKEY 記錄投向數個公開解析器，報出 DNSSEC 的簽章是否一路驗證得通。它揪得出這樣一種狀況：本以為已啟用 DNSSEC，鏈條卻在半途斷了。
DNSSEC 所護的是「答案未曾被竄改」，而非「內容是祕密」。 往來的東西一如既往人人可見，所擔保的唯有真偽。而最常見的疏漏，是忘了把 DS 記錄登記到父區域。 您縱在自家區域放好金鑰並簽了名，若不經註冊商把 DS 登記到父區域（譬如 .com），信任鏈便在此處斷開，什麼也驗證不了。 反過來，金鑰輪替若出了岔子而留下不一致，在凡是作驗證的解析器那裡，整個網域便都解析不出來了。 故而半途而廢的狀態，反倒可能比從未啟用更危險。
使用方法
-
輸入網域
只給網域即可，形如
example.com。 - 閱讀驗證的結果 它判定簽章之鏈是否一路接到了父區域。
- 確認有無 DS 記錄 此處一旦缺失，您放下再多金鑰也驗證不了。
- 比對數個解析器的答案 若有出入，便可疑心是快取或是設定。
用好本工具的小技巧
- AD（Authenticated Data，已驗證資料）標誌只有在您查詢的 DNS 解析器自身執行了 DNSSEC 驗證時才會被設定。不支援 DNSSEC 的解析器無法給出有意義的判定結果。
- "DNSSEC 未啟用"並非錯誤——目前大多數域名仍未使用 DNSSEC，這不會直接影響搜尋排名或郵件送達率。
- 若判定為"驗證失敗"，請先確認在註冊商後臺登記的父區域 DS 記錄的金鑰標籤（Key Tag）與摘要是否與當前 DNSKEY 一致。
- DNSSEC 簽名（RRSIG）具有有效期。請同時確認區域管理軟體的自動重新簽名是否已停止執行。
- 剛啟用 DNSSEC 後，在 DS 記錄傳播到父區域完成之前，可能會暫時顯示為"驗證失敗"。
這些情境會用到
啟用 DNSSEC 之後的確認
在控制台上勾一下，往往並未把事情辦完。
把金鑰輪替看到底
可在換鑰的前後確認驗證不曾斷掉。
查究名稱為何解析不出
DNSSEC 的不一致，會讓網域在部分使用者眼裡像是憑空消失了。
查一查往來對象的網域
由此可知對方把自家的措施做到了哪一步。
DNSSEC 的術語
- DNSKEY
- 存放某區域公鑰的記錄，用於驗證簽章。
- DS 記錄
- 把子區域金鑰的指紋登記到父區域的記錄。 少了它，信任鏈便斷。
- RRSIG
- 附在每條記錄上的簽章本身。它帶有有效期，須按期更新。
- 信任鏈
- 簽章自根經父及子一路相扣的結構。任何一處斷開，驗證便無從談起。
- 金鑰輪替
- 以新鑰替換舊鑰的作業。步驟一錯，整個網域便解析不出來。
- 作驗證的解析器
- 當真去核驗 DNSSEC 簽章的解析器。一旦有不一致，它便什麼答案也不回傳。
常見問題
閒話 ― 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）本身已受到保護。