差不多一年前，我们宣布将停止回答DNS的任何查询。我们受到许多因素的推动：没有合法的使用。大量的恶意使用。在大型DNS放大DDoS攻击中经常使用任何查询。此外，我们即将推出Universal DNSSEC，我们可以预见组装任何答案并为这些答案提供DNSSEC的高昂成本，尤其是在大多数情况下，这些答案都是针对恶意的、不合法的客户的。尽管我们通常会花很大的精力来维护跨Internet协议的向后兼容性（例如，最近，继续支持基于SHA-1的SSL证书），但我们清楚地看到，DNS ANY查询是从Internet上删除而不是保留用于一般用途的东西。我们当时的建议是向查询者返回一个错误代码，告诉他们任何一个都不受支持，这在DNS协议社区引发了一场激烈的讨论。在这篇博文中，我们将介绍发生了什么，以及我们的最终计划是什么。就在我们发表博客之前，一个流行的软件开始使用任何查询来获取一个名字的所有地址记录，而这并不是ANY设计的。这个软件的效果是，我们稳定的任何查询负载在几天内从每秒几百次增长到数万次。幸运的是，该软件发布了一个没有使用ANY的修订版本，并且我们稳定的ANY查询负载恢复到原来的水平。CC BY-SA 2.0图像Liam QuinnDNS社区中的对话当这一切发生时，DNS社区中的人们开始形成一场热烈的讨论。必须回答的第一个基本问题是："任何东西都意味着一切吗？"。也就是说，ANY查询是用来接收某个区域中查询名称的所有记录的一种方式吗？根据他们所提供的DNS服务的种类，不同的人对任何服务都有不同的解释。例如，作为一个DNS解析程序的操作员，能够询问您自己的解析程序，"在解析程序内存/缓存中存储的特定名称是什么？"。具有正确查询标志的ANY查询可以帮助回答这个问题。另一方面，权威服务器的操作员不需要该功能，因为AXFR提供了另一种获取信息的可靠方法。简言之，ANY查询对于那些试图了解DNS解析中发生了什么的人来说是一个很好的工具。一些社区成员认为，任何查询都应该是对少数需要知道的特权人士的限制查询。虽然ANY可以是调试和暴露解析器缓存中不一致性的好工具，但它仍然不是一个好工具：随着越来越多的Anycast解析器集群，无法保证两个后续查询会命中同一个解析器。为什么对像CloudFlare这样的DNS提供商来说，回答费用太高了？我们的动态DNS服务器是为了提供优化的内部问题解答。例如，根据CNAME的配置方式，我们的服务器可能返回CNAME，从CNAME的目标获取真实答案（我们称之为CNAME扁平化），或者提供CloudFlare地址作为答案。因此，为了回答任何查询，我们需要计算所有可能的组合，以知道返回什么。除此之外，我们的DNSSEC实现会动态地签署答案。因此，在应答中返回包含许多不同类型DNS记录的应答需要在边缘对所有DNS记录进行签名。因此，为任何"传统"意义上的支持都具有严重的计算和响应时间影响。这并不是CloudFlare独有的；我们并不是唯一一个在回答任何查询时具有如此高成本因素的DNS实现。在DDoS攻击中使用任何查询在Akamai最近的一篇论文中，作者得出结论，DNSSEC是DDoS攻击使用大量答案的主要原因。但是看看他们在论文中包含的数据包捕获，很明显造成大答案的真正原因是攻击者使用任何查询来最大化放大因子。Vladimer Shioshvili的CC BY-SA 2.0图像我们经常看到企图利用我们强大的DNS系统作为反射源的攻击。为了应对这种情况，我们建立了先进的系统来检测攻击并以负责任的方式减轻攻击。我们对任何人的抨击都是这些保护措施的关键部分。我们的一个主要口头禅是"不要返回大于需要的答案"，这正是为了帮助保护互联网上的其他人免受放大攻击。DNS协议社区中"抑制任何"的演变在我们宣布了对ANY的计划后不久，我们向IETF提交了一份互联网草案，建议将任何查询仅限于授权方。在随后的讨论中，很明显，这里重要的是我们如何反对任何一个。为了确保没有系统受到不利影响，我们必须考虑到各种应用程序和DNS实现是如何使用ANY的。简而言之，任何查询都有两个主要用途：一些程序使用ANY作为概率优化尝试，以获得所需的答案。有些人在出错时使用ANY来调试DNS解析程序。然而，这两个用例都不能满足当前的任何环境。对于如何处理作为ANY查询结果缓存的答案，解析器之间缺乏共同的行为。一些解析程序将在更具体的查询匹配时返回此数据，而其他解析器将获取确切的请求数据，即使它们已经从ANY查询缓存了该数据。这是因为解析器以不同的方式解释RFC2181第5.4.1节（排名数据），而且有些解析器编写时根本没有应用RFC2181中的规则。如果解析程序的缓存中存在该名称的单个RRset，则某些解析程序不会将任何查询转发给权威服务器，而其他解析程序则会转发查询，除非它们在缓存中事先有任何答案。此外，有些解析器只会重用ANY查询的结果来回答其他ANY查询，对所有其他类型的查询将导致对所请求类型的直接查询。在许多情况下，ANY查询导致的答案太大，无法满足所请求的UDP数据包大小，从而导致答案被截断，从而导致通过TCP进行后续操作。有一段时间，DNS社区认为返回截断的答案可以阻止攻击，但实际上，这只会减轻使用伪造数据包的简单攻击。在通过开放解析程序反映的攻击中，返回被截断的数据包将不起作用，因为如果UDP应答设置了截断位，则打开的解析程序很乐意退回到TCP。因此，对于如何处理ANY查询以最小化其放大潜力，目前还没有共识。公平地说，ANY查询是一种称为元查询的特殊类型的查询，即它不是实际类型。然而，社区被分成两个阵营："ANY==ALL"和"ANY！=全部"。社区也被进一步划分为"任何人都可以"和"任何人都应该只限于"好"客户"的群体。从一开始我们的立场就是"任何！=ALL"我们正在寻找一种方法来帮助遏制互联网上使用任何。几个月来，我们进行了大量的实验，以了解不同的DNS系统如何对ANY查询的不同非ANY响应作出反应。在与世界各地的同事进行了大量的实验和讨论之后，我们决定采用一种以递归解析器为中心的方法。我们想要做的是给出对递归解析器友好的答案，也就是说，我们给它们一些小的东西，它们可以缓存并返回到重复的任何查询中。将错误返回给递归解析程序并不是一个好的选择，因为解析器在放弃之前只会询问下一个权威服务器并访问所有权威服务器。我们还希望避免猜测查询发起者的意图，这就是为什么我们没有按照一个建议提供A+AAAA+MX记录或CNAME（如果存在的话）。我们不喜欢这样，因为答案比它必须要大，而且答案中的数据比发起者想要的还要多。例如，假设一个电子邮件服务器需要一个MX记录（如果存在），但是如果MX不存在，它将回退到一个IP地址。相反，我们决定返回一个我们称之为"无害"的答案-一个对互联网上的任何应用程序都没有用处的答案。我们选择了一个旧的DNS记录类型，它已经不再使用了，但是它具有所有测试工具都显示为文本的良好属性：HINFO。这种方法记录在当前的因特网草案中，拒绝IETF处理DNS协议问题的DNSOP工作组采用的任何草案。正如您在下面看到的，当被要求任何时，我们只返回一个HINFO记录和一个可选的RRSIG，这只在区域被签名时需要。这个记录可以被缓存，并且有一个额外的好处：很小，因此可以减少攻击者预期的放大系数。；挖9.8.3-P1@ns2.p31。dynect.net公司. 亚马逊网站. any+dnssec+norec公司；（找到1台服务器）；；全局选项：+cmd；；得到答案：；；->>头