翻译|测量DNS Flag Day的影响

原文地址：https://labs.ripe.net/Members/willem_toorop/measuring-the-impact-of-dns-flag-day

DNS Flag Day是多方努力的共同结果，经过DNS实现者的一致同意，DNS解析器运营商承诺从2019年2月1日起将不再为不符合标准的权威域名服务器提供解决方案。在DNS Flag Day之前，或者说作为推广的一部分，测量的关注点是那些需要修复的权威名称服务器。这篇文章中，我们将从另一个角度查看解析器及解析器的实现，在DNS Flag Day 之前解析器在互联网上有哪些行为，在实际中删除工作区的传播情况如何？

第一个DNS Flag Day 2019年2月1日

第一个DNS Flag Day 在2019年2月1日举行。这个启动活动的重点在于解决权威名称服务器丢弃EDNS请求的问题。

EDNS是在1999年(RFC 2671)上引入的一个DNS扩展机制。它使得DNS消息具有以下特性：

• 更大
• DNS响应具有更多的响应代码
• 扩展DNS头部具有更多比特位
• 扩展DNS支持尚未预见的未来功能和改进

这些扩展在1999年就被定义，包括DNSSEC的运行也需要EDNS的支持。

权威名称服务器不支持EDNS

不理解EDNS的权威名称服务器会发送RCODE FORMERR响应（RFC2671,更新于RFC6891）。这种情况下，不支持EDNS的名称服务器将立刻进行不使用EDNS的尝试。

非常不幸的是，在实际中一些不支持EDNS的权威名称服务器直接抛弃EDNS的请求，没有任何的回应消息。这对解析器来说是灾难性的，因为这种情况与丢包或权威名称服务器宕机没有什么区别。解析器与如此权威的名称服务器交互的惟一方法是在不使用EDNS时的特定超时后重试。这使得解析不必要的变得缓慢和低效。

所有发布的BIND、Knot、PowerDNS和Unbound新版本都不再使用这种解决方案，而是将没有响应的权威名称服务器视为宕机——在这篇文章中，我们将这些解析行为称为“严格的”和“宽容的”，两者有适当的变通方法。公共DNS经营商将立即或逐步地从宽容转向严格。

为了能够测量Flag Day声明之后的变化，我们在NLnet实验室、SIDN和罗切斯特理工学院创建了一个有目的的、不兼容的权威域名服务器，它可以删除任何EDNS查询。我们在NLnet Labs，SIDN和罗切斯特理工学院(Rochester Institute of Technology)创建了一个有针对性的不兼容的权威域名服务器，其会直接丢弃任何EDNS查询。该域名服务器的区域是flag .rootcanary.net。

宽松策略的解析器可以在这个域中进行名称查询，如test.flagday.rootcanary.net，而严格策略的解析器无法解析成功。

在Flag Day之前解析器的实现

首先，我们检查现有的开源解析器的实现来了解它们如何支持EDNS。我们发现有两种实现无法解析来自我们特意设置的权威名称服务器的域名。

1. Knot解析器没有添加任何的适应手段，它一直遵循着严格策略。
2. 目前最新的在Flag Day日之前使用的Power DNS递归解析器也不能解析测试域名。尽管Flag Day后的发行版4.2.0-alpha1的公告中提到了对某些工作区的删除，但在我们的测试设置没有并什么区别。

2月1日，BIND 和Unbound 的最新版本都是宽松策略的。BIND的9.13.7版本从2019年2月27日开始执行严格策略，Unbound 的1.9.0版本在2月5日开始执行严格策略。

从终端实体看Flag Day的影响

在2019年1月30日，我们开始使用RIPE Atlas探测器每四个小时使用向探测器上配置的DNS解析器发送一次查询。每个解析器都查询一个惟一的名称，并且不会重用以前中间件缓存的结果。因此，如果我们能够从测试的解析器上得到有效的响应，那么该解析器将被标识为“宽容策略”，而无效的响应或无响应将被标识为“严格策略”。

截至8月，我们已经对10127个探测器进行了测试，每个探测器有一个或者多个解析器，总共测试了19272个解析器。

值得注意的是，其中15%的解析器在Flag Day之前就已经在执行严格策略。截至2019年6月1日，这一比例已升至42%，见图3。之后，又上升了1.9%，最终测试达到了43.9%。

下面的图种从上到下分别是参与的公共解析器的结果:Cloudflare、Google Public DNS、Quad9和OpenDNS

注意，这些图显示的是解析器的绝对数量。例如，RIPE Atlas探测器中使用Cloudflare公共解析器的数量正在增加，但是使用严格策略的解析器的相对数量的增加的速率并不相同。

并且，由于Cloudflare使用的是Knot 解析器, 我们预期是在整个测量期间看到100%的执行严格策略的解析行为，但相反，我们在整个测量期间观察到一小部分宽容策略的解析行为。

对于Google Public DNS是完全不同的。从一开始，他们的基础架构中就有一小部分在执行严格策略的解析，然后从3月中旬开始逐步增加，直到4月的第三周左右达到峰值(几乎100%)。

Quad9开始已经有85%的解析器执行严格策略的解析。直到5月1日，这一数字突然增长到几乎100%。

OpenDNS仍然完全采用宽松解析策略。因此，其根本没有与Flag Day相关的活动。

Flag Day 对权威名称服务器的影响

RIPE Atlas 发出的每一个查询请求都有唯一的名称。在权威的名称服务器上，我们现在可以看到哪些包属于同一个解析器。这样我们就可以从权威名称服务器中的流量中识别执行严格策略和宽松策略的解析器。我们使用下面用伪代码表示的算法来进行区分过程：

for each unique QNAME:
    if all queries with EDNS:
        All IPs seen are strict
    elif at least one query without EDNS:
        All IPs seen are permissive

因为我们不需要关心响应，所以我们可以从Internet上的端点接触大量不同的解析器。我们还使用开放解析器来调度唯一名称的查询，并使用了Luminati(一个免费的VPN提供商，用户可以通过它提供的一个退出节点来发送查询)。表1总结了不同解析器IP地址的数量和不同ase的数量:

图9 展示了这些IP中执行严格策略的比例。与终端实体的角度类似，我们也看到2月1日之前实行严格策略的解析器的比例相当高：超过30%。从2月1日的35%到8月1日的40%，我们看到严格策略的缓慢增长。

与终端实体角度的测量相比，权威名称服务器测量开始时严格策略的解析器的百分比要更大，这表明流行的解析器在2月1日之前更加趋向于使用宽松策略。然而，与使用惟一IP的解析器的权威名称服务器相比，终端实体角度上严格策略的解析器显示出了更大的增长。因此，较受欢迎的解析器比较不受欢迎的解析器更有助于严格策略的普及。

图10显示了在权威服务器上最常见的前10个ASes的百分比。严格策略普及最明显的应用是Google Public DNS。

互联网变好了一点点

19年的DNS Flag Day唤醒了许多人的意识，督促他们调查和修复他们的权威服务器。从结果看，互联网确实变好了一点点。

但是，如果你的域名由不能满足测试的权威服务器提供服务，那么你的情况很糟糕。甚至在19年Flag Day之前，两个受测的开源实现就不能解析我们的测试域名，两个参与的公共DNS服务同样也不可以。

在2019年的Flag Day之前，RIPE Atlas 探测器观察的超过15%的解析器和在我们的权威服务器上观察的超过30%的唯一解析器，也不能解析测试域名。没有人注意到这可能与域名的弹性解析有关，可能不是服务于该域名所有名称服务器都坏了，也与终端实体的弹性供应有关，可能在严格策略解析器旁边配置了一个宽松策略解析器。

不过，严格策略的解析行为正在缓慢增长。一开始Google Public DNS非常快速的引入了严格解析策略，而我们确实看到在终端实体和权威服务器上都出现了持续缓慢的增长。也许终端实体的缓慢增长主要与使用Cloudflare解析器的探测器的缓慢增长有关？也就是说，在权威服务器上看到的缓慢增长不仅表明了这一点，而且还表明了不太流行的解析器的长尾问题。

在Flag Day到来之前，是否有必要急于解决DNS实现者和DNS解析器运行商不再支持的问题？

它的实现缓慢，再加上大部分解析器在19年Flag Day之前就已经执行了严格策略，这可能表明它并没有那么紧迫。

将提供的域名使用的权威域名服务器上的测量值与解析器测量值(如我们在本研究中所做的)相结合，可以帮助我们更精确地确定这一点。给出一个现实的规划肯定有助于减少 Flag Day的不确定性。

目前，下一个DNS Flag Day(2020年)正在讨论中。目前还没有确定日期，但是重点将放在由IP包碎片引起的DNS中的操作和安全问题上。查看官方网站，了解更多关于过去和未来DNS Flag Day的信息。