Col*_*lin 13 domain-name-system dnssec dig
大约一周前，我在我的主域上启用了 DNSSEC。它不是一个主要网站或任何东西——只是我用于电子邮件等的个人域名（TLD：com；DNSSEC 算法 13；权威 DNS 提供商：Cloudflare）。
在过去 24 小时内，该域已收到 15,605 个查询。作为回应，它发出了 15,601 个NOERROR响应代码，总共 4 个NXDOMAIN响应代码。
NXDOMAIN 响应如何仍然可能？什么可能产生它们？
就我个人而言，无论我尝试什么查询都无法触发查询，并且我的理解是 DNSSEC 至少在理论上应该完全消除此响应代码。
我错了吗？
Pat*_*zek 26
长话短说
\nCloudflare 托管域缺乏NXDOMAIN响应是其特定 DNSSEC 实施（使用所谓的“黑色谎言”）的结果，而不是 DNSSEC 协议本身的设计；因此，观察结果将与其他执行 DNSSEC 的提供商有所不同。
\n\nNXDOMAIN 响应如何仍然可能？
\n
为什么它们不可能呢？无论是否有 DNSSEC，如果您查询不存在的名称，您都会得到NXDOMAIN回复。
\n\n我的理解是 DNSSEC 至少在理论上应该完全消除这个响应代码
\n
为什么？你从哪里得到这种感觉？
\nicann.org现在 DNSSEC 已启用。如果我查询其下不存在的名称，我会得到NXDOMAIN：
$ dig NS icann.org +short\nb.icann-servers.net.\nc.icann-servers.net.\nns.icann.org.\na.icann-servers.net.\n\n$ dig @a.icann-servers.net does-not-exist-foobar.icann.org\n\n; <<>> DiG 9.18.4 <<>> @a.icann-servers.net does-not-exist-foobar.icann.org\n; (1 server found)\n;; global options: +cmd\n;; Sending:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38891\n;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 4096\n; COOKIE: 98228e9e0c5ef4e6\n;; QUESTION SECTION:\n;does-not-exist-foobar.icann.org. IN A\n\n;; QUERY SIZE: 72\n\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38891\n ^^^^^^^^\nDNSSEC 是 DNS 的扩展，对于非验证解析器来说，即使域启用了 DNSSEC，答案也没有不同。因此所有返回码的工作方式都是相同的。
\n它所做的改变，你可以看到，如果添加+dnssec到dig（这并不意味着“激活 DNSSEC”，而是意味着“显示 DNSSEC 相关记录 - 这些是RRSIG，NSEC并且NSEC3- 因为它们通常不显示），是以防AUTHORITY万一的部分的NXDOMAIN进一步解释NSEC或NSEC3记录：
;; AUTHORITY SECTION:\nicann.org. 1h IN SOA sns.dns.icann.org. noc.dns.icann.org. (\n 2022070670 ; serial\n 10800 ; refresh (3 hours)\n 3600 ; retry (1 hour)\n 1209600 ; expire (2 weeks)\n 3600 ; minimum (1 hour)\n )\nj93jujiqg7ge3616mub4r5bei85poet9.icann.org. 1h IN NSEC3 1 0 5 9714B5ACB8F7A193 (\n J9HKD4G746GMUTGGUV6AM37GSJAD6NRR\n A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM )\ntdr1at6eafsrigdrlj6atpb2dge2aof0.icann.org. 1h IN NSEC3 1 0 5 9714B5ACB8F7A193 (\n TE4FB4PVMU1GQNPG9P01ID48U1BTN2G4\n A RRSIG )\nlsrp57e1pe333jadkpdgh3v1i8vs80rd.icann.org. 1h IN NSEC3 1 0 5 9714B5ACB8F7A193 (\n LT4I8S7OTQ7ACOSF73M7LHCIC7C1J17I\n A RRSIG )\nicann.org. 1h IN RRSIG SOA 7 2 3600 (\n 20220804192816 20220714153322 3425 icann.org.\n NMcD1TeozFyCRDlmqFMoM/V/VmWQUmRNIH0/igPzdj2S\n hemnQHeXDOudBxsUgE/DpSV4KHsgqLQKdgbQruqCO7Dt\n iLK1bCLBZs38LdOadyJs3jWjjuJ9+mEnLXTsqMeeMllw\n YFL6pPyo1TfChZm05KJ+DJNw0SHJw3MWBRtV4iI= )\nj93jujiqg7ge3616mub4r5bei85poet9.icann.org. 1h IN RRSIG NSEC3 7 3 3600 (\n 20220724054620 20220703065347 58935 icann.org.\n gmo0VP8k9Li9lutMA3uTrMfABMmFBN23GonYo72Twk9l\n wGYqFvlU/naN0KKtEd3g+zOiYB0Jb1J1270Dveew/vYa\n hTmeMYrwUbEt9gZYCvi74zm6Ss0cQ8uxJ5bZw70nZ7oU\n LAtWYVGJMgupfjtne6021AJoLNB1CaMhFwo+TPo= )\ntdr1at6eafsrigdrlj6atpb2dge2aof0.icann.org. 1h IN RRSIG NSEC3 7 3 3600 (\n 20220724101659 20220703045347 58935 icann.org.\n hGsUeE4di9yFuDMq8ly1YQEs1OvOFAHVctOQrs6Poixl\n STqcErjC20V2CI0YApX6SbiI8AP/dqMjBm3fZh91mtDf\n aSrZypfScBEO/KVdlqbW9G+y8VR65ryjTAA7TZIzqN+z\n 7YyTAESWb8E7T4NCtQPPwYpjl/S9krbEGSiKfaw= )\nlsrp57e1pe333jadkpdgh3v1i8vs80rd.icann.org. 1h IN RRSIG NSEC3 7 3 3600 (\n 20220724151521 20220703105347 58935 icann.org.\n P9qwkFoGkCd+m3aDQkzF/g7SJfn/byt6d4zugLzRKuH1\n rLmYZdlJNOC+fI1saCZySarsP9KavFSBzw6S9GMLobQJ\n hTVpu1ZUkEP9BMOZo28eeRLrGvAbrVb7aB9CWl9TgUMc\n 2+s4nG87HTvD2TCJHmyPC1mIbBLYmJoa7iGLGiI= )\nNSEC3更复杂（不太人性化），因为它使用域名的哈希值。但总的来说，以上所有内容意味着我请求的名称不存在，因为它位于两个存在的名称之间（但不能立即看到，因为已散列），并且不存在通配符（这就是为什么你有三个NSEC3记录）。记录RRSIG对这些记录进行签名NSEC3，因此上述所有内容都允许解析名称服务器确实仔细检查该记录NXDOMAIN是否合法，并且不是由某些途中攻击者引入的，因为所有NSEC3和RRSIG记录都符合预期。
让我们使用启用了 DNSSEC 的域NSEC来代替NSEC3：根本身:-)
如果我dig @g.root-servers.net foobar. +dnssec现在这样做，我会NXDOMAIN再次得到 , 原因与上述相同，而且 TLD 还不存在（还？）
但让我们看看结果，尤其是一条NSEC记录：
foo. 1d IN NSEC food. NS DS RRSIG NSEC\nRRSIG这是来自名称服务器的肯定签名（有相应的记录）断言，告诉我foobar区域中不存在该断言，因为 和foo都food存在，但两者之间没有任何关系。根据 DNSSEC 排序规则，将在和之间foobar进行排序，因此上述证明不存在。顺便说一句，它证明许多其他名称不存在，并且某些解析器可以缓存此名称foofoodfoobarNSEC并得出答案，而无需请求任何内容。
为什么？因为如果我知道之间不存在任何东西foo，food我立即知道fooa不存在，也不存在fooa42或foobie或fooccc类似\xe2\x80\xa6
CloudFlare 实现了“DNSSEC 善意谎言”和“黑色谎言”，请参阅https://www.cloudflare.com/dns/dnssec/dnssec-complexities-and-considerations/和https://blog.cloudflare.com/black-lies /出于他们自己的各种原因（部分是因为他们进行动态签名生成，他们RRSIG在请求到来时生成记录，而不是提前；这是一种折衷，两种情况都有优点和缺点）。
这意味着什么？他们伪造所有名称的存在，因此几乎从来没有NXDOMAIN.
让我们看一个例子：
\n$ dig dwewgewfgewfee-32cewcewcew-2284.cloudflare.com @ns3.cloudflare.com. +dnssec\n\n; <<>> DiG 9.18.4 <<>> dwewgewfgewfee-32cewcewcew-2284.cloudflare.com @ns3.cloudflare.com. +dnssec\n;; global options: +cmd\n;; Sending:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9469\n;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags: do; udp: 4096\n; COOKIE: fd8d36048320c848\n;; QUESTION SECTION:\n;dwewgewfgewfee-32cewcewcew-2284.cloudflare.com. IN A\n\n;; QUERY SIZE: 87\n\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9469\n;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1\n;; WARNING: recursion requested but not available\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags: do; udp: 1232\n;; QUESTION SECTION:\n;dwewgewfgewfee-32cewcewcew-2284.cloudflare.com. IN A\n\n;; AUTHORITY SECTION:\ncloudflare.com. 5m IN SOA ns3.cloudflare.com. dns.cloudflare.com. (\n 2282614227 ; serial\n 10000 ; refresh (2 hours 46 minutes 40 seconds)\n 2400 ; retry (40 minutes)\n 604800 ; expire (1 week)\n 300 ; minimum (5 minutes)\n )\ndwewgewfgewfee-32cewcewcew-2284.cloudflare.com. 5m IN NSEC \\000.dwewgewfgewfee-32cewcewcew-2284.cloudflare.com. RRSIG NSEC\n（我删除了RRSIG记录）。
那么这说明了什么？首先：NOERROR而不是NXDOMAIN相反，所以解析器告诉我我查询的名称存在（但可能不是我要求的类型，A这是默认dig类型，这是有效的并且被称为NODATA这意味着NOERROR但没有内容，没有ANSWER部分，如当名称存在但类型不存在时会发生这种情况）。
该AUTHORITY部分，特别是该NSEC记录告诉我，之间没有名称dwewgewfgewfee-32cewcewcew-2284.cloudflare.com.（实际上是我要求的名称，所以不是前一个，只是我的），并且\\000.dwewgewfgewfee-32cewcewcew-2284.cloudflare.com.这可能看起来像一个奇怪的名称，但 1）是完全有效的（它是不是有效的主机名，因为\\000意味着字节值 0 必须按照\\000DNS 操作进行编码，但仍然是有效的域名，因为 DNS 规范中的域名可以是任何任意字节）并且 2) 是，使用 DNSSEC 排序算法，在我的名字“后面”命名（所以基本上两个名字的范围不包括中间的任何其他名字）。
RRSIG NSEC记录末尾的部分意味着名称上NSEC没有记录类型，但有记录类型和，这是有道理的，因为我正在查看该名称的记录，当然，正如我们在 DNSSEC 土地上一样有一个。ARRSIGNSECNSECRRSIG
所以这被称为“谎言”，因为名称服务器正在回复您：该名称存在，但不存在该记录类型。并且无论您请求哪种记录类型（除了NSEC和RRSIG），名称服务器都会告诉您：“此记录类型不存在此名称”。\n最后，如果任何记录类型（除了NSEC和RRSIG）都不存在该名称，则它会告诉您：实际上就好像它（名称）根本不存在，但它只是以不同的方式呈现，原因如下。
我建议阅读第二个链接，但它解释的要点是（我跳过了有关NSEC/NSEC3和通配符记录的全部要点，以及有关“最近的相遇”等的所有详细信息，但如果深入了解这些内容，这些内容很重要NSEC） :
\n\nNSEC3 是 \xe2\x80\x9cclose 但没有 cigar\xe2\x80\x9d 问题的解决方案。虽然它确实使区域行走变得更加困难，但这并不意味着它变得不可能。
\n
（这就是为什么他们不使用NSEC3和保留NSEC，但仍然需要另一个解决方案来避免行走该区域并因此枚举所有名称）
\n\n否定答案有两个问题：
\n首先是权威服务器需要返回>前一个和下一个名称。正如您\xe2\x80\x99 将看到的，这对于 CloudFlare 来说计算成本很高，而且正如您\xe2\x80\x99 已经看到的，它可能会泄漏有关区域的信息。
\n第二个是否定答案需要两个 NSEC 记录和它们的两个后续签名（或三个 NSEC3 记录和三个 >NSEC3 签名）来验证一个名称不存在。>这意味着答案比他们需要的要大。
\n
所以上面的部分是为什么想要避免使用NXDOMAIN和成功“模拟”它的基本解释（NOERROR）但同时对任何查询（任何请求的类型的名称+类型）做出否定响应的基本解释。
另一点，同样是针对 CloudFlare 的，是在他们的情况下很难计算“下一个”名称（因为NSEC实际上给出了两个名称的“范围”，作为现有两个事物之间的链接），所以而不是使用存储中存在的真实下一个名称，它们按照 DNSSEC 算法计算最小的“下一个”名称，因此上面带有作为\\000.前缀的奇怪名称，这个名称显然也不存在，因此如果您查询它您将再次收到相同类型的回复，但这次NSEC在右侧\\001.或\\000.\\000.实际上有一个记录列表，等等......
再向下：
\n\n\n对于 NXDOMAIN，我们总是返回 \\000.（缺少的名称）作为下一个名称，并且因为我们直接在缺少的名称上返回 NSEC，所以我们不必为通配符返回额外的 NSEC。这样我们只需要返回 SOA、SOA RRSIG、NSEC 和 NSEC RRSIG，并且不需要搜索数据库或预先计算动态答案。
\n
通过较小的回复就达到了目标。这在 DNS 领域很重要，因为存在与碎片有关的各种问题。从他们的例子来看，他们通过恶意谎言从 1096 字节减少到只有 357 字节，减少了近 2/3，这是一项相当大的成就！
\n对于那些想做同样事情的人来说，上述所有内容将来可能会成为“标准”，因为他们编写了一份文档，有一天可能会成为 IETF RFC：https: //datatracker.ietf.org/doc/html/草案瓦尔索达 DNSOP 黑色谎言
\n但请注意它会产生后果：
\nNXDOMAIN是一个重要的信号：各种其他东西都是建立在其之上的，请参阅 RFC 8020“NXDOMAIN：下面确实没有任何东西”和 RFC 8198“积极使用 DNSSEC 验证的缓存”，因此不再有此信号可能会产生副作用（改变其他递归解析器来尝试找出权威方是否使用恶意谎言然后考虑它们并不是一个好主意，这将是脆弱的；这一点在上面的草案中得到了确切的讨论）NSEC）没有正确计算，因此破坏了一些东西。如果我确实找到了我认为我所看到的内容，我会尝试更新此内容，但我可能有妄想（很容易与 DNSSEC 合作......）；事实上，我认为这与观察到他们所有最初的示例确实在NSEC上一节中放置了更多类型，现在他们只放置了RRSIG和NSEC。有关位图中错误及其后果的实时示例，请参阅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，但简而言之：
\n\n现在你可以用 NSEC 记录撒谎，[..]但是服务器永远不应该在 NSEC 记录中返回一个空的位向量。因为某些解析器（包括 Google\xe2\x80\x99s 公共\nDNS 服务）将空的 NSEC 位向量解释为声称该域名根本不存在资源记录。这不是 Google DNS 错误。这是对 DNSSEC 规范的完全合法的解释。Slack 遇到的问题是，当使用通配符条目形成响应且未为通配符资源定义查询类型时，Route 53 服务器返回的 NSEC 响应几乎为空 RR 类型位向量。这是 Route\n53 实现中的一个错误。
\n
所以，简而言之，撒谎有时确实会带来不好的后果:-)\n(和/或：DNSSEC 很复杂，DNS 中的通配符也会造成各种复杂情况；事实上 DNSSEC + 通配符 + CNAME 记录就像 3某种程度的世界末日的确定迹象......）。
\n这只是一种做事方式，其后果（几乎没有 NXDOMAIN 响应）绝对不是协议 (DNSSEC) 的结果，而只是其实现的结果。因此，不要认为这是理所当然的，这与其他提供商有所不同。但作为该区域的所有者或用户，它真的会给您带来什么改变吗？没那么多。您为什么如此担心NXDOMAIN回复:-)？
附：
\n在 Cloudflare 的特殊情况下，其权威服务器仍然会NXDOMAIN为未设置该DO位（不请求 DNSSEC 记录）的查询生成响应。
他们可能会也可能不会返回其他情况NXDOMAIN。
$ dig +norecurse nxdomain.cloudflare.com @ns6.cloudflare.com
; <<>> DiG 9.19.2-1+ubuntu20.04.1+isc+1-Ubuntu <<>> +norecurse nxdomain.cloudflare.com @ns6.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49384
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;nxdomain.cloudflare.com. IN A
;; AUTHORITY SECTION:
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com. 2282614227 10000 2400 604800 300
;; Query time: 3 msec
;; SERVER: 2400:cb00:2049:1::a29f:506#53(ns6.cloudflare.com) (UDP)
;; WHEN: Fri Jul 15 04:33:54 UTC 2022
;; MSG SIZE rcvd: 96
$ dig +dnssec +norecurse nxdomain.cloudflare.com @ns6.cloudflare.com
; <<>> DiG 9.19.2-1+ubuntu20.04.1+isc+1-Ubuntu <<>> +dnssec +norecurse nxdomain.cloudflare.com @ns6.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42126
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;nxdomain.cloudflare.com. IN A
;; AUTHORITY SECTION:
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com. 2282614227 10000 2400 604800 300
nxdomain.cloudflare.com. 300 IN NSEC \000.nxdomain.cloudflare.com. RRSIG NSEC
cloudflare.com. 300 IN RRSIG SOA 13 2 300 20220716053359 20220714033359 34505 cloudflare.com. VI/f0QNfsim677htUOQ4yZxFK41C2jzhXsF+T5/oFiQtwPIm3m3gLr3Y WB8NUpsje9v+ARFcQUPqM6SKGJ7CJQ==
nxdomain.cloudflare.com. 300 IN RRSIG NSEC 13 3 300 20220716053359 20220714033359 34505 cloudflare.com. 9BuyhrKElvzvzv5w4eOJRikcX3eFUOr9z6IYOgWjwez2tfVaR+P8x9kN uSYporOFom3KxhS3krcq9zbDO7kxdw==
;; Query time: 3 msec
;; SERVER: 2400:cb00:2049:1::a29f:506#53(ns6.cloudflare.com) (UDP)
;; WHEN: Fri Jul 15 04:33:59 UTC 2022
;; MSG SIZE rcvd: 363
（设置DO并不能保证解析器将验证响应。例如，非验证解析器可能会请求 DNSSEC 记录，以便将它们传递给验证客户端，或者测试中的部署可能会记录错误但接受虚假响应。）
| 归档时间： |
|
| 查看次数： |
2032 次 |
| 最近记录： |