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

[domosekai]

今天发现网关上的 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

[ysc3839]

https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-01

[domosekai]

大概找到原因了，请搜索一份 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 的包确认了无误

[domosekai]

@ysc3839 谢谢，没错，这个是 SVCB/HTTPS 的草案，但里面涵盖的功能很多，这次 apple 要做的我猜只是查询特定域名的 DoH server 是否存在，请参考我上面的回复

[shikkoku]

@domosekai #3 dnspod 的 doh 还没实装到 119 呢。

[domosekai]

@shikkoku 这和 doh 不是一回事，就是 UDP 查询

[johnjiang85]

大概看了下，后面还需要仔细研究下，大概几点吧
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 权威。

[johnjiang85]

@johnjiang85 NOTIME -> NOTIMP

[domosekai]

@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"

[johnjiang85]

@domosekai 嗯，昨晚只看了 draft-ietf-dnsop-svcb-httpssvc-03， 没看 draft-pauly-add-resolver-discovery-01

[GPU]

@domosekai #2 iPhone 抓包有什么可以通过网卡抓的办法吗? 最近在研究 ffapple.com 的原理,但是他是要设置在 Wi-Fi 的代理里去,用 iOS 的抓包软件都抓不到想要的内容,只能抓到一条访问 ffapple.com 测试是否可用的.

[Lentin]

@GPU
就是这个 curl 获取一下就看到了
https://pastebin.com/Ch05zFwD

[GPU]

@Lentin #11 是的，通过 UA 判断，如果是浏览器就会返回一个图片。我回复完过来几天又去试试也发现了。