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

2020-10-01 14:01:38 +08:00
 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 没有任何关系。

9628 次点击
所在节点    DNS
12 条回复
domosekai
2020-10-01 15:23:47 +08:00
又想到一点,既然 HTTPS 回答包括了 IP 地址,那么所有基于 DNS 的策略(比如 ipset,比如那些不可描述的分流工具)都将可能暂时失效。即便客户端同时发出 A 和 AAAA,但可能由于时间差,连接请求早于分流发出。
hallieastem
2020-10-08 01:29:20 +08:00
本地局域网内有一些 service 的域名解析,在 openwrt 上做的 host,IOS14 设备实际使用应用时都会解析出公网 IP 导致应用无法使用,神烦,网上搜了圈还没人提过这问题,难道都没这种场景的需求的吗?
tsanie
2020-10-12 14:27:03 +08:00
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
2020-10-12 14:38:00 +08:00
@tsanie ali 其实不是不支持,是对所有 cloudflare 管理的域名有 bug,经常解析不了,这个 bug 很久了。dnspod 不是空白,是 NOTIMP 未部署
outyua
2020-10-26 17:57:48 +08:00
@hallieastem 兄弟, 问题解决了吗, 我们也遇到这个问题了, ios14 上, 自定义的 dns 解析不了
hallieastem
2020-10-26 19:42:40 +08:00
@outyua 我后来发现涉及到公网有 CNAME,本地局域网则是直接解析 A 记录的域名就有这个问题,只能很麻烦把公网 CNAME 域名都调成 A 记录后暂时恢复可用。这问题已经报给苹果,搞笑的是苹果工程师回信说 IOS14.2beta3 修复了该问题,但我测试后依然存在,不解。
outyua
2020-11-03 09:50:48 +08:00
@hallieastem -我使用 coredns 配置了 tls 解析, 可以了
yyysuo
2020-11-03 12:53:43 +08:00
@outyua 请问是在上游加一个 dot 的 dns 就可以了吗?您加的是哪一个 dot 的 dns 呢?
cwbsw
2020-11-09 20:52:44 +08:00
原来如此。Safari 打不开某些路由器上做了分流的网站的原因破案了。
i8i
2020-11-19 11:40:53 +08:00
我在路由器的 DNS 指定 pbs.twimg.com 到 151.101.188.159 。
在 iPhone 上 ping pbs.twimg.com 常常跳到别的 IP,让我路由器那边的分流失效,即使是路由器把所有 port 53 转发都挡掉还是有这个状况。安卓手机没有这个状况。
请问有办法把 iPhone 擅自解析域名的功能关掉吗?
outyua
2020-11-25 15:56:18 +08:00
@yyysuo 直接用 coredns 的 tls 插件就行, 配一个证书, 监听 53 端口, 作为 dns 服务, 把客户端的 dns 设置为这台机器的 IP
wzhpro
2023-03-11 22:00:36 +08:00
我今天把这个 HTTPS 记录仔细研究了下 : https://docs.wzh.me/technology/dns-httpstype65-ji-lu

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/712074

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX