今天分享的论文主题为DoH性能测量，由来自伊利诺伊大学厄巴纳-香槟分校和斯坦福大学的研究人员共同完成。该论文使用代理网络对DoH和Do53的性能进行了测量，比较了四家公共DoH提供商在各方面的表现。此外，作者还分析了DoH和Do53解析时间之间的地理差异及可能原因，总结了对DoH生态系统的潜在改进方案。该论文发表于国际网络测量领域顶级会议ACM IMC 2021。
全文共4000字，阅读时间约15分钟。
01
【研究背景】
近年来，DNS-over-HTTPS（DoH）作为未加密DNS的隐私保护替代方案获得了极大的关注。一些行业参与者提倡把DoH作为Do53（基于UDP的传统未加密DNS）的隐私保护替代方案：Mozilla Firefox已经默认在Firefox中为美国用户使用DoH[1]；Google宣布将在Chrome[2]中逐步默认支持DoH；微软计划在Edge浏览器和Windows操作系统中支持DoH；Apple已在其各平台中支持加密DNS。
在DoH性能方面，已有多项研究测量了DoH相对于传统DNS和其他加密DNS方案的性能差异，但这些研究要么仅从个别国家或地区进行测量[3]，要么无法将加密DNS与默认DNS行为进行直接比较[4]。相比之下，本文的重点在于直接比较DoH与用户端默认DNS的性能，以评估过渡到DoH所带来的性能影响。此外，作者还试图理解过渡到DoH是否会对不同国家和地区的用户产生差异性影响，以及这些差异的形成原因。这对全球合理部署DoH至关重要。
02
【 主要方法】
2.1 概述
为了测量DoH和Do53，作者利用BrightData代理服务（以前称为Luminati）[5] 从不同国家的代理节点发起请求，该服务通过安装HolaVPN的出口节点在全球范围内路由流量。HolaVPN为用户提供免费的VPN访问权限，与此同时，用户的机器也会成为Hola网络的一部分。
图表1：测量实验设置
图表 1 展示了测量实验配置。作者搭建了一个 Web 服务器（域名为“a.com”，位于美国）和权威域名服务器，分别用于接收HTTP和DNS请求。作者还控制测量用户端与BrightData的主控代理服务器（Super Proxy）通信，该Super Proxy可以指示各出口节点通过DoH或Do53来解析实验域名。通过为特定请求指定出口节点的国家或地区，测量实验可以在全球范围内定位用户。而通过相同出口节点发出多个请求，可以测量DoH和Do53性能。
作者针对四个公共DoH服务提供商（Cloudflare、Google、NextDNS和Quad9）进行了测量研究。在实验中，用户端使用国家代码和目标公共DoH解析器作为输入，首先连接到BrightData Super Proxy的代理服务器，然后通过指定国家/地区的出口节点发起请求。代理服务器会在给定国家或地区范围内随机选择的出口节点，并将用户端请求流量转发至该出口节点。
对于每个出口节点，作者会完成两项测量实验，总共发送 5 个请求：四个请求用于测量四个DoH提供商，一个请求用于测量用户端的默认DNS解析器。具体的测量方式如下：
DoH 测量。通过出口节点向每个公共DoH解析器发起DoH解析请求，查询a.com的唯一子域。
Do53 测量。通过出口节点向Web服务器发起HTTP GET请求，主机名称为a.com的唯一子域，这会在出口节点触发默认的DNS解析协议。作者通过实验验证了没有操作系统的默认配置为使用DoH协议，因此认为Do53仍然是这些用户端的默认配置。
在这两项测量中，作者利用UUID为每个请求生成唯一子域（如.a.com），强制用户端每次都会向权威域名服务器发起请求。这样做是为了避免缓存的影响，同时可以将解析性能的差异归因于传输协议本身而不是解析的域名。
2.2 计算方法
作者基于一些假设提出了计算DoH和Do53查询时间的方法，具体如下：
（1）DoH查询时间
图表 2 DNS-over-HTTPS（DoH）请求的时间序列
图表 2 展示了DoH请求的时间序列：测量用户端向BrightData Super Proxy发送请求，代理服务器将请求转发到出口节点并建立到DoH服务器的TCP连接（步骤1-8），然后测量用户端使用TCP信道与DoH解析器建立TLS会话（步骤 9-14），最后测量用户端向DoH解析器发送解析请求，解析器通过请求作者的权威名称服务器来解析域名（步骤 15-22）。
作者对这个过程做了两个假设：用户端和出口节点之间的往返时间是相对稳定的；BrightData仅在作者建立TCP信道时（步骤 1-8）需要花费一定处理时间（t_BrightData）。信道建立后，BrightData Super Proxy和出口节点转发后续请求的时间可以忽略不计。基于这两个假设，作者计算出DoH的解析时间为：
其中，T_A、T_B、T_C、T_D是测量用户端上可以获得的四个时间戳，图表 2 中标记为A、B、C、D，t_3、t_4、t_5、t_6是图表 2 中步骤 3-6 所花费的时间，这些都可以从测量信息和标头信息中获知。
（2）Do53查询时间
对于Do53测量，作者直接从BrightData的响应头中提取时间信息。具体来说，在通过Super Proxy指示出口节点访问.a.com网站的过程中，出口节点使用具有默认配置的传统DNS解析（如DNS-over-UDP），而Do53的查询时间会被记录在Super Proxy响应的标头中。
（3）DoH 连接重用
现有研究表明，如果用户为多个DNS解析重用相同的TLS连接，则可以提高DoH性能[6, 7]，因为不再需要执行TCP握手或建立TLS会话。然而，直接在出口节点测量DoH连接重用的性能是不可行的，因为BrightData Super Proxy在每次发送请求后会将关闭连接。
作者用t_DoHR表示第一次查询之后的DoH查询时间。为估计t_DoHR，作者假设出口节点和DoH解析器之间的往返时间几乎相同，然后通过从t_DoH中减去DNS解析、TCP 握手和TLS会话建立的时间来计算其上限值。
03
【测量结果】
本文首先通过小规模实验证明了前述假设及方法的有效性，然后开展了完整的测量。
测量数据集收集于2021年4月至5月，涵盖来自224个国家或地区的 22,052 名用户，分别位于 2,190 个不同的自治系统 (AS)。此外，作者通过权威域名服务器观察到了来自 1,896 个递归解析器的查询，图表 3 展示了不同提供商和Do53的解析器对应国家和用户数量，图表 4 展示了数据集中每个国家的用户数量。
图表 3 数据集组成
图表 4 数据集中每个国家的用户数
图表 5 解析器的解析时间
图表 5 展示了Do53、有初始TLS握手、无初始TLS握手的三种DoH请求的用户端解析时间累积分布图。其中Cloudflare的表现脱颖而出，因为它的大部分用户的DoHR解析时间非常接近Do53解析时间。在图表 6 中，作者按地理位置展示了每个提供商的表现，其中不同颜色表示各提供商DoH解析时间的中位数，黑色星星为每个提供商的入网点（points-of-presence, PoPs），从中可以看出四个提供商在解析时间和入网点的分布上都有较大差异。
图表 6 DNS 解析时间和入网点（PoP）
最后，通过对用户端和解析器进行地理定位，作者调查了真实世界的用户端是否正在使用每个提供商最近的可用入网点（PoP）。作者提出了一个评价指标——“潜在改善（Potential Improvement）”，用以近似表示“实际的用户端到其DoH入网点的距离”与“测量数据中的用户端到DoH最近入网点的距离”之差。图表 7 显示了每个提供商的“潜在改善”分布情况。
图表 7 到DoH入网点距离的潜在改善
下面是对每个解析器提供商测量结果的总结：
**Cloudflare。**Cloudflare是表现最好的DoH提供商，从DoH解析时间和地理角度来看都表现不错。
**Google。**Google用户的初始DoH解析时间中位数在四家提供商中排名第二。然而，就后续请求的时间（DoHR）而言，Google的中位数总体排名第三。值得注意的是，与其他提供商相比，Google的入网点数量要少得多，甚至在非洲没有任何入网点。这引发了一个问题：为什么Google的解析时间仍能与其他提供商不相上下？图表 7 提供了一种可能的解释：与其他提供商相比，Google似乎极大地减少了使用不必要的远程入网点的情况。
**NextDNS。**与其他提供商不同，NextDNS没有自己的自治系统（AS）来运行解析器。作者观察到NextDNS的 107 个入网点是通过分布在至少 47 个不同AS上的递归解析器来实现的。也许正是因如此，实验测得的NextDNS DoH性能最差。
**Quad9。**Quad9在性能方面居于中间位置。从图表 6(d) 可以观察到，Quad9在撒哈拉以南的非洲地区拥有比其他提供商更多的入网点，但这并没有明显的优势，因为Quad9在这些地区的性能与Google和Cloudflare相似。此外，从图表 7 中可以看出，相比其他提供商，Quad9在将用户分配到入网点的方式上还有很大的改进空间。
作者还发现不同国家的DoH性能存在显著差异。例如，中非国家乍得国的用户平均花费2,011毫秒来解析初始的DoH查询，而解析Do53查询的平均时间为1,280毫秒。相比之下，百慕大的初始DoH解析时间中位数为204.1毫秒，Do53 为90.5毫秒。为了比较各国的DoH和Do53测量值，作者计算了各国解析时间中位数之间的差值（delta 值）。图表 8 显示了所有国家delta值除以完成初始DoH请求的解析器数量的累积分布情况。
图表 8 DoH解析器的DNS性能
对于大多数国家，切换到DoH会增加执行单个DNS查询时间。但是在8.8%的国家，切换到DoH反而减少了执行单次DNS查询时间。例如，与Do53相比，巴西的用户使用初始DoH时DNS性能提高了 33%。此外，在这个指标下，四个DoH提供商中Cloudflare的DoH解析对性能的影响最小。
04
【DoH性能差异分析】
在上述测量结果的基础上，作者分别从国家和用户端两个层面出发，分析影响用户端DoH和Do53性能差异的因素。
首先，一个主要问题是国家的经济和互联网基础设施发展状况与DoH部署造成的影响是否呈线性关系？也就是DoH部署是否会对发展程度更低的国家造成比想象中更严重的影响？为此，作者从世界银行收集了人均国内生产总值（GDP）数据，用以表示不同国家的经济发展水平，并使用Ookla的Speedtest服务收集的各国固定宽带速度指数和IPInfo收集的各国AS数量来代表对应国家的互联网基础设施发展水平。作者开发了一个Logistic模型和一个线性模型，研究哪个变量会对DoH减速的影响更严重，以及各变量相对于彼此的强度。
Logistic模型的输入变量包括带宽、收入水平、ASN数量、解析器提供商。实验结果（图表 9）表明，从Do53向DoH过渡将对收入较低和互联网基础设施投资较少的国家产生比预想中更大程度的影响。
图表 9 Logistic回归结果（p < 0.001）
为了衡量每个解释变量对Do53和DoH解析时间之间增量的连续结果的影响，作者通过线性回归函数对结果进行建模，输入变量包括人均GDP、宽带速度、每个国家可用的AS数量、从用户端到作者的权威名称服务器的测地距离以及从用户端到DoH解析器的测地距离。图表 10 显示了线性回归的结果。作者将线性回归的系数作为模型权重，它显示了每个变量对结果的相对影响。其中，国家对互联网基础设施的投资是DoH减速程度的最大影响因素，而到DoH递归解析器的距离是第二大因素。
图表 10 线性回归结果（p < 0.001）
05
【总结】
作者根据测量结果，从多个角度提出了实行更合理的DoH部署方案的建议。
（1）软件提供商。软件提供商已在逐步推进DoH部署，但对于互联网基础设施发展和经济发展水平较低的国家，这可能会带来不成比例的、比预想中更严重的影响。因此，作者建议软件提供商不要将DoH作为用户端DNS解析的默认选项，并建议允许用户选择是否加入DoH服务，甚至可以提供相关信息帮助用户做出决策。
（2）改进DoH解析服务。DoH 减速的第二个重要因素是用户与执行解析的递归解析器之间的距离。作者观察到不同提供商的解析器选择策略截然不同，例如Cloudflare会在广泛的地理位置建设入网点（146 个），而Google仅在关键的地理区域使用较少的入网点（26 个）。此外，拥有较多入网点也不足以保证高效性。以Quad9为例，它在撒哈拉以南的非洲地区拥有较多的入网点，但该地区的用户却会被分配到整个非洲甚至全球的入网点，从而导致效率低下。因此，提供商应改进为每个用户分配入网点的方法，以确保用户能够充分利用附近的入网点。此外，全国带宽仍然是决定DoH性能的主要因素，在将用户端的解析方式切换到DoH之前必须认真考虑互联网基础设施建设情况。
--
参考文献
[1] Mozilla. 2020. https://blog.mozilla.org/blog/2020/02/25/!refox-continues-pushto-bring-dns-over-https-by-default-for-us-users/
[2] Martin Brinkmann. 2020. Chrome 83: rollout of DNS over HTTPS (Secure DNS) begins. https://www.ghacks.net/2020/05/20/chrome-83-rollout-of-dns-over-httpssecure-dns-begins/.
[3] Austin Hounsel, Paul Schmitt, Kevin Borgolte, and Nick Feamster. 2021. Can Encrypted DNS Be Fast?. In Passive and Active Measurement Conference.
[4] Chaoyi Lu, Baojun Liu, Zhou Li, Shuang Hao, Hai-Xin Duan, Mingming Zhang, Chunying Leng, Ying Liu, Zaifeng Zhang, and Jianping Wu. 2019. An End-to-End, Large-Scale Measurement of DNS-over-Encryption: How Far Have We Come?. In ACM Internet Measurement Conference.
[5] BrightData. 2021. Bright Data (formerly Luminati Network). https://brightdata.com/
[6] Timm Böttger, Felix Cuadrado, Gianni Antichi, Eder Leão Fernandes, Gareth Tyson, Ignacio Castro, and Steve Uhlig. 2019. An Empirical Study of the Cost of DNS-over-HTTPS. In ACM Internet Measurement Conference
[7] Austin Hounsel, Paul Schmitt, Kevin Borgolte, and Nick Feamster. 2021. Can Encrypted DNS Be Fast?. In Passive and Active Measurement Conference
原文链接：
https://dl.acm.org/doi/pdf/10.1145/3487552.3487849
编辑&审校 | 张明明
