女士们先生们，我希望你们欢迎新的闪亮的RFC8482，它有效地抑制了DNS的任何查询类型。dnsany是一个"元查询"——可以把它看作与常见的a、AAAA、MX或SRV查询类型类似的东西，但与这些查询类型不同的是，它不是真正的查询类型——它是特殊的。与标准查询类型不同，任何查询类型的使用寿命都不太长。它很难在现代DNS服务器上实现，社区对它的语义理解很差，它不必要地暴露了DNS协议的滥用。RFC8482允许我们清理它-这是件好事。但让我们倒带一点。历史背景这一切都始于2015年，当时我们正在查看权威DNS服务器的代码。代码流总体上还不错，但却充斥着这样的调皮语句：如果qtype=="任何"{//特殊情况}这个特殊的代码很难看而且容易出错。这让我们思考：我们真的需要它吗？"ANY"不是一个流行的查询类型-没有合法的软件使用它（qmail除外）。图片由Christopher MichelCC 2.0制作任何对现代DNS服务器来说都是困难的"ANY"查询，在旧的rfc中也称为"*querys"，应该返回"allrecords"（引用RFC1035）。这个概念有两个问题。首先，它假设服务器能够检索"所有记录"。在我们的实现中-我们不能。我们的DNS服务器，像许多现代的实现，没有一个单一的"区域"文件列出一个DNS区域的所有属性。这种设计使我们能够快速响应，并且信息总是最新的，但它使检索"所有记录"变得异常困难。对"ANY"的正确处理会为晦涩、很少使用的查询类型增加不合理的代码复杂性。其次，许多DNS响应是按需生成的。仅举两个用例：我们的一些DNS响应是基于位置的我们对DNSSEC使用了黑色谎言和DNS猎枪在现代数据库中存储数据并动态生成响应是任何一个基本问题。任何东西对客户来说都很难就在同一时间，一场灾难发生了——Firefox开始发布DNS代码，发布"ANY"类型。和往常一样，这是善意的。Firefox开发人员希望获得A和AAAA查询的TTL值。引用DNS专家Andrew Sullivan：一般来说，ANY对于故障排除很有用，但决不能使用用于常规操作。考虑到这些影响，它的产出是不可预测的缓存的数量。它可以返回大量的结果集。在用户代码中，您不能依赖任何正常的东西来执行"ANY"查询。虽然"ANY"查询在DNS权威端有一定定义的语义，但在DNS解析程序端它是未定义的。这样的查询可能会混淆解析器：它是否应该将"任何"查询转发给权威机构？它应该用缓存中已经存在的任何记录来响应吗？它是否应该混合上述行为？它是否应该缓存"ANY"查询的结果并将数据重新用于其他查询？不同的实现可以做不同的事情。""任何"并不意味着"全部"，这是造成混淆的主要原因。让我们高兴的是，Firefox很快就放弃了这一改变，并停止发出任何查询。网络运营商很难做到一个典型的50Gbps DNS放大针对我们的一个客户。袭击持续了大约4个小时。此外，由于"ANY"查询可以生成较大的响应，因此它们通常用于DNS反射攻击。权威提供者接收欺骗的任何查询并将大的答案发送给目标，这可能会导致DoS损坏。我们已经在博客上多次提到：使Spamhaus离线的DDoSDNS放大攻击的深层次反思CPSC是如何在不经意间成为最大攻击的幕后黑手任何DoS问题都是很老的问题。下面是一个关于2013年的补丁程序的讨论。还有第二个角度来解决任何DoS问题。一些报告指出，performantdns服务器（权威或解析程序）可以用大量的响应来填充其出站网络容量。建议很简单——网络运营商在回答大型DNS查询时必须使用"响应速率限制"，否则会造成DoS威胁。"ANY"查询类型恰好经常给出如此大的响应，而对合法用户几乎没有价值。终止任何2015年，我们对我们宣布的经历感到失望，我们希望停止对"任何"问题作出回应，并写了一篇（一次有争议）博文：不推荐使用DNS任何元查询类型一年后，我们继续解释可能的解决方案：接下来发生了什么-任何今天我们来了！在RFC8482中，我们有一个RFC提议的标准来澄清这个有争议的问题。任何查询都是背景噪音。在正常情况下，我们看到的任何查询量都非常小。用户的未来对于"ANY"查询可以做些什么呢？RFC8482规定：接收到ANY查询的DNS响应程序可以拒绝提供传统的任何响应，或者可以用答案中有单个RRset（或可用RRset的较大子集）第节。这清楚地定义了角落的情况-从现在起，权威服务器可以对"any"查询使用任何查询类型进行响应。有时候像这样简单的事情最重要。这为实现者打开了一扇大门——我们可以为这些查询准备一个简单的答案。作为一个实现者，您可以在响应中粘贴"A"或"AAAA"或任何其他内容。此外，规范建议返回一个特殊的（到目前为止很少使用）HINFO类型。事实上，我们就是这样做的：$随便挖cloudflare.com网站@ns3。cloudflare.com网站.；；答案部分：cloudflare.com网站.3789在HINFO"ANY Obsoled""见ietf dnsop草案拒绝任何"哦，我们需要更新消息，以提到新的RFC编号！NS1同意我们的实施：$随便挖nsone.net网站@dns1.p01。nsone.net网站.；；答案部分：nsone.net网站.3600 IN HINFO"ANY not supported.""见ietf dnsop草案拒绝任何"我们的终极英雄是维基百科，这完全符合RFC的建议：$随便挖维基百科.org@ns0。维基媒体.org.；；答案部分：维基百科.3600，HINFO"RFC8482"""在解析程序服务中，我们使用NOTIMP代码停止任何查询。这使我们更确信解析程序不用于执行DNS反射：$随便挖cloudflare.com网站@1.1.1.1；；->>头