未分類
27 8 月 2020

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

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

資深大佬 : domosekai 20

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

大佬有話說 (9)

  • 資深大佬 : 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