我发现 223.5.5.5 开始拒绝解析 TXT 记录了

[Tianao]

这可能会令使用 223.5.5.5 作为递归上游的收件服务器的 SPF 验证不能如期工作。

可以使用如下命令测试：
macOS: dig -t txt apple.com @223.5.5.5
PowerShell: Resolve-DnsName -type txt apple.com -server 223.5.5.5
Windows CMD: nslookup -qt=txt apple.com 223.5.5.5

作为对比，119.29.29.29 和 114.114.114.114 返回了不完整的少量 TXT 记录（强制 UDP ）； 1.1.1.1 使用了 RFC 顺从的 EDNS UDP payload size 字段遵从和 TCP mode 并返回了完整的全部 TXT 记录。

[mytsing520]

阿里云公共 DNS 团队回复：已知问题，近期安排修复。

[allenby]

@laminux29 #8 说的对

[yulgang]

我现在在 coreDNS 上配置 8.8.8.8 、 8.8.4.4 、1.1.1.1 、1.0.0.1 、9.9.9.9 、149.112.112.112 这几个 dns 的 DoT 轮着换，感觉还行。没用 DoT 之前遇到过好几次查询的记录和实际不符的情况。

[Miary]

@Aicnal 我也是这个组合，但是偶尔会非常卡，影响体验。

[Aicnal]

@Miary 如果求稳定还是得用运营商的 DNS ，不过我目前还没有出现什么问题，建议检查一下是不是 AD 误杀

[gentrydeng]

> 非常抱歉，给您使用带来不便。目前阿里公共 DNS 出于安全等角度考虑，限制了最大的 DNS 回复报文长度，apple.com 域名下 TXT 记录过多，超过了最大长度限制，所以导致其 TXT 类型无法解析。后续我们会考虑针对这种场景进行优化，比如返回一部分应答记录，不过目前还没有明确的上线时间。

[yyysuo]

@gentrydeng #26 用 tcp 请求有没有这个限制？

[K8dcnPEZ6V8b8Z6]

@yulgang 国内场景吗？这样感觉延迟会很高

[lxcopenwrt]

主要是阿里 DNS 用 TCP 或者 DoH 查询都直接返回 SERVFAIL 明显是有问题的，测试了一圈国内的公共 DNS 只有 360 能正常返回 apple.com 的全部 TXT 记录（直接 UDP 返回全部数据未返回 TC flag 指示客户端使用 TCP 重试），里面最奇葩的是百度返回了 TC flag 但他家不支持 TCP 查询就一直卡在那里，国外的基本都正常但包括谷歌在内的很多公共 DNS 也是像 360 这样处理不太符合规范

[yulgang]

@K8dcnPEZ6V8b8Z6 平时上网感觉不到明显延迟，做 nslookup 的时候会卡几秒，总体感觉可以。

[bclerdx]

TXT 记录是做什么用的。