如何查看域是否使用DNSSEC

Question

我正試圖找到一種方法來查看域是否正在使用DNSSEC。 從這個線程： 我如何檢查域是否使用DNSSEC？ 我了解到了

dig +dnssec <domain> dnskey

可以揭示很多東西。 但經過一些實驗，我意識到它只顯示名稱服務器是否設置了DNSSEC。 我需要弄清楚的是，該域名是否標記為在NIC上使用DNSSEC。

我嘗試查看python的dnssec 實現 ，但它們似乎都在查看名稱服務器而不是原始的NICzone。

在挖掘之后，我注意到一些NICS（例如sidnl.nl）在WHOIS數據中記錄了它，但由於這幾乎不可靠（並非所有NICS都這樣做），我正在尋找更好的方法。

激光器不必是編程/使用代碼片段，但如果是，我會很高興，如果它是python / C＃/ java或其他一些易於理解的語言。

Answer 1

使用verisign的dnssec調試器： http ： //dnssec-debugger.verisignlabs.com/ 。

Answer 2

TL; DR

它很難診斷，不要自己動手，不要認為單個DNS查詢或者whois輸出能夠真正完全回答這個問題，它就更復雜了。

如果您信任它們，以下工具非常有用，可以簡化生活：

• https://dnssec-debugger.verisignlabs.com/很久以前在另一個答案中報道過
• https://dnsviz.net/基於特定查詢的DNS層次結構的非常好的顯示
• https://zonemaster.net/通用區域檢查程序

至少最后兩個也是您可以在本地下載和安裝以執行相同測試的軟件; 你也有dig ，或它的DNSSEC的繼承者是delv （見下文）， unbound提供drill實用程序的等效功能集。

“我需要弄清楚該域名是否標記為在NIC上使用DNSSEC。”

根據您的問題，這不是相關的或措辭不佳。

在whois輸出中寫的內容沒有用：它確實有時顯示DNSSEC: Yes或某些等價物，但Whois和DNS是兩個獨立的東西，如果你想處理DNS問題，你應該留在DNS土地，所以讓我們暫時忽略了whois。

回到dig +dnssec <domain> dnskey ，這是一個很好的方向，但從兩個大問題開始：

1. 您正在使用dig而沒有使用@ what nameserver指定您的查詢。 因此，您將獲得的回復將來自您可能會或可能不會控制的某個遞歸名稱服務器，可能會或可能不會欺騙您，並且您的路徑可能控制也可能不控制，在后一種情況下，答案可以在中轉; 要解決這一點，您實際上需要查詢域的權威名稱服務器之一，因此您首先需要找到它們; 這可能會變得復雜，因為你需要使用DNSSEC來確保你在所有查詢中得到有效的回復，同時DNSSEC中的任何錯誤都會給你SERVFAIL作為回復
2. 第二個大問題是，基本上您的查詢將顯示是否使用區域數據發布了一些DNSKEY，以及任何簽名但是：
   1. 它不能確保你提出的遞歸解析器已經驗證了任何東西（因此簽名可能都是偽造的）因為要做到這一點你需要+nocdflag而不是+dnssec （那個觸發顯示簽名，也就是RRSIG記錄）; +cdflag是禁用驗證的標志，所以你需要反轉它（因為解析器可以默認驗證，在這種情況下，將dig與dig +cd結果進行比較可以幫助解釋觀察到的錯誤是否與DNSSEC或不是（所有DNSSEC故障目前只是返回SERVFAIL ，這是一個通用的錯誤代碼，可能發生在與DNSSEC無關的無數其他情況; 正在進行的工作正在向DNS交換機添加更豐富的錯誤報告 ）
   2. 最后，即使所有內容都在那里點擊，最終域名已發布DNSKEY事實並不意味着它已啟用DNSSEC，因為要使其工作，它必須具有與該特定密鑰匹配但在父級上發布的DS記錄權威的名稱服務器，即注冊表的名稱服務器; 沒有這樣的記錄（並且它的簽名與密鑰本身一起發布，並且它本身對一些其他DS記錄更高，並且DNSKEY到DNS根目錄），即使發布了DNSKEY ，它也永遠不會被信任，因此域名沒有真正的DNSSEC。

像解析器一樣進行驗證

因此，要從頭開始實現並正確地執行所有操作，您需要做的是執行遞歸驗證名稱服務器將執行的操作：它將DNSSEC驗證您的域（或失敗）。 這是證明域已啟用DNSSEC的唯一測試，因為這意味着它已發布所需內容，父級也發布了所需內容，等等。

當然，手動重做所有這些都是一個壞主意，因為DNSSEC驗證很復雜。

你將要做的是，安裝一個本地驗證解析器， getdns unbound或使用像getdns這樣的庫，它將為你處理所有這些，或者你使用遠程遞歸名稱服務器為你驗證DNSSEC 當且僅當你完全信任所討論的名稱服務器以及您和它之間的所有網絡路徑（或者您現在使用DoH或DoT將DNS交換包裝到TLS流中）。 因為如果您使用的是您無法信任的遠程服務器，它可能會欺騙您關於DNSSEC驗證結果，如果您信任nameserer而不信任網絡路徑，那么活動攻擊者可以在它們從遞歸名稱服務器找到您之前修改結果。

請注意，最新版本的bind提供了delv ，它是專門針對DNSSEC相關故障排除進行dig的繼承者： https ： delv

BIND 9.10包含一個新的調試工具，它是挖掘的繼承者。 所以，當然，我們必須將它命名為delv。 它非常像挖掘，但它更好地理解DNSSEC。

delv +vtrace清楚地顯示了每一步的所有驗證和DS / DNSKEY記錄檢索。

DNSSEC以whois顯示

最后回到這一點，並討論它的真正含義。

如果一個注冊表顯示某個whois中的一個點輸出了某個域“已簽名”的指示，那么該DNSSEC處於活動狀態，這意味着只有一個非常狹窄的事情：在過去的某個時刻（可能很久以前），注冊商代表其客戶贊助此域名，發送加密材料（相當於DNSKEY或DS記錄，具體取決於注冊機構的政策;如果是DS則注冊商希望注冊管理機構在注冊機構權威名稱服務器中將其發布;如果這是一個DNSKEY ，注冊表將計算自己要發布的DS值;有時注冊商必須發送兩者，以便注冊表可以仔細檢查DS是否從DNSKEY正確計算到注冊表，通常是通過EPP一段時間后（幾小時/幾天） DS記錄出現在注冊表權威的名稱服務器中。

但：

1. 現在很少有注冊管理機構在更新時進行檢查，因此當子區域絕對沒有發布DNSKEY時，注冊服務商可以發送添加DS記錄的請求。 這將導致DNSSEC: yes在whois輸出中為DNSSEC: yes ，但域將因任何解析名稱服務器而失敗
2. 即使在此更新發生時所有內容都已正確設置，名稱服務器也可能已更改（更改已簽名的域的名稱服務器是一個難題，特別是如果舊的提供程序不合作，並且沒有良好的通用萬無一失的解決方案，除了停止簽署域一段時間，然后在名稱服務器更改后重新簽名）
3. 即使不更改名稱服務器本身，也可以通過錯誤或自願更改區域的內容，從而在DS仍然發布時丟棄DNSKEY ，從而產生與第一點相同的效果。 這種情況比預期/希望的更頻繁。

請注意，某些注冊管理機構對其發布的所有域執行異步DNSSEC檢查，並警告注冊服務商和/或最終客戶端，如果他們的域名不再正確設置。