很多第三方的公共 DNS （或者某些教育网）都有 ipv6 地址，可以使用 ipv6 地址访问，另外递归 DNS 的后端既有 ipv4 也有 ipv6 ，可以向相关的授权 DNS 发起请求，并不需要授权 DNS 必须有 ipv6 地址，所以还是可以解析出来 AAAA 地址。

但是在国内的话非常不建议使用 ipv6 ，用了 ipv6 就不能使用智能解析（分线路）了，跨运营商和跨地区访问就是常态了。我们的授权 DNS 原本是有 ipv6 地址的，但是不能上线，会影响正常的智能解析（比如说在教育网里）。

相关协议中有 RTT 延时选择机制及算法，开源的 BIND 和 UNBOUND 也曾经使用过，但是目前这两个开源的更多的是使用随机选择 IP 的方式，而不是根据 RTT 延时机制去较大概率选择质量好的 IP ，较小概率选择质量差的 IP 。质量差的 IP （即使是完全无应答的 IP ）也会去选择是因为网络总是在变化的，有可能之前较差的慢慢变好，根据算法会调整每个 IP 的选择到的概率， BIND 和 UNBOUND 中的 RTT 延时算法是按照 RFC 实现的，但是在实际的使用中， DNS 选优效果并不好。 DNSPod 的 119.29.29.29 的后端递归也使用了 RTT 延时机制，基本思想参照 RFC 的思想，但是算法经过了优化，可以测试不同 IP 的质量，并线性调整各 IP 的权重。

第二个问题差不多，会随机去选择一个或多个 NS 的一个或多个 IP 去重试，根据递归的不同，选择也会有所不同，重试时同样会有第一个问题了选择哪个 IP 的问题。

方便提供几个域名吗，我们测试下

算是一个思路，不过实际情况可能更复杂， CNAME 很多时候还是用在 CDN 上的，线路太多了。

@hqfzone 理论上 NS 记录和 CNAME 记录确实是冲突的，但是在实际使用中还没有发现相关的影响解析的 CASE 。
CDN 厂商提供的域名上设置 MX 记录当然是可行的，也是完全符合协议的，但是除非是大客户，不然 CDN 厂商不会支持的。因为每支持一个客户，需要单独分配一套完全独立的 CNAME 解析链，并同步修改调度。

@johnjiang85 最后一句是“不返回 IP ” -> “不返回 CNAME ”

cloud flare 可以进行递归查询根上的 CNAME 记录并返回最终的 A 记录，但是我们认为在 DNS 攻击频繁的网络环境中，该功能会严重影响 DNS 的解析性能，目前在 DNSPod 上是不支持去递归查询的。只有当 CNAME 指向的记录能够在 DNSPod 直接解析出 A 记录时，会直接返回 A 记录，不返回 IP 。

@kang000feng [email protected],有问题可以发到这里

也测试下 tcp 方式是否能够正常返回

@kang000feng 能麻烦提供下出口 IP 地址吗，以及能作下 dig 的测试结果（或者 nslookup 设置 set debug ）

出现这种情况很明显是该域名出现了某种问题，而不是 DNSPod 解析的问题，最好详细排查下

@cszhiyue 没找客服看吗，发下域名看下

我们看看调整下方案，有进展再回复。

目前 119.29.29.29 的 tcp 查询请求确实是走了转发的，通过 bgp 出口转发到了单独的服务器，没有区分各运营商的 IP ，导致解析到了默认。

标准协议有 DNSSEC ，但是递归不支持的话没用

@openbaby 这个 IP 是个 BGP IP ，不过实测 DNSPod 授权上是识别为浙江联通线路的。这里是说的 Public DNS 识别成电信了？

@snsd 是的，解析出来是联通的地址

@LengthMin sorry ，昨天已经可以了，但是忘了回复了