参考报告：亚太地区网络信息中心对2020年DNS“执行日”影响的测量

点击：作者：邱实牟承晋来源：昆仑策网【原创】发布时间:2021-10-22 08:21:22

当今时代，数字技术、数字经济是世界科技革命和产业变革的先机，是新一轮国际竞争重点领域，我们要抓住先机、抢占未来发展制高点。要提高数字技术基础研发能力，打好关键核心技术攻坚战，尽快实现高水平自立自强，把发展数字经济自主权牢牢掌握在自己手中。

为此，我们必须及时、深入、广泛地了解和掌握全球网络信息领域关键重大技术变革演进的事实真相，不断充实、丰富、提高和激发我们自身的创新与自立自强能力。

2019年2月1日，由行业内主流的DNS服务商和DNS技术提供商发起互联网（Internet，下同）史上的第一次DNS“执行日”（Flag Day），被称为是“无缝过渡到下一个30年的DNS时代”。2020年10月1日，实施了第二次DNS“执行日”，强制执行TCP承载DNS的要求和规定。

对此，亚太地区网络信息中心（APNIC）进行了网络状态测量，并于2020年12月14日发表题为《对2020年DNS‘执行日’影响的测量》报告（以下简称“报告”）；其中基于测量数据，分析了存在问题，指出了所实施的IETF标准“DNS扩展机制EDNS（0）”的技术缺陷及根源，提出了相关的改进建议。

报告的第一作者，杰夫•休斯顿（Geoff Huston），是亚太地区网络信息中心的首席科学家，也是从事研究互联网基础设施、IP技术和地址分配政策等方面的专家。

报告的第二作者，保罗•威尔逊（Paul Wilson），拥有在互联网行业30多年的经验，其中自1998年始，担任亚太地区互联网地址注册机构的负责人。

报告给出的信息量较大，不仅有助于对DNS应用、技术和工程现状与趋势的了解、重新认识以及建议采纳，而且在对互联网发展的思维和方法上给出了有意义的参考和启示。

报告中的相关技术术语，参考定义如下：

●UDP-Lite（Lightweight User Datagram Protocol，精简版用户数据报协议），是一种无连接通信的传输层协议（RFC 3828，2004-7），允许将有可能被损坏数据载荷发送给接收方，而不会被接收方直接丢弃；允许一些应用层协议（例如：一些视频编码传输的协议）在知晓部分应用数据受到损坏和影响的情况下，作出控制数据完整性的决定。

●ICMP（Internet Control Message Protocol），互联网控制报文协议。

●MTU（Maximum Transmission Unit），最大传输单元。

●NTP（Network Time Protocol），网络时间协议，基于UDP，用于网络时间的同步。

● MSS（Maximum Segment Size），TCP 最大报文段大小。

报告尤其适合网信业界专业从业人员参考、分析和探讨。报告来源：

https://blog.apnic.net/2020/12/14/measuring-the-impact-of-dns-flag-day-2020/

以下是参考译文。

对2020年DNS“执行日”影响的测量

（APNIC，杰夫•休斯顿，保罗•威尔逊）

在广域通信协议的发展中，互联网的体系结构曾迈出了非常激进的一步。网络的大部分功能没有被置于基础架构中，也没有利用网络功能来模拟可靠的边缘到边缘的电路系统（circuitry），而是使用了互联网协议（IP）作为网络服务的最小模式；除了不可靠的数据包传递之外，什么也没有；其他的一切都留给被连网的主机。

互联网的真正主力一直是TCP协议。该协议接受底层不可靠的数据报（datagram）服务，并构建基于连接的、可靠的应用传输电路。几乎所有广泛使用互联网所承载的应用都是使用TCP或TCP模式的变体。

IP协议族（suite）还包括IP数据报模式的分离，在IP数据报中添加了应用级的端口地址。这种基于数据报的传输服务，即是“用户数据报协议”（UDP）。UDP协议并没有被广泛使用，尤其是关注到滥用地址欺骗的广泛性和普遍性。如今，在公共网络中仅有仍在使用UDP传输的主流应用，似乎是网络时间协议（NTP）和域名系统（DNS）。

DNS似乎与UDP是一个理想匹配。在DNS的交互模式中，域名查询和解析响应都是小的数据包，很适合简单的数据包交换的网络模型。一旦发生DNS数据包丢失，无论是域名查询还是解析响应，都可以通过超时、重新查询和扩大请求域名服务器的范围予以恢复。如果数据包丢失的发生率很低，那么在正常情况下，对DNS数据包丢失的检测和恢复的开销，会被UDP传输的固有效率所抵消。这意味着，UDP承载DNS的制约因素之一，是丢包可能性的最小化。

为了降低UDP承载DNS的数据包丢失的可能性，DNS的应用可以采取一些措施，包括：

Ø 首先，域名查询方产生UDP数据包的长度（字节数），不应该大于接收方的UDP接收能力。在IPv4中，所有主机将收到的UDP数据包确保不超过576个字节。这就是说，只要被发送的信息量少于576个字节，信息发送方就无须担心对UDP数据包的大小限制。在DNS的应用中，UDP数据包被限制为最多512个字节。超过512个字节的信息将被截断，而且被作为一个信号，即该DNS的域名应该使用TCP进行重新查询。

Ø 其次，为了使基于UDP的协议有效运行，确实应该避免在IP层的数据分片。在IPv4中没有数据包碎片，是因为通过网络传输的最大数据包是68个字节。DNS没有尝试将其交互的数据处理限制在40个字节的载荷内（假设DNS的IP数据包没有可选项字段）。相反，DNS假设，IP层的数据包分片能力足够健壮，使UDP得以高效地承载应用，而且最大576个字节的IP数据包被分片是一个非常特殊的情况。

IP的这组能力和约束，归纳如下（表-1）：

【表-1 IP数据包的长度（字节）】

对DNS应用的设计假设是，IP数据包分片（碎片化）被认为是一种不可避免的情况。然而，所有的连网和运营IP协议的主机都需要与DNS通信，这就是说，在IPv4网络中不能假设所有的主机同时收到大于576个字节的UDP数据包。因此，在使用UDP传输时，DNS的有效载荷被限制为512个字节。

自此，IP和DNS都已经被改变了。关于在数据传输选项方面的考虑，DNS的主要变化是对域名查询的解析响应添加了数字签名。DNS安全扩展（简称DNSSEC）的数字签名，增加了DNS解析响应数据包的字节数。总体上，将大多数的DNS解析响应数据包保持在512个字节的UDP限制之内，越来越具有挑战性。同时，在将以太网模式作为数据包传输的共同标准方面，世界表现出团结一致，并且有一个事实上的规范，即非碎片化的IP数据包上限为1,500个字节。

为保持DNS规范不变，超过512字节的数据包可以被截断，并切换到TCP以获取大于512个字节的域名解析响应。如果这种情况发生率很低，是可以接受的方式；但是，如果DNS域名解析响应大于512个字节占很大比例，DNS可能会变得低效。客户端需要使用UDP进行查询，接收数据包截断的解析响应，然后打开TCP会话（session）以重新查询。姑且忽略复用与TCP 会话的相关尝试，仅从UDP切换为TCP的两步过程，将为这样的域名查询增加两次额外的往返（round trip）时延，并将在TCP过程中所产生的开销强加给域名解析服务器。

对需要提供更多信息的DNS域名解析响应，同时仍然保留UDP作为默认的DNS传输协议的方式，是在DNS域名查询中使用接收方的缓存扩展指标，即EDNS（0）扩展机制（RFC 6891，2013-4）。

请不要忘记，DNS的UDP传输最初被限制在512个字节数据包的原因，不是为了避免UDP分片，而是为了保证接收方能够完全收到DNS响应。在IPv4网络中，最小的未被分片的IP数据包只有68个字节。对576个字节或更小的IP数据包进行分片是非常正常的。EDNS（0）扩展机制的目的是允许客户端向服务器发出信号，表明其可以处理通过UDP传递的、大于默认512个字节最大有效载荷的DNS域名解析响应，而不是考虑该域名解析响应是否可能被碎片化。

因此，如果EDNS（0）有效载荷参数的主要目的不是为了避免UDP碎片，而是为了避免在没有确实必要的情况下过早启动TCP所带来的额外开销，那么有效载荷参数就可以设置一个更大的默认值。如果客户端主机对数据包的字节数有限制，那么就可以在域名查询中不使用EDNS（0）扩展，或者使用较小的缓存指标。RFC 6891中的EDNS（0）规范中提出，缓存的初始默认值为4,096个字节，其背后似乎就是基于这种思路。

简而言之，EDNS（0）所隐含的设计似乎是一种权衡：虽然IP碎片化的损失可能很糟糕，但是其严重性被认为低于过早从UDP切换到TCP的时延影响。

但是，对于网络稳固性的细小但重要之处仍需要得到持续关注。数据包分片对网络性能和安全都有影响，目前遵循的一般性原则是，互联网的应用和平台应该切实努力避免依赖于IP分片。在最好的状况下，应该完全避免触发IP数据包分片！

按照这种思路，重新调整EDNS（0）参数的作用。除了表示DNS接收方可以接受传入UDP数据包的最大数据包字节数之外，还添加了进一步的限定条件，即DNS数据包的字节数应小于或等于可以通过网络传递的最大UDP有效负载，而不会触发IP数据包分片（碎片化）。2020年的DNS“执行日”（Flag Day）的措施正是基于这种想法。

2020 年的DNS“执行日”（Flag Day）：

DNS 是一个高度异构的环境，有许多变动着的组件和许多供应商。事实证明，协调DNS中的变更非常具有挑战性，“Flag Days”是为协调集体行动的一种方式。

“Flag Days”允许DNS软件供应商更改他们的代码库，但是前提是更改的所有代码都必须是通用的。这种方法于2019年进行首次尝试，当时的目的主要是解决DNS解析服务器软件对实施EDNS的非规范性方式和删除一些“变通”的行为。

2020年10月1日，实施了第二次“执行日”，主要目的是修改DNS协议的行为，以避免依赖于碎片化的UDP数据包。

第二次“执行日”的主要目的是，DNS客户端应使用默认载荷（和缓存）为1,232字节的EDNS；并且如果DNS消息大于1,232字节，DNS服务器就不应通过UDP发送DNS域名解析响应。

由此，引发了一些问题，包括：

◣ 为什么选择1,232个字节？如果是为了避免IP数据包被分片，为什么不选择更大的指标参数，例如1,452个字节？

◣ DNS中的数据包由于被碎片化丢失的程度有多严重？

◣ TCP承载DNS的性能有多“差”？比碎片化的UDP是好还是更差？

DNS 测量（Measurement）：

APNIC实验室对DNS进行了测量。但是应该指出，我们使用的测量系统和方法存在局限性以及某些问题。

第一个限制，首先面对DNS实际上是一个松散耦合的网元组集合，要全面和完整地观察DNS交互的集合几乎是不可能的。在网络边缘的末端域名解析器系统，与一个或多个递归域名解析服务器之间存在着相互作用的关联关系，而这些递归域名解析服务器又都分别代表这些末端域名解析器执行域名解析任务。

然后面对受权域名服务器系统，包含一组区块的DNS信息，每个区块都可以通过若干个这样的受权服务器来发布。末端域名解析器和递归域名解析服务器可以是单独的系统，或者目前通常使用一组分布式的引擎来实现，这些引擎可以通过服务器“场”（farm）的集群作为域名查询的分布式前端，或者运用“任播”（anycast）将服务地址分布在互联网上。

任何测量都必须关注系统的一些受限子集。在我们的DNS测量中，观察递归域名解析服务器与受权域名服务器之间的解析性能受到限制。而且，我们的测量技术也不能直接观察末端域名解析器与递归域名解析服务器之间的相互交互通信。

第二个限制，是我们的DNS测量技术依赖于域名服务器对域名的解析。一些递归域名服务器在解析域名时改变了对域名查询的设置，并使用较小的缓存，甚至根本没有缓存。

第三个限制，是关于DNS测量的问题，即测量的单位，这个问题在类似的工作中很常见。

“DNS解析器是什么？”这是一个令人意外且难以回答的问题；还有一个因素是，有一些域名解析器比其他域名解析器更为关键。总体而言，一个服务于上亿个末端客户的递归域名解析器，比个人使用的一个末端域名解析器要显得更为重要。

在我们的测量工作中，对终端用户的计数被作为计量单位。这种方法在本质上是通过计量递归解析服务器的被测用户所表现出某种属性的百分比来测量DNS。如果一个测量显示有1.8%的被测用户无法通过TCP完成域名解析，那么这并不能说明有多少域名解析服务器具有这种状况。基于对用户的测量是对特定行为影响的测量。

“执行日”后的“正常”（Normal）状况如何？

为了建立控制测量基线（baseline），我们采集了一台受权域名服务器生成的DNS域名解析响应，从中随机选择了11种大小不同的数据包。结果如表-2 所示。

1.webp (2).jpg

【表-2 控制测量的基线】

每次单独的测试都要求递归域名解析服务器成功解析一个DNS域名响应（175个字节数据包）的控制实例。然后，所呈现的域名响应数据包所含字节是表-2 中所列出的情况之一。

令人惊讶的是，在尝试解析DNS域名响应数据包为1,230个字节时，并不如预期成功。大约0.5%的测试例（即200分之一），未成功完成域名的解析过程。

对于域名响应数据包从1,230个字节到1,430个字节，域名解析失败率基本一致。域名响应数据包为1,470个字节，对应的IPv4 UDP数据包为1,498个字节（略低于1,500个字节），对应的IPv6 UDP数据包为1,518个数据包。这就需要将UDP数据包分片，域名解析的失败率为0.9%，这个结果与IPv4域名响应数据包具有较低的域名解析失败率和IPv6域名响应数据包具有较高的域名解析失败率是一致的。

对于超过1,500个字节的DNS域名响应数据包，域名解析的失败率跃升至2.6%，或大约是40分之一。

TCP（传输控制协议）：

为了进一步地了解TCP承载DNS的状况，有必要通过利用有效载荷参数，了解客户端域名解析器与受权域名服务器之间的互动通信。

在EDNS（0）规范UDP承载DNS的数据包载荷之前，默认DNS 域名响应的最大UDP数据包为512个字节。这也是可以传递回客户端域名解析器的DNS响应的最大数据包。

如果DNS消息大于512个字节，那么服务器就可以在512个字节的上限内尽可能多地输入域名解析响应，并在域名解析的响应中设置截断位。客户端可以只使用所收到512个字节的域名响应，也可以截断位作为信号，与服务器建立TCP连接并通过TCP提出域名查询再请求。在TCP的数据传输中没有信息量的限制，并且假定TCP将成功地传输完整的域名解析响应。

EDNS（0）允许客户端指定DNS的UDP数据包大于512个字节。如果服务器的域名响应信息超过客户端查询所指定的字节数，则截断域名解析响应，并在UDP的数据包中设置截断标识位。

此外，域名服务器可能有已设置DNS的最大UDP缓存，在这种情况下，客户端在域名查询中指定的字节数与服务器所设置的缓存，其中的较小者被用于确定UDP域名解析响应的数据包截断点。

虽然TCP查询可以是由客户端发起，而不是由于触发UDP的数据包截断响应，但这种情况很少发生。我们观察到大多数TCP域名查询的发起，仅是在UDP截断响应传递回客户端解析器之后。

在我们测量场景中的TCP状况，如表-3 所示。

一旦域名响应信息超过1,470个字节，测试例中约有三分之一的实例，即域名响应信息大于DNS服务器设置的UDP缓存，并且截断的域名解析响应被传递回客户端解析器，以触发TCP重新查询（在表-3中的“TCP应用率”）。

DNS的TCP失败率约为1%。如果域名解析响应大于1,500个字节，则失败率会进一步增加约0.9%（在表-3中的“失败率”）。DNS的TCP失败率被分为三种类型：

1）TCP会话未被建立（在表-3中的“NO TCP”）；

2）TCP会话被建立，域名查询请求也发出了。但是当域名响应被传回给客户端解析器时，TCP会话就会中断，而没有对域名响应的ACK。对于较小的DNS域名响应数据包，在失败案例中这种情况发生约占四分之一；对于较大的DNS域名响应（多个TCP 段），在失败案例中这种情况上升到略低于二分之一，其最可能的原因是在TCP 路径上MTU（最大传输单元）不匹配，较大的TCP段（segment）无法传递到客户端（在表-3中的“NO ACK”）。

3）TCP会话似乎是正常完成了，但由于某些原因，完整的域名解析过程仍然是失败的（在表-3中的“TCP OK”）。

【表-3 测试中DNS的TCP应用】

在实验中，我们使用了1,500个字节的MTU设置，可能会在TCP传输路径上遇到一些问题。

UDP（用户数据报协议）：

实验中发现，仅在略多于一半的测试例中，DNS的UDP缓存被设置为4,096个字节。这低于“正常”状况，因为许多解析器在解析域名服务器的名称时会改变其行为。而“正常”状况的指标值是：DNS的UDP缓存被设置为4,096个字节的域名解析器，占比约为82%。这表明，在本实验中TCP承载DNS的使用率大约是一般预期的两倍。

在我们测量场景中的UDP域名解析失败率，如表-4 所示。

【表-4 测试中DNS的UDP应用】

没有被分片的UDP数据包（字节数小于1,500字节）的域名解析失败率不到TCP数据包（表-3）失败率的一半（小于二分之一），即通过UDP传输DNS数据包的域名解析失败率为0.4%。

当UDP域名响应数据包（字节数大于1,500字节）被分片时，域名解析失败率上升到3.0%，这比通过TCP传输DNS数据包的域名解析失败率更糟糕。尽管有许多解析器会宣称已为DNS的UDP设置了较大的缓存，但是仍无法接收较大数据包的UDP域名解析响应（被分片）。这很可能是由于路由路径上的IP数据包过滤器所造成的，其中丢弃数据包碎片是这类过滤器中的常见安全设置。

超过1,500个字节的DNS域名解析响应，其失败率上升了五倍：

在实验中观察到一些个例，一旦DNS域名响应的数据包超过1,500个字节，域名解析的失败率就会从0.5%上升到2.5%。在这些个例中，由于域名服务器使用碎片化的UDP传递域名解析响应占比约75%。换句话说，客户端解析器为DNS设置了一个较大的缓存并告知了域名服务器，但是基于客户端设置的较大缓存，域名服务器使用碎片化的UDP传递域名解析响应导致域名解析失败。

从客观的角度，EDNS（0）的缓存参数设置意在控制域名服务器的行为，以尝试避免通过UDP传输的DNS数据包被碎片化，是基于非常粗糙的猜测（very crude guesses）。因为客户端无法预知域名服务器的域名解析响应数据包将通过什么网络路径路由，并且各种域名服务器到客户端的数据路由路径MTU的发现技术，是基于服务器端的探测，而不是客户端探测。被传递的数据包大小是由服务器决定，只有服务器通过ICMP消息获知某路由路径上存在MTU不匹配。客户端永远无法了解互联网路由路径中的MTU特性。因此，客户端基于EDNS（0）所设置的数据包载荷充其量只是路由路径中MTU设置的简单“一厢情愿”（a crude substitute）。

如果EDNS（0）的目的，是在试图恢复被丢失的UDP数据包时减少无效和延迟，那么DNS解析器的缓存设置小一些（如“执行日”要求设置为1,232个字节）比设置为4,096个字节更有意义。

但是，设置相对较小的缓存具有自身的问题，因为由此会不必要地过早调用TCP，特别是在递归域名服务器与授权域名服务器的交互通信中。另一方面，TCP也存在其自身的问题是，即比未分片的UDP数据包的传输速度慢得多，当然数据传输也不可靠。现实是，并非所有的客户端解析器都能启用TCP承载DNS，这可能是由于局部或局域过度地热衷于数据包过滤规则。

综上，我们试图定位DNS，而统筹考虑的三个因素是：

1）没有被碎片化的UDP传输数据是快速、高效和非常可靠的。

2）TCP的数据传输速度较慢，效率较低，而且并不可靠；但是通过谨慎管理TCP的MSS（最大报文段大小）设置，以避免TCP黑洞（black holes），可以提升可靠性。

3）分片的UDP数据传输是性能最差的，不仅DNS解析的失败率很高，而且必须依靠本地计时器来检测数据包是否被丢失（或超时）。

这就意味着，对于DNS的数据传输，应该继续使用UDP；当DNS的信息大而数据包不得不被分片时，再切换到TCP传输。

那么，如何实现如此的DNS定位？如果指望运行基于UDP的精简版（简称UDP-Lite），为每一次DNS数据交互而发现传输的路由路径中MTU的操作，是不合理的。这就要求，客户端和服务器都应该使用保守的数据传输参数设置，以避免路由路径中出现MTU问题。

客户端DNS 解析器应该做什么？

2020年DNS“执行日”中要求的缓存参数设置是一个好的开端。但我们认为，仍然存在较大的局限性（don't quite catch the entirety of the space）。

在递归域名服务器与受权域名服务器的交互场景中，递归域名服务器应使用EDNS（0）设置的UDP载荷参数：对于IPv6，等于或仅略小于1,452个字节（考虑到40个字节的IPv6包头和8个字节的UDP包头）；对于IPv4，等于或仅略小于1,472个字节（考虑到20个字节的IPv4包头和8个字节的UDP包头）。

当启用TCP时，递归域名服务器客户端应设置载荷参数：对于IPv6，小于1,440个字节的MSS设置（考虑到40个字节IPv6包头和20个字节TCP包头）；对于IPv4，小于1,460个字节（考虑到20 个字节IPv4包头和20字节TCP包头）。

DNS 服务器应该做什么？

域名服务器应避免所传递的数据包被分片，可以通过将最大有效载荷参数设置为：对于UDP的数据传输，IPv6不大于1,452个字节，IPv4不大于1,472个字节。此外，还应该对TCP传输的数据包（IPv6的1,440个字节和IPv4的1,460个字节），施加一个约束上限。

域名解析器默认缓存1,232个字节显得太少

鉴于具体情况各不相同，在互联网边缘的测量与在网络基础设施内侧的测量存在差异。测量递归域名服务器与授权域名服务器之间在互联网基础设施内的行为表明，在IP数据包不超过1,500个字节时，网络的行为相对统一。

如果我们把自己限制在只是递归域名服务器与授权域名服务器之间的交互通信设置上，那么DNS“执行日”（2020年）所设置默认缓存1,232个字节显得太少了。其结果是，递归域名服务器与受权域名服务器之间的交互通信，将过早地调用TCP。在触发TCP之前，可以通过将UDP数据包字节数的限制上界提高到1,500个字节（包括IP包头），以实现一个更有效的结果。

同时，设置降低TCP段（segment）的字节数是谨慎的。从DNS交互通信的观点，使用1,200个字节的MSS参数，提高了性能但所付出的成本是非常小的，而且这样的设置对于进一步避免TCP 的MTU黑洞问题，可以得到保证。

因此，对DNS客户端和服务器的数据传输参数提出建议，如表-5所示。其目的是：在DNS数据包小于1,500 节，使用UDP传输；然后使用更具保守的MSS设置，以提高TCP会话的可靠性。