我的啟用 DNSSEC 的域如何仍然提供少量 NXDOMAIN 響應程式碼？
大約一周前，我在我的主域上啟用了 DNSSEC。它不是主要網站或任何東西——只是我用於電子郵件等的個人域名（TLD：
com；DNSSEC 算法 13；權威 DNS 提供商：Cloudflare）。在過去 24 小時內，該域已收到 15,605 個查詢。作為回應，它已經拋出了15,601個
NOERROR響應程式碼，總共4個NXDOMAIN響應程式碼。NXDOMAIN 響應如何仍然可能？是什麼產生了它們？
就個人而言，無論我嘗試什麼查詢，我都無法觸發，我的理解是 DNSSEC 至少在理論上應該完全消除此響應程式碼。
我不正確嗎？
TL;博士
對於 Cloudflare 託管域， No
NXDOMAIN是其特定 DNSSEC 實施（使用所謂的“謊言”）的結果，而不是 DNSSEC 協議本身的設計；因此觀察結果與其他提供 DNSSEC 的提供商不同。最初的問題
NXDOMAIN 響應如何仍然可能？
為什麼他們不可能？DNSSEC 與否，如果您查詢一個不存在的名稱，您會得到
NXDOMAIN回复。我的理解是，至少在理論上，DNSSEC 應該完全消除此響應程式碼
為什麼？你從哪裡得到這種感覺？
啟用 DNSSEC 的域的實時範例
icann.org現在是否啟用了 DNSSEC。如果我查詢其下不存在的名稱，我會得到NXDOMAIN：$ dig NS icann.org +short b.icann-servers.net. c.icann-servers.net. ns.icann.org. a.icann-servers.net. $ dig @a.icann-servers.net does-not-exist-foobar.icann.org ; <<>> DiG 9.18.4 <<>> @a.icann-servers.net does-not-exist-foobar.icann.org ; (1 server found) ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38891 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 98228e9e0c5ef4e6 ;; QUESTION SECTION: ;does-not-exist-foobar.icann.org. IN A ;; QUERY SIZE: 72 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38891 ^^^^^^^^從某種意義上說，DNSSEC 是 DNS 的擴展，對於非驗證解析器，即使域啟用了 DNSSEC，答案也沒有什麼不同。所以所有返回碼都以相同的方式工作。
NSEC/NSEC3/RRSIG說明
它確實發生了什麼變化，您可以看到是否添加
+dnssec（dig這並不意味著“啟動 DNSSEC”，而是意味著“顯示 DNSSEC 相關記錄 - 這些是RRSIG,NSEC和NSEC3- 因為它們通常不顯示），是該AUTHORITY部分以防萬一用或記錄NXDOMAIN進一步解釋：NSEC``NSEC3;; AUTHORITY SECTION: icann.org. 1h IN SOA sns.dns.icann.org. noc.dns.icann.org. ( 2022070670 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 1209600 ; expire (2 weeks) 3600 ; minimum (1 hour) ) j93jujiqg7ge3616mub4r5bei85poet9.icann.org. 1h IN NSEC3 1 0 5 9714B5ACB8F7A193 ( J9HKD4G746GMUTGGUV6AM37GSJAD6NRR A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM ) tdr1at6eafsrigdrlj6atpb2dge2aof0.icann.org. 1h IN NSEC3 1 0 5 9714B5ACB8F7A193 ( TE4FB4PVMU1GQNPG9P01ID48U1BTN2G4 A RRSIG ) lsrp57e1pe333jadkpdgh3v1i8vs80rd.icann.org. 1h IN NSEC3 1 0 5 9714B5ACB8F7A193 ( LT4I8S7OTQ7ACOSF73M7LHCIC7C1J17I A RRSIG ) icann.org. 1h IN RRSIG SOA 7 2 3600 ( 20220804192816 20220714153322 3425 icann.org. NMcD1TeozFyCRDlmqFMoM/V/VmWQUmRNIH0/igPzdj2S hemnQHeXDOudBxsUgE/DpSV4KHsgqLQKdgbQruqCO7Dt iLK1bCLBZs38LdOadyJs3jWjjuJ9+mEnLXTsqMeeMllw YFL6pPyo1TfChZm05KJ+DJNw0SHJw3MWBRtV4iI= ) j93jujiqg7ge3616mub4r5bei85poet9.icann.org. 1h IN RRSIG NSEC3 7 3 3600 ( 20220724054620 20220703065347 58935 icann.org. gmo0VP8k9Li9lutMA3uTrMfABMmFBN23GonYo72Twk9l wGYqFvlU/naN0KKtEd3g+zOiYB0Jb1J1270Dveew/vYa hTmeMYrwUbEt9gZYCvi74zm6Ss0cQ8uxJ5bZw70nZ7oU LAtWYVGJMgupfjtne6021AJoLNB1CaMhFwo+TPo= ) tdr1at6eafsrigdrlj6atpb2dge2aof0.icann.org. 1h IN RRSIG NSEC3 7 3 3600 ( 20220724101659 20220703045347 58935 icann.org. hGsUeE4di9yFuDMq8ly1YQEs1OvOFAHVctOQrs6Poixl STqcErjC20V2CI0YApX6SbiI8AP/dqMjBm3fZh91mtDf aSrZypfScBEO/KVdlqbW9G+y8VR65ryjTAA7TZIzqN+z 7YyTAESWb8E7T4NCtQPPwYpjl/S9krbEGSiKfaw= ) lsrp57e1pe333jadkpdgh3v1i8vs80rd.icann.org. 1h IN RRSIG NSEC3 7 3 3600 ( 20220724151521 20220703105347 58935 icann.org. P9qwkFoGkCd+m3aDQkzF/g7SJfn/byt6d4zugLzRKuH1 rLmYZdlJNOC+fI1saCZySarsP9KavFSBzw6S9GMLobQJ hTVpu1ZUkEP9BMOZo28eeRLrGvAbrVb7aB9CWl9TgUMc 2+s4nG87HTvD2TCJHmyPC1mIbBLYmJoa7iGLGiI= )
NSEC3更複雜（不太人性化），因為它使用域名的雜湊值。但總而言之，以上所有含義是我請求的名稱不存在，因為它位於兩個存在的名稱之間（但不能立即看到，因為散列），並且不存在萬用字元（這就是為什麼你有三個NSEC3記錄）。記錄對這些RRSIG記錄進行簽名NSEC3，因此上述所有內容都允許解析名稱伺服器確實仔細檢查NXDOMAIN是否合法，而不是由某些路徑上的攻擊者引入，因為所有NSEC3和RRSIG記錄都符合預期。NSEC案例的更簡單範例
讓我們使用啟用的域 DNSSEC
NSEC而不是NSEC3：根本身:-)如果我
dig @g.root-servers.net foobar. +dnssec現在這樣做NXDOMAIN，我會再次出於與上述相同的原因，並且 TLD 不存在（還沒有？）但讓我們看看結果，尤其是一條
NSEC記錄：foo. 1d IN NSEC food. NS DS RRSIG NSEC這是來自名稱伺服器的肯定簽名（有相應的
RRSIG記錄）斷言，告訴我foobar區域中不存在，因為兩者都foo存在food，但兩者之間沒有。並且每個 DNSSEC 排序規則foobar將在foo和之間進行排序food，因此上述證明foobar不存在。順便說一句，它證明了許多其他名稱不存在，並且一些解析器可以記憶體它NSEC並在不請求任何內容的情況下得出答案。為什麼？因為如果我知道之間不存在任何東西
foo，food我立即知道fooa不存在，也不fooa42或foobie或fooccc或類似……返回 CloudFlare 具體案例
CloudFlare 實現了“DNSSEC 白色謊言”和“黑色謊言”，請參閱https://www.cloudflare.com/dns/dnssec/dnssec-complexities-and-considerations/和https://blog.cloudflare.com/black-lies /由於他們自己的各種原因（部分是因為他們進行動態簽名生成，他們
RRSIG在請求到來的那一刻生成記錄，而不是提前生成記錄；這是一種折衷方案，兩種情況都有優點和缺點）。這意味著什麼？他們偽造所有名稱的存在，因此幾乎沒有
NXDOMAIN.讓我們看一個例子：
$ dig dwewgewfgewfee-32cewcewcew-2284.cloudflare.com @ns3.cloudflare.com. +dnssec ; <<>> DiG 9.18.4 <<>> dwewgewfgewfee-32cewcewcew-2284.cloudflare.com @ns3.cloudflare.com. +dnssec ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9469 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: fd8d36048320c848 ;; QUESTION SECTION: ;dwewgewfgewfee-32cewcewcew-2284.cloudflare.com. IN A ;; QUERY SIZE: 87 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9469 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;dwewgewfgewfee-32cewcewcew-2284.cloudflare.com. IN A ;; AUTHORITY SECTION: cloudflare.com. 5m IN SOA ns3.cloudflare.com. dns.cloudflare.com. ( 2282614227 ; serial 10000 ; refresh (2 hours 46 minutes 40 seconds) 2400 ; retry (40 minutes) 604800 ; expire (1 week) 300 ; minimum (5 minutes) ) dwewgewfgewfee-32cewcewcew-2284.cloudflare.com. 5m IN NSEC \000.dwewgewfgewfee-32cewcewcew-2284.cloudflare.com. RRSIG NSEC（我刪除了
RRSIG記錄）。那麼這說明了什麼？第一：
NOERROR而不是NXDOMAIN相反，所以解析器告訴我我查詢的名稱存在（但可能不是我問的類型，A這是預設dig類型，這是有效的並且被稱為NODATA這意味著NOERROR但也沒有內容，沒有ANSWER部分，如它在名稱存在時發生，但不是那種類型）。該
AUTHORITY部分，特別是該NSEC記錄告訴我，兩者之間沒有名字dwewgewfgewfee-32cewcewcew-2284.cloudflare.com.（實際上是我要求的名字，所以不是前一個，只是我的名字），\000.dwewgewfgewfee-32cewcewcew-2284.cloudflare.com.這可能看起來像一個奇怪的名字，但 1）是完全有效的（它是不是一個有效的主機名，因為\000意味著字節值 0 必須被編碼為\000用於 DNS 操作，但仍然是一個有效的域名，因為 DNS 規範中的域名可以是任意字節）和 2）是，使用 DNSSEC 排序算法，在我的名字之後命名（所以基本上這兩個名字的範圍不包括中間的任何其他名字）。
RRSIG NSEC記錄末尾的部分意味著NSEC名稱A上沒有記錄類型，但有記錄類型RRSIGandNSEC，這是有道理的，因為我正在查看NSEC該名稱的記錄，當然，就像我們在 DNSSEC 領域一樣有一個RRSIG.所以這被稱為“謊言”，因為域名伺服器正在回复你：這個名字存在，但不是這個記錄類型。並且無論您要求哪種記錄類型（
NSEC和除外RRSIG），名稱伺服器都會告訴您：“此記錄類型不存在此名稱”。最後，如果任何記錄類型（除了NSECandRRSIG）都不存在它，它（名稱）就好像它（名稱）根本不存在，但它只是以不同的方式呈現，原因將在下面快速詳述。我建議閱讀第二個連結，但它解釋的要點是（我跳過了關於
NSEC/NSEC3和萬用字元記錄的全部要點，以及關於“最近遭遇”等的所有細節，但如果深入了解NSEC這些內容，這些都很重要） ：NSEC3 是一個“接近但沒有雪茄”的解決方案。雖然它確實使區域行走變得更加困難，但它並沒有讓它變得不可能。
（這就是為什麼他們不使用
NSEC3和保留NSEC但仍然需要另一種解決方案來避免行走區域並因此列舉所有名稱）否定答案有兩個問題：
首先是權威伺服器需要返回>previous和next name。正如您將看到的，這對 CloudFlare 來說在計算上是昂貴的，而且正如您已經看到的，它可能會洩露有關區域的資訊。
第二個是否定答案需要兩個 NSEC 記錄和 >它們的兩個後續簽名（或三個 NSEC3 記錄和三個 >NSEC3 簽名）來驗證一個名稱的不存在。>這意味著答案比他們需要的要大。
所以上面的那部分是為什麼想要避免使用
NXDOMAIN和“模擬”成功（NOERROR）但同時對任何查詢（請求的任何類型的名稱+類型）做出否定響應的基本解釋。另一點，同樣非常具體到 CloudFlare，是在他們的情況下很難計算“下一個”名稱（因為
NSEC實際上給出了兩個名稱的“範圍”，作為現有兩個事物之間的連結），所以而不是使用儲存中存在的真實下一個名稱，他們根據 DNSSEC 算法計算最小的“下一個”，因此上面帶有\000.前綴的奇怪名稱，顯然也不存在的名稱，所以如果你查詢它你將再次得到相同類型的回复，但這次是在正確或事實上的NSEC記錄列表中，等等……\001.``\000.\000.再向下：
對於 NXDOMAIN，我們總是返回 \000.（缺少的名稱）作為下一個名稱，並且因為我們直接在缺少的名稱上返回 NSEC，所以我們不必為萬用字元返回額外的 NSEC。這樣我們只需要返回 SOA、SOA RRSIG、NSEC 和 NSEC RRSIG，我們不需要搜尋數據庫或預先計算動態答案。
只需較小的回复即可達到目標。這在 DNS 領域很重要，因為碎片化存在各種問題。從他們的例子來看，他們從 1096 字節到只有 357 字節的謊言，減少了近 2/3，相當了不起！
以上所有內容在未來可能會成為“標準”，對於那些想要做同樣事情的人來說，因為他們編寫了一份可能成為 IETF RFC 的文件：https ://datatracker.ietf.org/doc/html/草稿-valsorda-dnsop-黑色謊言
請注意它有後果：
NXDOMAIN是一個重要的信號：各種其他的東西都建立在此之上，請參閱 RFC 8020“NXDOMAIN：下面真的沒有什麼”和 RFC 8198“積極使用 DNSSEC-Validated Cache”，因此不再擁有此信號可能會產生副作用（並且更改其他遞歸解析器以嘗試找出權威方是否在使用惡意謊言然後考慮它們並不是一個好主意，這將是脆弱的；這一點在上面的草案中得到了確切的討論）- 它還會影響 ENT 或“空非終端”，其中名稱必須存在於 DNS 樹中，不是因為它附加了任何類型，而是因為它下面有名稱；有關該主題的更多詳細資訊，請參見https://www.ietf.org/archive/id/draft-huque-dnsop-blacklies-ent-01.html
- 沒有一個實現是沒有錯誤的，DNSSEC 很複雜，圍繞 DNSSEC 的技巧更複雜；現在我不確定了，也找不到參考資料，但我認為一開始有一個錯誤，並且返回的類型（在位
NSEC圖中）沒有正確計算，因此破壞了一些東西。如果我確實找到了我認為我所看到的內容，我會嘗試更新此內容，但我可能會產生妄想（很容易與 DNSSEC 相處……）；事實上，我認為這與觀察結果有關，即他們所有的初始範例確實在NSEC上一節中放置了更多類型，現在他們只放置了RRSIGandNSEC。有關點陣圖中錯誤及其後果的實時範例，請參見https://indico.dns-oarc.net/event/40/contributions/899/attachments/862/1563/nsec-bitmaps.pdfNSEC啊，不，事實上我沒記錯，這個
NSEC點陣圖中的一個錯誤正是最近 Slack 中斷的根源:-)，但這不是 Cloudflare 故障，而是 AWS Route53 的問題所在。有關這些詳細資訊，請參見https://www.potaroo.net/ispcol/2021-12/oarc36.pdf，但簡而言之：現在你可以用 NSEC 記錄撒謊，
$$ .. $$ 但是伺服器不應該做的是在 NSEC 記錄中返回一個空的位向量。因為一些解析器，包括Google的公共 DNS 服務，將一個空的 NSEC 位向量解釋為聲稱該域名根本沒有資源記錄。這不是 Google DNS 錯誤。這是對 DNSSEC 規範的完全合法解釋。Slack 遇到的問題是，當使用萬用字元條目形成響應並且未為萬用字元資源定義查詢類型時，Route 53 伺服器返回的 NSEC 響應帶有幾乎為空的 RR 類型位向量。這是 Route 53 實現中的一個錯誤。
所以，簡而言之，撒謊有時確實會產生不良後果 :-) （和/或：DNSSEC 很複雜，DNS 中的萬用字元也會造成各種複雜情況；事實上，DNSSEC + 萬用字元 + CNAME 記錄就像 3 個確定的跡象莫名其妙的天啟……）。
這只是做事的一種方式，其後果（幾乎沒有 NXDOMAIN 響應）絕對不是協議 (DNSSEC) 的結果，而只是它們的實施。所以不要認為這是理所當然的，它與其他提供商會有所不同。但是，對於作為區域所有者或區域使用者的您來說，它真的有什麼改變嗎？沒那麼多。你為什麼這麼擔心
NXDOMAIN反應:-)？PS：