iOS14 结合 DNS 的 HTTPS 记录进行 HTTP/3 连接的实测

[domosekai]

前情提要： https://www.v2ex.com/t/699027

上次发现 iOS14 会查询域名的 HTTPS 记录(TYPE65，以前叫 HTTPSSVC)后，本以为只是个试探性功能没多大用，结果今天看到 cloudflare 的贴文，已经完全实用化了。

简单来说，使用 CF 的域名已增加 HTTPS 记录，记录里罗列服务器支持的协议类型（如 HTTP/3，HTTP/2 ），同时提供 IPv4 和 v6 地址，免去查询 A 和 AAAA 记录的必要，使得客户端可以直接用合适的协议连接，不需要先 HTTP 再 fallback 。

原文： https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

不罗嗦，下面是网关上的抓包分析，以 iOS14 设备连接 V2EX 为例（ Safari 要先开启 HTTP/3 支持）：

1 、包 497-499：客户端发出 HTTPS(65),A,AAAA 三种类型的 DNS 查询

2 、包 500：HTTPS 结果返回，由于 wireshark 不支持 decode 65 记录，翻译如下，data 部分共 96 字节：

0000   00 01 00 00 01 00 15 05 68 33 2d 32 39 05 68 33   ........h3-29.h3
0010   2d 32 38 05 68 33 2d 32 37 02 68 32 00 04 00 0c   -28.h3-27.h2....
0020   68 14 09 da 68 14 0a da ac 43 03 bc 00 06 00 30   h..Úh..Ú¬C.¼...0
0030   26 06 47 00 00 10 00 00 00 00 00 00 68 14 09 da   &.G.........h..Ú
0040   26 06 47 00 00 10 00 00 00 00 00 00 68 14 0a da   &.G.........h..Ú
0050   26 06 47 00 00 10 00 00 00 00 00 00 ac 43 03 bc   &.G.........¬C.¼

跳过前三字节，此后每条记录有 4 字节 header，2 字节 key 和 2 字节 length 。

记录 1：00010015，0001 是 alpn，15 是长度，内容是支持的协议：h3-29,h3-28,h3-27,h2 四种，由于 http/3 还在 draft，后面带的是草案版本

记录 2：0004000c，0004 是 ipv4hint，就是 ipv4 地址，省得你去查 A 记录，值当然就是 ip 地址

记录 3：00060030，0006 是 ipv6hint，内容正好是最后 3 行，从 hex 就看得出是三条 v6 地址，2606:4700 开头

3 、包 501,504：Safari 发出 HTTP/3 请求和服务端应答，可以看到是 UDP(QUIC)，没有进一步研究

4 、包 502-503：A 和 AAAA 的应答，在这里已经没用了

另外，目前 Google 、CF DNS 都可以正常返回 HTTPS 记录，dnspod 和 alidns 不支持，114 和百度支持但非常缓慢，可用dig type65 example.com测试。小白注意，HTTPS 记录和 DOH 没有任何关系。

[domosekai]

又想到一点，既然 HTTPS 回答包括了 IP 地址，那么所有基于 DNS 的策略（比如 ipset，比如那些不可描述的分流工具）都将可能暂时失效。即便客户端同时发出 A 和 AAAA，但可能由于时间差，连接请求早于分流发出。

[hallieastem]

本地局域网内有一些 service 的域名解析,在 openwrt 上做的 host,IOS14 设备实际使用应用时都会解析出公网 IP 导致应用无法使用,神烦,网上搜了圈还没人提过这问题,难道都没这种场景的需求的吗?

[tsanie]

alidns 似乎支持了，而且速度不错
```
; <<>> DiG 9.10.6 <<>> type65 v2ex.com @223.5.5.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v2ex.com. IN TYPE65

;; ANSWER SECTION:
v2ex.com. 298 IN TYPE65 \# 96 000100000100150568332D32390568332D32380568332D3237026832 0004000C681409DA68140ADAAC4303BC000600302606470000100000 00000000681409DA26064700001000000000000068140ADA26064700 0010000000000000AC4303BC

;; Query time: 10 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Mon Oct 12 14:20:49 CST 2020
;; MSG SIZE rcvd: 134
```

dnspod 有响应，但 answer 空白。
114 我这里偶尔有比较快速的响应，但是大多数时间 timeout，很奇怪……

[domosekai]

@tsanie ali 其实不是不支持，是对所有 cloudflare 管理的域名有 bug，经常解析不了，这个 bug 很久了。dnspod 不是空白，是 NOTIMP 未部署

[outyua]

@hallieastem 兄弟, 问题解决了吗, 我们也遇到这个问题了, ios14 上, 自定义的 dns 解析不了

[hallieastem]

@outyua 我后来发现涉及到公网有 CNAME，本地局域网则是直接解析 A 记录的域名就有这个问题，只能很麻烦把公网 CNAME 域名都调成 A 记录后暂时恢复可用。这问题已经报给苹果，搞笑的是苹果工程师回信说 IOS14.2beta3 修复了该问题，但我测试后依然存在，不解。

[outyua]

@hallieastem -我使用 coredns 配置了 tls 解析, 可以了

[yyysuo]

@outyua 请问是在上游加一个 dot 的 dns 就可以了吗？您加的是哪一个 dot 的 dns 呢？

[cwbsw]

原来如此。Safari 打不开某些路由器上做了分流的网站的原因破案了。

[i8i]

我在路由器的 DNS 指定 pbs.twimg.com 到 151.101.188.159 。
在 iPhone 上 ping pbs.twimg.com 常常跳到别的 IP，让我路由器那边的分流失效，即使是路由器把所有 port 53 转发都挡掉还是有这个状况。安卓手机没有这个状况。
请问有办法把 iPhone 擅自解析域名的功能关掉吗？

[outyua]

@yyysuo 直接用 coredns 的 tls 插件就行, 配一个证书, 监听 53 端口, 作为 dns 服务, 把客户端的 dns 设置为这台机器的 IP

[wzhpro]

我今天把这个 HTTPS 记录仔细研究了下 ： https://docs.wzh.me/technology/dns-httpstype65-ji-lu