@popzuk alidns 的实现和初期不一致了，近几年的实现是每条线路选择一个固定的 ip 带给权威，但是不会携带客户端的 ip 去权威，DNSPod 的 IPv6 ECS 一直用的也是这种方案，选择一条与 ipv6 线路相同的 ipv4 地址带去给权威，而不是客户端的 ipv6 地址。

1. akamai 的权威默认对非对接处理的递归不开启 ecs
2. DNSPod 的公测版 doh.pub 海外使用海外递归，所以会解析到海外。国内的大部分 doh.pub 和 ip 的 doh 对大部分海外国家使用的是国内的递归，少部分国家使用海外递归，会存在不同国家结果不同的情况。
3. 这些可以直接通过对应的测试测试出来。

@docxs 比如
1. 自定义的 DNS Host 是 ns1.a.com,注册局是 verisign ，
2. 如果一个域名 b.com 想把 NS 设置为 ns1.a.com ，就必须先在 verisign 创建 ns1.a.com 这个 host 之后，才能设置，否则会报错无法设置，这里相同 tld 会同时在注册局设置 glue record ip ，并同步到 tld 服务器（如 a.gtld-servers.net 上）
3. 同理如果有另外的 tld 域名，如 c.cn 也向设置 NS 为 ns1.a.com ，cn 的注册局是 CNNIC ，就必须先在 CNNIC 创建 ns1.a.com 这个 host 之后，才能设置，否则会报错无法设置。这里只需要创建 ns1.a.com 这个 host ，而无需设置 glue record ip

2 、3 步在云厂商（注册商）创建自定义 DNS host 的时候都会自动在对接的注册局做好，一般无需用户关注。
但是如果有这个注册商没对接的注册局负责的 tld 域名, 假设 d.xyz, 那么就无法设置 NS 为 ns1.a.com ， 需要 d.xyz 的注册商在注册局代为创建 DNS Host （手动或自动）或者由其他人（如权威 ns1.a.com 的提供者）联系注册局创建

glue record IP 这里，本域名作为 NS -> 或者说本域名相同 TLD 的域名一起生效

这里涉及 2 个问题：
1. 使用本域名作为 NS 的时候，涉及的死循环的问题，必须设置 glue record ip
2. 如果不在对应的注册局创建 Host ，对应的注册局下的 tld 域名是无法设置这个 NS 的，这里只要不是使用本域名作为 NS ，就不是必须设置 glue record ip ，只需要创建 Host

@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 上了