加快与DNS的HTTPS和HTTP/3协商

6月下旬，Cloudflare的解析器团队注意到，由于我们新的雷达服务暴露的数据，65479资源记录的域名请求激增。我们开始调查，发现这些是苹果iOS14测试版的一部分，在那里他们正在测试一种新的SVCB/HTTPS记录类型。

一旦我们看到苹果要求这种记录类型，而iOS14测试版还在进行中，我们就在整个Cloudflare客户群中推出了支持。

这篇博客文章解释了这种新记录类型的作用及其重要性，但还有一个更深层次的故事：CloudFlare客户自动获得对这样的新协议的支持。

这意味着，今天如果你在运行iOS 14的苹果设备上启用了HTTP/3，当它需要与Cloudflare客户交谈时(比如你浏览受Cloudflare保护的网站，或者使用其API在Cloudflare上的应用程序)，它可以找到自动建立连接的最佳方式。

如果您是Cloudflare的客户，您必须使用…。绝对没什么，…。为苹果用户提供与您的互联网财产的最佳连接。

每当用户在浏览器框中键入URL而没有指定方案(如“https：//”或“http：//”)时，如果没有诸如严格传输安全(HSTS)缓存或预载列表条目之类的先验知识，浏览器就不能假定所请求的网站是否支持HTTPS。浏览器将首先尝试使用明文HTTP获取资源，并且仅当网站重定向到HTTPS URL，或者如果在初始HTTP响应中指定了HSTS策略时，浏览器才会通过安全连接再次获取资源。

这意味着，由于浏览器需要通过TLS重新建立连接并重新请求资源，所以获取初始资源(例如，网站的索引页面)的延迟增加了一倍。但更糟糕的是，初始请求以明文形式泄露给网络，这可能会被路径上的恶意攻击者(想想所有那些不安全的公共WiFi网络)修改，以便将用户重定向到完全不同的网站。实际上，这个弱点有时会被所说的不安全的公共WiFi网络运营商用来将广告偷偷放入人们的浏览器。

不幸的是，这并不是问题的全部。此问题还会影响HTTP/3，它是HTTP协议的最新修订版，可提供更高的性能和安全性。HTTP/3使用Alt-Svc HTTP报头通告，该报头仅在浏览器已使用不同且可能性能较差的HTTP版本联系来源之后返回。浏览器最终在第一次访问网站时错过了使用速度更快的HTTP/3(尽管它确实存储了供以后访问的知识)。

基本问题来自这样一个事实：HTTP相关参数(例如是否可以使用HTTPS或HTTP/3)的协商是通过HTTP本身(通过重定向、HSTS和/或Alt-Svc报头)完成的。这会导致鸡和蛋的问题，其中客户端需要使用最基本的HTTP配置，该配置最有可能成功完成初始请求。在大多数情况下，这意味着使用明文HTTP/1.1。只有在获知参数后，它才能更改以下请求的配置。

但在浏览器可以尝试连接到网站之前，它首先需要通过DNS将网站的域名解析为IP地址。这带来了一个机会：如果除了IP地址之外，还可以通过DNS提供建立连接所需的其他信息，情况会怎样？

这就是我们今天要兴奋地宣布的：CloudFlare已经在我们的EDGE网络上推出了对HTTPS记录的初步支持。CloudFlare的DNS服务器现在将根据特定区域上是否启用了HTTP/3和/或HTTP/2功能，自动动态生成HTTPS记录，以通告特定区域是否支持HTTP/3和/或HTTP/2。

目前由互联网工程任务组(IETF)讨论的新提案定义了一系列可用于协商各种应用协议的参数的DNS资源记录类型(“SVCB”)。

通用DNS记录“SVCB”可以被实例化成特定于不同协议的记录。规范草案定义了一个称为“HTTPS”的实例，该实例特定于HTTP协议，它不仅可以用来通知客户端它可以通过安全连接连接(跳过最初的不安全请求)，而且还可以用来通告网站支持的不同HTTP版本。在未来，可能会有更多的功能被做广告。

上面的DNS记录通告对example.com源的HTTP/3和HTTP/2协议的支持。

这最好与HTTPS上的DNS或TLS上的DNS以及DNSSEC一起使用，以再次防止恶意攻击者篡改记录。

客户端不仅需要获取典型的A和AAAA记录来获取源的IP地址，还需要获取HTTPS记录。当然，它可以并行执行这些查找，以避免连接开始时的额外延迟，但这可能会导致A/AAAA和HTTPS响应彼此不同。例如，在源使用DNS负载均衡的情况下：如果源可以由多个CDN提供服务，则A和/或AAAA记录的响应可能来自一个CDN，而HTTPS记录来自另一个CDN。在某些情况下，这可能会导致连接到源时失败(例如，如果其中一个CDN的HTTPS记录宣传支持HTTP/3，但客户端最终连接到的CDN不支持HTTP/3)。

这由SVCB和HTTPS记录通过直接提供IP地址来解决，而不需要客户端查看A和AAAA记录。这是通过“ipv4hint”和“ipv6hint”参数来实现的，这些参数可以选择性地添加到这些记录中，它们提供了客户端可以使用的IPv4和IPv6地址列表，以代替A和AAAA记录中指定的地址。当然，客户端仍然需要查询A和AAAA记录，以支持没有SVCB或HTTPS记录可用的情况，但是这些IP提示提供了额外的健壮性。

Example.com 3600 in HTTPS 1。Alpn=“h3，h2”ipv4hint=“192.0.2.1”ipv6hint=“2001：DB8：：1”

除此之外，SVCB和HTTPS还可用于定义对服务具有权威性的替代端点，类似于SRV记录：

Example.com 3600 in HTTPS 1 example.net alpn=“h3，h2”example.com 3600 in HTTPS 2 example.org alpn=“H2”

在这种情况下，“example.com”HTTPS服务可以由“example.net”(除了HTTP/1.x还支持HTTP/3和HTTP/2)和“example.org”(只支持HTTP/2和HTTP/1.x)提供。在能够连接之前，客户端将首先需要获取“example.net”或“example.org”的A和AAAA记录，这可能会增加连接等待时间，但是在这种情况下，服务运营商也可以利用上面讨论的IP提示参数，以减少客户端需要执行的所需DNS查找的量。

这意味着SVCB和HTTPS记录可能最终提供了一种方式，使类似SRV的功能可以由流行的浏览器和其他历史上不支持SRV记录的客户端支持。

在Internet上设置网站时，通常使用“www”子域(如“www.cloudflare.com”中的子域)来标识站点，以及该域的“顶点”(或“根”)(在本例中为“cloudflare.com”)。为了避免两个域的DNS配置重复，通常可以将“www”子域配置为CNAME(规范名称)记录，即映射到不同DNS记录的记录。

这样，网站的IP地址列表将不需要全部重复，但是请求“www.cloudflare.com”的A和/或AAAA记录的客户端仍将得到与“cloudflare.com”相同的结果。

然而，在某些情况下，使用CNAME似乎是最好的选择，但最终却微妙地破坏了网站的DNS配置。例如，当使用自定义域设置GitLab Pages、GitHub Pages或Netlify等服务时，通常会要求用户向其域的DNS配置中添加A(有时为AAAA)记录。这些IP地址在用户的配置中是硬编码的，这意味着如果服务提供商决定更改地址(或添加新地址)，即使只是为了提供某种形式的负载平衡，其所有用户也需要手动更改其配置。

使用CNAME到更稳定的域(然后可以拥有变量A和AAAA记录)似乎是一个更好的选择，其中一些提供程序确实支持这一点，但重要的是要注意，这通常只适用于子域(如前一个示例中的“www”)，而不适用于顶点记录。这是因为定义CNAME记录的DNS规范规定，当在特定目标上定义CNAME时，不能有任何其他记录与其关联。这对于子域来说很好，但APEX记录需要定义额外的记录，如SOA和NS，DNS配置才能正常工作，还可能有MX等记录，以确保电子邮件得到正确传递。在实践中，这意味着在域的顶端定义CNAME记录在某些情况下看起来工作得很好，但却以一种不太明显的方式被微妙地打破了。

但这一切与SVCB和HTTPS记录有什么关系呢？事实证明，这些记录也可以解决这个问题，方法是定义一种称为“别名表单”的替代格式，它在所有有用的方面都与CNAME的行为方式相同，但没有恼人的历史包袱。域操作员将能够定义记录，例如：

并期望它能像定义了CNAME一样工作，但没有微妙的副作用。

加密SNI是TLS的扩展，旨在改善Internet上用户的隐私。您可能还记得它如何利用自定义DNS记录来通告客户端使用的服务器公钥共享，然后派生实际加密SNI所需的密钥。在较新版本的规范(现在称为“Encrypted ClientHello”或“ECH”)中，以前使用的自定义TXT记录被称为SVCB和HTTPS记录的新参数“echconfig”简单地替换。

这意味着需要SVCB/HTTPS来支持较新版本的加密SNI/Encrypted ClientHello。今年晚些时候会有更多关于这方面的信息。

这一切听起来都很棒，但对于Cloudflare客户来说，这实际上意味着什么呢？如前所述，我们已经在整个边缘网络中启用了对HTTPS记录的初始支持。CloudFlare的DNS服务器将根据区域上是否启用了HTTP/3和/或HTTP/2功能，动态自动生成HTTPS记录，以通告特定区域是否支持HTTP/3和/或HTTP/2，我们稍后还将添加加密的ClientHello支持。

由于Cloudflare的庞大网络覆盖数百万家网站(我们碰巧是最受欢迎的DNS提供商之一)，代表我们的客户为这些记录提供服务将有助于为使用支持客户端的任何人构建一个更安全、更高性能的互联网。

采用新协议需要多方合作。我们一直在与各种浏览器和客户端合作，以增加对HTTPS记录的支持和采用。在过去的几周里，苹果的iOS14版本已经包含了对HTTPS记录的客户端支持，允许在DNS记录中返回HTTP/3参数时将连接升级到Quic。苹果公司报告说，到目前为止，在iOS14上手动启用HTTP/3的人群中，8%的Quic连接有HTTPS Record响应。

其他浏览器供应商，如Google和Mozilla，也在向他们的用户提供对HTTPS记录的支持，我们希望很快就能听到更多这方面的消息。

HTTPS HTTP3安全性能