iOS 14 开始查询 HTTPS 记录 (type 65)

今天发现网关上的 dnsmasq 出现许多没见过的 type 65 查询(HTTPS BINDING)，查下来是 iOS14 的 iPhone 发出。

试着 dig 了一下，目前功能和 CNAME 差不多，国内 114 、百度、阿里都支持，我的联通也支持，但是 dnspod 不支持！！！

这个以后有什么用？还请知道的大佬说说？附 dig 记录

cloudflare

; <<>> DiG 9.16.3 <<>> TYPE65 su.itunes.apple.com @1.1.1.1 +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5808
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;su.itunes.apple.com.           IN      TYPE65

;; ANSWER SECTION:
su.itunes.apple.com.    3323    IN      CNAME   su-cdn.itunes-apple.com.akadns.net.
su-cdn.itunes-apple.com.akadns.net. 3323 IN CNAME su-applak.itunes-apple.com.akadns.net.
su-applak.itunes-apple.com.akadns.net. 23 IN CNAME su.itunes.apple.com.edgekey.net.
su.itunes.apple.com.edgekey.net. 23 IN  CNAME   e673.dsce9.akamaiedge.net.

alidns

; <<>> DiG 9.16.3 <<>> TYPE65 su.itunes.apple.com @223.5.5.5 +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48522
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;su.itunes.apple.com.           IN      TYPE65

;; ANSWER SECTION:
su.itunes.apple.com.    60      IN      CNAME   su-cdn.itunes-apple.com.akadns.net.
su-cdn.itunes-apple.com.akadns.net. 60 IN CNAME su-china.itunes-apple.com.akadns.net.
su-china.itunes-apple.com.akadns.net. 60 IN CNAME su.itunes.apple.com.mwcname.com.

dnspod 失败

; <<>> DiG 9.16.3 <<>> TYPE65 su.itunes.apple.com @119.29.29.29 +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 62775
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;su.itunes.apple.com.           IN      TYPE65

domosekai

2020-08-17 19:27:02 +08:00

大概找到原因了，请搜索一份 apple 领衔的 IETF draft，draft-pauly-add-resolver-discovery-01
简要而言，通过查询某域名的 SVCB/HTTPS 记录，可以获取这个域名的专用 DoH server，如果存在的话关于此域名的所有 DNS 请求将发给制定的 DoH 进行，这给域名拥有者指定 nameserver 提供了可能
附录 A 提到，支持 SVCB/HTTPS 查询的客户端的做法是，同时发送 A/AAAA/HTTPS 三种类型的查询给 DNS，如果有 DoH 记录则采用，这个同时发的行为我也通过抓 iPhone 的包确认了无误

johnjiang85

2020-08-18 00:41:09 +08:00

大概看了下，后面还需要仔细研究下，大概几点吧
1. 该草案和 DoH/DoT 本身没有必然关联，只是可以通过 DoH/DoT 进行 SVCB/HTTPSSVC 的 DNS 请求来 “To realize the greatest privacy benefits”
2. 主要还是解决 HTTPS 访问 WEB 服务器的相关问题，涉及内容比较多，如之前 HTTPS 相关的 HSTS/Alt-Svc, DNS 相关的 SRV 记录、非标服务端口、CNAME 与其他记录冲突等等
3. 119 返回 NOTIME 目前看影响不大，但是后续会评估是否以及何时支持 SVCB/HTTPSSVC 记录，包括 119 和 DNSPod 权威。

domosekai

2020-08-18 00:52:41 +08:00

@johnjiang85 感谢大佬回复。目前确实无实际影响，我也没有发现哪个 apple 的域名部署了 65 记录。另外，不是通过 DoH/DoT 进行 SVCB 请求来保障隐私。我的理解是，该请求完全可以通过 UDP 进行，这个草案的逻辑是，既然 TLS 的握手包要加密（无论 ESNI 或者 ECH ），那么 DNS 自然也不能通过公共服务器，所以要有个办法来指定域名专属的 DoH，从而保证"clients would only resolve names with the same entity that would service TLS connections"