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