@Love4Taylor
理论上来说也不能算是格式错误，应该说是格式兼容性问题，如下的 NSEC 位图表中的__01 01 00___ ，目前第二段只支持设置 CAA 记录，当请求 CAA 记录时，会将 CAA 记录的位图置为 0 ，此时第二段位图已经没有有效类型，但是并没有将第二段位图整体去掉，依然保留了，opendns 兼容此格式，bind 和 google 会认为是错误格式，已经修改完毕，从免费套餐灰度中。
```
$ dig +dnssec caa iks.moe @ns3.dnsv2.com
;; Got bad packet: FORMERR
353 bytes
cd d8 85 00 00 01 00 00 00 04 00 01 03 69 6b 73 .............iks
03 6d 6f 65 00 01 01 00 01 c0 0c 00 06 00 01 00 .moe............
00 00 b4 00 3e 03 6e 73 33 05 64 6e 73 76 32 03 ....>.ns3.dnsv2.
63 6f 6d 00 0e 6c 65 76 65 6c 33 64 6e 73 61 64 com..level3dnsad
6d 69 6e 06 64 6e 73 70 6f 64 03 63 6f 6d 00 62 min.dnspod.com.b
75 35 17 00 00 0e 10 00 00 00 b4 00 12 75 00 00 u5...........u..
00 00 b4 c0 0c 00 2e 00 01 00 00 00 b4 00 5b 00 ..............[.
06 0d 02 00 00 00 b4 62 7f 82 41 62 6d 0d 41 bb .......b..Abm.A.
e8 03 69 6b 73 03 6d 6f 65 00 e3 58 dd ff 4f be ..iks.moe..X..O.
89 3e 3c e6 12 16 b6 03 00 06 92 2d 98 b2 56 b7 .><........-..V.
8d cd a9 41 8a aa e2 af 43 19 2c ef d8 2b 0f 6c ...A....C.,..+.l
6b 93 79 e5 fa cb 6e 55 d7 c3 9f 4c 94 9f f7 48 k.y...nU...L...H
45 ee e9 e7 0d 44 6b 29 27 d3 c0 0c 00 2f 00 01 E....Dk)'..../..
00 00 00 b4 00 19 01 00 03 69 6b 73 03 6d 6f 65 .........iks.moe
00 00 09 62 01 80 08 40 03 80 00 c0 __01 01 00___ c0 ...b...@........
0c 00 2e 00 01 00 00 00 b4 00 5b 00 2f 0d 02 00 ..........[./...
00 00 b4 62 83 f2 37 62 71 7d 37 bb e8 03 69 6b ...b..7bq}7...ik
73 03 6d 6f 65 00 f7 2e cf 8c de f1 a5 b7 22 43 s.moe........."C
6d b8 0d 1f e9 ba 5e 1b 4d ee a9 cc a3 19 5d 0b m.....^.M.....].
59 57 90 7c 43 c5 b5 d3 29 41 b7 49 82 c0 fd 81 YW.|C...)A.I....
fe f1 1e 12 e4 8a 23 5f 20 e9 86 68 01 02 1f a2 ......#_...h....
4d 22 d9 7b ec fa 00 00 29 10 00 00 00 00 00 00 M".{....).......
00
```

确认没有对未设置 CAA 记录时的 dnssec 请求应答做格式的正确处理，可以先临时随意添加一条 CAA 记录规避，下周 5 前上线完成无 CAA dnssec 失败的问题。

CAA 记录示例：
0 iodef "mailto:[email protected]"

收到，稍后排查后回复

@bclerdx 可以看下 ECS 的 RFC 或者 Google 的开发者文档，返回 scope mask 为 0 表示匹配后续所有网段过来的请求，即任何 IP 过来请求都可以直接应答，就相当于没有设置分线路解析。

doh 国内已经切换了大部分，dot 暂时还没有，这几天吧。海外切换还没有具体时间。

DNSPod 的解析准确性主要靠 ECS 来保证，不能保证分配的后端递归出口 IP 与用户运营商一致。

国内目前 top 网站几乎很少有不支持 ECS 的，所以依然可以准确解析，可以不关注这个结果。海外域名的权威很多需要白名单开启 ECS ，但是开了也解析不到国内，使用哪个运营商基本无影响。

@loukky 可以解决。但是只是顺带的，毕竟这不是 dot.pub 的问题，是京东权威的问题。

当某个海外的 IP 先请求了该域名，且返回了海外的结果之后，如果返回的 scope mask 为 0 ，即作为全局缓存，那么后面其他的任意 Ip 再请求也都会拿到海外的结果，权威的错误返回如下所示（。-> .)。

dig @ns1 。jdcache 。com www 。jd 。com +subnet=8 。8 。8 。8

; <<>> DiG 9 。10 。6 <<>> @ns1 。jdcache 。com www 。jd 。com +subnet=8 。8 。8 。8
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50719
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 8 。8 。8 。8/32/0
;; QUESTION SECTION:
;www 。jd 。com 。 IN A

;; ANSWER SECTION:
www 。jd 。com 。 120 IN CNAME www 。jd 。com 。gslb 。qianxun 。com 。
www 。jd 。com 。gslb 。qianxun 。com 。60 IN CNAME jd-abroad 。cdn20 。com 。

;; Query time: 137 msec
;; SERVER: 111 。13 。28 。10#53(111 。13 。28 。10)
;; WHEN: Sat Mar 26 21:05:49 CST 2022
;; MSG SIZE rcvd: 119

京东的权威 DNS 对 ECS 的只是不完整或不同服务器数据不一致，可以看以下返回，有时候可以返回非 0 的 scope mask ，有时候返回 0 的 scope mask ，0 表示不支持 ecs 或者没有分线路解析，解析结果将按照全局缓存。

dig @ns1.jdcache.com www.jd.com +subnet=119.6.6.6

; <<>> DiG 9.10.6 <<>> @ns1.jdcache.com www.jd.com +subnet=119.6.6.6
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59784
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 119.6.6.6/32/24
;; QUESTION SECTION:
;www.jd.com. IN A

;; ANSWER SECTION:
www.jd.com. 120 IN CNAME www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 60 IN CNAME www.jdcdn.com.
www.jdcdn.com. 720 IN CNAME img20.360buyimg.com.s.galileo.jcloud-cdn.com.

;; Query time: 114 msec
;; SERVER: 111.13.28.10#53(111.13.28.10)
;; WHEN: Sat Mar 26 21:00:02 CST 2022
;; MSG SIZE rcvd: 168

dig @ns1.jdcache.com www.jd.com +subnet=119.6.6.6

; <<>> DiG 9.10.6 <<>> @ns1.jdcache.com www.jd.com +subnet=119.6.6.6
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45079
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 119.6.6.6/32/0
;; QUESTION SECTION:
;www.jd.com. IN A

;; ANSWER SECTION:
www.jd.com. 120 IN CNAME www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com. 60 IN CNAME www.jdcdn.com.
www.jdcdn.com. 720 IN CNAME img20.360buyimg.com.s.galileo.jcloud-cdn.com.

;; Query time: 124 msec
;; SERVER: 111.13.28.10#53(111.13.28.10)
;; WHEN: Sat Mar 26 21:00:11 CST 2022
;; MSG SIZE rcvd: 168

正式环境的 120.53.53.53 和 1.12.12.12 将增加一层缓存，谷内到省级运营商，国外到国家级，对于普通域名不会再按照网段缓存结果，即同时受 dot.pub 和权威的 IP 库准确度影响。
海外的切换会晚一些时间，未切换前还是完全以权威返回为准，按照网段缓存结果，完全依赖于权威的 IP 库准确度，如果权威的 IP 库不准，那就会解析错误。
国内目前的权威 DNS IP 库准确度比较高的是我们 DNSPod 和 51dns ，部分对比结果可以参照公众号“老高的互联网杂谈”

DNSPod 目前的 DoT 解析结果完全以权威返回结果为准，国内下周将切换到正式环境

@Love4Taylor 相关功能的 API 是有的，但是前端控制台的排期目前不确定

@Love4Taylor 我问下产品

@v2tudnew 这个最低 ttl 限制是 60 秒

@kenvix 其实是 119.29.29.29 这个 ip 被攻击的频率太高，所以不能再继续复用这个 IP 了

@jmk92 公测的 doh.pub 和 dot.pub 指向的 IP 后续会逐步灰度迁移到 120.53.53.53 和 1.12.12.12 这两个 IP ，不会一次性切过去，全部切过去后，老 IP 的公测 doh 和 dot 就会下掉了

花生壳早期支持，后面的 DNS 就大多支持了

@jmk92 没计划，http 可以使用 HttpDNS ，支持不加密，轻量级对称加密（ DES 和 AES ）

其实之前已经有了，还没宣传，先猜猜或者自己找找吧

@loukky 正常的
他的权威不支持 ecs ，带 ecs 没用的，只看是国内还是国外的递归 dns 访问的，如果从海外访问 dot.pub 只能解析到海外节点