@bclerdx 119 目前的 ecs 缓存并不是完整支持的，是按照省份运营商精度来缓存的，而不是按照 IP 段的精度来缓存的，所以如果对应域名的权威 dns 对鹏博士线路的 IP 应答可能返回其他线路结果时，119 的对应的鹏博士线路的缓存会根据权威对不同 IP 段 ecs 返回结果在不同运营商之间横跳，这个主要还是要看 119 的 IP 库识别，以及域名对应 CDN 权威对鹏博士线路的识别返回结果。

完整 ecs 缓存（即按照 IP 段缓存结果），已经开发测试完成，在灰度的队列里，预计近期可能开始逐步灰度，但是这个功能对网络带宽和缓存成本太高，不会在 119.29.29.29 上放开，只可能会在专业版的公共 dns 和 httpdns 上加白放开，具体策略还没有确定。

@bclerdx 大概看了下，www.163.com 的 cdn 对部分鹏博士的 ip 请求返回的就是一级运营商的节点，部分鹏博士 ip 的请求可以返回网内 ip ，这个要对应的 cdn 去看了
www.jd.com 目前测试了下，倒是暂时没发现问题

@bclerdx 就是缓存过期不淘汰，如果有请求也返回过期的记录，然后异步去尝试重新递归请求，再更新缓存。

刚刚和相关同事修复了一个问题，可以再观察下

114 强烈不建议作为主 dns 使用，但是可以酌情考虑作为备 dns

主要原因：解析准确度差距太大，乐观 dns 会返回甚至数月前已经修改的记录，但稳定性较好

https 记录类型承载的功能比较多，类似传统的 srv 记录的一种扩展，最常见的使用场景是设置服务器支持的 https 协议版本（ h3/h2/h1.1 等）、端口、优先级、兜底 IP 等，如果客户端支持 https 记录类型（ ios14 以上），在某些场景下可以减少一些协议探测协商的过程。

@872517414
@wanacry
> 通常而言，这个问题是路由器的问题，但是我注意到 Google Public DNS 的结果又不太一样。 在路由器上使用 dns.google DoT ，不会显示 ECS 信息，既不支持 ECS 。 而直接向 dns.google DoT 请求数据，会正常显示 ECS 信息。

这取决与公共 DNS 是否会将客户端请求携带的 ecs 0.0.0.0/0 携带到权威进行查询，根据 RFC 7871 ，可以不携带，也可以携带自己的 ecs 信息；
dns.google 没有携带 0.0.0.0/0 到权威，所以不显示；
DNSPod 的公共 DNS 会原样携带 0.0.0.0/0 到权威 DNS ，所以可以显示。

权威对 0.0.0.0/0 的一般处理方式是按照递归 DNS 的出口 IP 进行解析，这与不携带 0.0.0.0/0 完全一致；
部分权威也有可能解析到默认线路，这也是一种正常的处理方式；
两种方式都不会太准确，如果就是不想暴露自己客户端的外网 IP ，而不想要更准确的解析结果，可以传递 0.0.0.0/0 ，如果需要更准确的解析结果，则不能传递 0.0.0.0/0 ，对应的公共 DNS 可能将客户端 IP 作为 ECS 发送到权威 DNS 进行查询。

应该是路由的 dot 配置了禁止 ecs ，携带了 0.0.0.0/0 向 DNSPod 的 dot 请求，需要找下对应配置，选择开启 ecs 。
```
kdig @dot.pub +tls o-o.myaddr.google.com txt +subnet=8.8.8.8/0
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-128-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4866
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; CLIENT-SUBNET: 0.0.0.0/0/24
;; PADDING: 332 B

;; QUESTION SECTION:
;; o-o.myaddr.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.google.com. 180 IN TXT "113.96.17.244"
o-o.myaddr.google.com. 180 IN TXT "edns0-client-subnet 113.96.17.244/0"

;; Received 468 B
;; Time 2022-12-05 22:45:59 CST
;; From 120.53.53.53@853(TCP) in 163.0 ms
```

目前的话如果正确配置，在 ios 上还是会有一定的优化作用，其他地方倒是基本没见过实际使用的。

这个 doh.pub 递归 dns 出口 IP 涉及 2 个问题
1. IP 库，旧版本识别为北京广电，所以递归分配的北京周边的递归，正在灰度更新的 IP 库识别是江苏广电，后续递归的出口 IP 会逐步调度到江苏周边
2. 后端递归的运营商选择问题，即使 IP 库识别为江苏广电，递归会到江苏附近，但是受限于递归节点不足（暂无广电节点），对广电是 3 大运营商的节点都有分配；当然国内其实没什么大影响，权威基本都是支持 ecs 的，对国外域名来说国内 IP 都一样，也没什么大影响。但是从外部测试的感受上来看，确实感受不太好，会想办法看是否能够优化，但是不能给保证。

@InvictusGod 这个域名没有使用 DNSPod 的权威 DNS ，他的权威本身无返回

最好把哪个地区，用的哪个 LDNS 的错误也发下，我分析下

域名发一个我看下

@eason1874 好的，可以临时先使用老版本，dns.pub ，短期内还不会下线，解析准确度上是要高于正式的版本的，容量也是足够的，因为之前的大部分流量已经切到 1.12.12.12 和 120.53.53.53 上了

后期也许会考虑其他的折衷策略，来优化解析速度。

目前的话同时使用 DNSPod 的权威尊享版解析套餐，可以开启解析记录共享到专业版的公共 DNS （包括专业版 DoH/DoT/HttpDNS ）来省略递归过程，请求直接返回。

虽然乐观 DNS 解析确实快，但是相比解析错误，我们认为初次解析延迟个几十 ms 是更可以接受的

@eason1874
两个问题

#1 部分解析失败需要重试的问题，反馈是公测环境切换到正式环境的 1.12.12.12 和 120.53.53.53 之后，正式环境高负载导致的，上周四、五有部分调整来优化，但是后期还是需要扩容来解决。

#2 解析慢于 ali 的 doh 的原因主要是阿里的公共 DNS 使用了乐观 DNS 缓存，即使缓存中记录 TTL 过期也会返回过期的记录，然后再去重新递归请求。
DNSPod 的公共 DNS 未使用乐观 DNS 缓存策略，如果请求时缓存已过期不会返回给客户端，需要重新递归进行返回；如果请求时缓存记录的 TTL 已经过去了 75%，会将缓存中的记录返回给客户端，同时对该域名进行递归提前预取。
两种策略的优略很明显，乐观 DNS 响应快，但是经常出现解析记录迟迟无法更新的问题，可以见本社区的多个相关帖子反馈。
非乐观 DNS 则相反，两种策略如何选择就是见仁见智，看实际需求选择。
乐观 DNS 缓存策略内部讨论多次，目前暂时没有支持，后续是否支持及时间不确定。

doh.pub 目前国内除了东北之外，其他地区已经都是指向 120.53.53.53 和 1.12.12.12 ，是同一套。
dot.pub 国内已经全量切到 120.53.53.53 和 1.12.12.12 。
已经反馈相关同学，后面看下

目前 dns.pub 还指向老的公测系统，可以使用 https://dns.pub/dns-query 来对比下。但是后期 dns.pub 会仅作为官网域名使用，doh 和 dot 等功能后期会下线。

楼主应该是想在域名注册里修改 NS 地址，但是在解析里看到的 @的 NS 记录不可修改。

域名注册控制台可以正常修改域名的 NS 地址。

域名解析里 @的 NS 记录，控制台上不可以修改，仅支持 API 修改，实在太多自行改掉解析里 @的 NS 记录导致无法解析的问题，API 修改是提高修改门槛，至少要一定的了解才可以改动 @的 NS 记录。