遭遇奇怪的 dnspod 对 IPv6 的支持问题
0
所有回答(2)
0
哈哈， 翻了下DNSPod文档，发现好像是解析A和AAAA的规则定义，楼主可以看下这个https://docs.dnspod.cn/dns/line-priority/
和https://cloud.tencent.com/developer/article/1965684
问题可能与在有 AAAA 记录类型的情况下 A 记录类型的泛域名解析优先级发生了变化有关
比如对于 q.cnblogs.com 域名的解析，正常情况下应该是在 q 主机记录 AAAA(IPv6) 解析失败的情况下，进行 q 主机记录的 A (IPv4)解析，在 A 解析也失败的情况下，才使用泛域名主机记录进行 A 解析
q.cnblogs.com -> AAAA(IPv6)
q.cnblogs.com -> A(IPv4)
*.cnblogs.com -> A(IPv4)
出现问题时，在 q 主机记录 AAAA(IPv6) 解析失败的情况下直接进行了泛域名主机记录的 A 解析
q.cnblogs.com -> AAAA(IPv6)
*.cnblogs.com -> A(IPv4)
q.cnblogs.com -> A(IPv4)
或者可能在 q 主机记录 AAAA(IPv6) 解析失败后，进行了泛域名主机记录的 AAAA(IPv6) 解析，解析也失败后，优先进行了 泛域名主机记录的 A(IPv4) 解析
q.cnblogs.com -> AAAA(IPv6)
*.cnblogs.com -> AAAA(IPv6)
*.cnblogs.com -> A(IPv4)
q.cnblogs.com -> A(IPv4)
今天将 DNS 服务切换到阿里云云解析 DNS，也出现了这个问题
不仅有解析到泛域名对应的 IPv4 地址，还会解析到 www 域名对应的 IPv4 地址
0
最终采用了一个变通方法，将泛域名解析的请求转发到 k8s ingress，通过 ingress 转发到各个应用，这样继续解析错了，也不影响用户正常访问
ingress 的配置见 https://q.cnblogs.com/q/142464/
后来采取了更彻底的变通方法，在 www 应用通过反向代理将错误解析的请求转发给正确的应用处理，详见博文 将错就错：DNS 错乱解析造成错误请求，借助 YARP 转发给正确的应用
