我们在去年年底推出了DNSSEC，目前已经每天签署569亿个DNS记录集。在这种规模下，我们非常关心计算成本。我们节省CPU周期的方法之一是在DNSSEC中实现否定答案。Chris Short的CC BY-SA 2.0图像我将简要地解释一些您需要了解的关于DNSSEC的概念和否定答案，然后我们将深入探讨CloudFlare在被问及不存在的名称时如何节省计算成本。你需要知道的是：DNSSEC版以下是DNSSEC的简要介绍：这是一个未签名的DNS应答（unsigned==no DNSSEC）：cloudflare.com网站A 198.41.214.162中的0.299cloudflare.com网站A 198.41.215.162中的0.299这是DNSSEC的答案：cloudflare.com网站A 198.41.214.162中的0.299cloudflare.com网站A 198.41.215.162中的0.299cloudflare.com网站.299英寸RRSIG A 13 2 300 20160311145051 20160309125051 35273cloudflare.com网站. RqRna0qkih8cuki++YbFOkJi0DGeNpCMYDzlBuG88LWqx+Aaq8x3kQZX TzMTpFRs6K0na9NCUg412bOD4LH3EQ==DNSSEC的答案包含返回的每个记录类型的签名。（在本例中，只返回一个记录，因此只有一个签名。）这些签名允许DNS解析程序验证返回的记录，并防止路径攻击者拦截和更改答案。你需要知道的是：否定回答版否定回答有两种。第一个是NXDOMAIN，这意味着请求的名称不存在。这方面的一个例子是缺少.cloudflare.com. 缺少.cloudflare.com根本不存在。第二种类型是NODATA，这意味着名称确实存在，只是不在请求的类型中。这方面的一个例子是请求blog.cloudflare.com. 有记录blog.cloudflare.com但是没有MX记录，所以适当的响应是NODATA。什么进入了DNSSEC的NXDOMAIN要查看在NXDOMAIN否定答案中返回的内容，让我们看看伪造.ietf.org.DNSSEC的否定答案中必须返回的第一条记录是SOA，就像在无符号否定答案中一样。SOA包含一些关于区域的元数据，并让递归器知道将否定答案缓存多长时间。ietf.org网站.1179在SOA ns0中。amsl.com网站. 格伦.amsl.com. 480601800003120000因为域是用DNSSEC签名的，所以SOA的签名也会返回：ietf.org网站.1179 IN RRSIG SOA 5 2 1800 20170308083354 20160308073501 40452ietf.org网站. 第二批共有34个。第四批是北京市第二批第二批第三批第三批第九批第九批第九批第九批第九批第九批第九批第九批第九批第九批第九批第九批第三批第三批第三批、第三批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批、第四批香港、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、第九批、CT4PLBIF+U86ONGBxVBNilyw2UISI2LY6KEO5AMK WNT0xHWe5+JTPD5PGMSM46YZ8JMP5MH4HSR76JQWVLCTxVQ8XGYQU/P QyuCpQ==DNSSEC中否定答案的下一部分是一个名为NSEC的记录类型。NSEC记录返回区域中的上一个和下一个名称，这向递归器证明查询的名称不可能存在，因为NSEC记录中列出的两个名称之间不存在任何内容。。NSEC cloudflare中的1062-verify.ietf.org. 一个RRSIG NSEC上面的NSEC记录告诉你伪造.ietf.org不存在，因为在和cloudflare-verify.ietf.org. 当然，这个记录的答案中也有一个签名：。RRSIG NSEC 5 4 1800编号1062 20170308083322 20160308073501 40452ietf.org网站. NxNxMjHkttooluOw/OreRebrexTfNyPM/r2p7oS/Hneodfi9TpggQyGnyjcnoodb/r56Kd+5wtuaKT+Xsiiz4K413i+cmrNQ+6oLT+Mz6 Kfzvo/TCRJD99Py线路在MWZ42OD/vi/JugkukjvczbkNHczqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqyyyFyfd3H8olfmhxT8F8F8 8Q 8Q/xjakakqqqqqqqqqqqqqqqqqqD77N2PXV6SJUKCSJZIQSGJEAM wIotSKa8EttJELkpNAUkN9uXfhU+WjouS1qzgyWwbf2hdgsBntKP9his 9MfJNA==还将返回第二个NSEC记录，以证明不存在可能覆盖的通配符伪造.ietf.org:ietf.org网站NSEC ietf1中的.1062_域名key.ietf.org. 一个NS SOA MX TXT AAAA RRSIG NSEC DNSKEY SPF上面的记录告诉您通配符（*）。ietf.org网站)会存在于这两个名字之间。因为在*处没有通配符记录。ietf.org网站，正如这个NSEC记录所证明的，DNS解析程序知道实际上不应该为返回任何内容伪造.ietf.org. 此NSEC记录还有一个签名：ietf.org网站.1062 IN RRSIG NSEC 5 2 1800 20170308083303 20160308073501 40452ietf.org网站. 五、五、五、三、五、五、五、五、三、四、九、四、四、四、九、九、四、四、四、四、四、四、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、五、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、三、二、三、三、二、二、二、二、二、二、九、二、九、九、二、九、九、二、九、九、九、九、九、九、九、九、九、九、九、九、九、九、九EMACFDQ2SSBR4P8HUOXIB tNlJWEubMnHi7YmLSgby+m8b97+8b6qPe8W478gAiggsNjc2gQSKOOXH EejOSA==总之，否定答案伪造.ietf.org包含一个SOA+SOA RRSIG+（2）NSEC+（2）NSEC RRSIG。总共有6条记录，返回的答案是1095字节（这是一个大的DNS应答）。区域步行你可能已经注意到了，因为否定的答案返回上一个和下一个名称，所以你可以不断地询问下一个名字，并且基本上"走走"这个区域，直到你知道其中包含的每个名字为止。例如，如果您要求NSECietf.org网站，你将得到该区域的名字，ietf_域名key.ietf.org:ietf.org网站NSEC ietf1中的0.1799_域名key.ietf.org. 一个NS SOA MX TXT AAAA RRSIG NSEC DNSKEY SPF如果你在ietf1上要求NSEC_域名key.ietf.org您将在区域中获得下一个名称：ietf1_域名key.ietf.org. NSEC中的1799apps.ietf.org. TXT RRSIG NSEC你可以一直往前走，直到你得到了这个区域的每个名字：apps.ietf.orgNSEC中的0.1799邮件.apps.ietf.org。MX RRSIG NSEC根区域也使用NSEC，因此您可以在根目录下查看每个TLD：根NSEC：NSEC aaa中的0.21599。NS SOA RRSIG NSEC DNSKEY公司.aaa NSEC：aaa.21599在NSEC aarp。NS DS RRSIG NSEC美国退休人员协会NSEC：美国退休人员协会21599，在NSEC abb。NS DS RRSIG NSEC分区步行实际上被认为是原始设计的一个特点：本文档中指定的完整NXT链使解析程序能够通过NXTs连续查询来获取区域中的所有名称。-RFC2535型（NXT是NSEC基于的原始DNS记录类型）然而，正如你所想象的，这对某些地区来说是个糟糕的主意。如果你可以在.gov专区走走，你可以了解美国所有政府机构和政府机构门户网站。如果你拥有一家房地产公司，每个房地产经纪人都有自己的子域，那么竞争对手就可以在你的区域内走来走去，找出你所有的房地产经纪人是谁。KIUI的CC BY 2.0图像所以DNS社区团结起来，找到了解决办法。它们将继续返回上一个和下一个名称，但会散列输出。这是在NSEC的升级版NSEC3中定义的。6RMO7 L6664KI2 HEHO7 JTIH1LEA9K6洛杉矶icann.org. 3599英寸NSEC3 1 0 5 2C21FAE313005174 6S2J9F2OI56GPVEIH3KBKJGGCL21SKKL A RRSIGNSEC3是解决这个问题的"近在咫尺，但没有雪茄味"的解决方案。虽然这确实使区域行走更困难，但这并不是说这是不可能的。使用NSEC3进行区域漫游仍然可以使用字典攻击。攻击者可以使用最常见主机名的列表，使用NSEC3记录中使用的哈希算法对其进行哈希运算（该哈希算法列在记录本身中），并查看是否存在匹配项。即使域所有者在哈希上使用了salt，salt的长度也包含在NSEC3记录中，因此要猜测的salt的数量是有限的。"Salt Length"字段以八位字节定义Salt的长度，值范围从0到255。"RFC5155型无数据响应如果您回想一下，NODATA是当服务器被要求提供一个存在的名称，但不是请求类型的名称时（例如blog.cloudflare.com). NODATA与NXDOMAIN的输出类似。它仍然需要SOA，但是只需要一个NSEC记录来证明下一个名称，并指定查询的名称上存在哪些类型。例如，如果您在apps.ietf.org，NSEC记录将告诉您，虽然没有TXT记录apps.ietf.org，有MX、RRSIG和NSEC记录。apps.ietf.orgNSEC中的0.1799邮件.apps.ietf.org。MX RRSIG NSEC否定答案的问题否定答案有两个问题：首先，权威服务器需要返回上一个和下一个名称。正如您将看到的，这对于CloudFlare来说计算成本很高，而且正如您已经看到的那样，它可能会泄漏有关区域的信息。第二个是否定答案需要两个NSEC记录及其两个后续签名（或三个NSEC3记录和三个NSEC3签名）来验证一个名称的不存在。这意味着答案比实际需要的要大。前一个名字和下一个名字的麻烦CloudFlare在Go中内置了一个名为RRDNS的自定义内部DNS服务器。RRDNS的独特之处在于，与标准DNS服务器不同，它没有区域文件的概念。相反，它有一个键值存储，保存所有域的所有DNS记录。当它获取一个记录的查询时，它可以只选择它需要的记录。CloudFlare DNS的另一个独特之处在于，我们的许多业务逻辑都是在DNS中处理的。我们经常动态地生成DNS应答，所以在被询问之前，我们并不总是知道我们将用什么来响应。传统的否定答案要求权威服务器返回丢失名称的上一个和下一个名称。因为CloudFlare没有区域文件的完整视图，所以我们必须要求数据库进行排序搜索，以找出前一个和下一个名称。除此之外，因为我们在运行中生成答案，所以我们没有可靠的方法来知道前一个名字和下一个名字，除非我们提前对每个可能的选项进行预计算。对前一个名字和下一个名字以及保密问题提出的一个解决方案是RFC4470，被称为"善意的谎言"。这个RFC建议DNS操作员通过随机生成在请求的名称之前和之后稍显规范的名称来组成上一个和下一个名称。善意的谎言是伟大的