Tianao

@CharonVIII #2 我测试下来，是 Windows 上的 nslookup 实现在通过 UDP 收到 Truncated 置位的应答、转而使用 TCP 并完成 TCP 的 3-way 握手后，会紧接着（也就是在这个 TCP 连接的第 4 个包）发送一个带有 PSH 置位的、仅有 2 bytes 的 TCP payload 的 TCP segment, 我不知道这个 2-byte 载荷的意义是什么（但猜测是用作一个什么出于性能或可用性目的的什么前导？），然后紧接着就收到了来自 223.5.5.5 的 TCP RST (我也不知道 223.5.5.5 为什么要 reset, 但是我猜测是 223.5.5.5 收到了这个不明所以的 TCP 分段，出于节省资源开销/防攻击的目的主动 reset 掉了这个 TCP 连接)，然而按照 Windows nslookup 的预期（这一「预期」我使用了其他使用 Windows nslookup 可以正常解析的 DNS 服务器进行了验证），这第 5 个包本应是来自服务端的正常 ACK, 然后 nslookup 再紧接着发送可以和第 4 个包进行 TCP segment reassemble 从而组成一个完整 DNS 请求的 TCP 分段，但是此时 TCP 连接已经被 223.5.5.5 给 reset 掉了。

目前的判断：Windows 的 nslookup 实现和 223.5.5.5 的某些策略性表现在 TCP 解析时存在兼容性问题。

目前的建议：在 Windows 上，在 PowerShell 中使用 Resolve-DnsName 能够获得比 nslookup 更接近 Windows DNS 客户端真实表现的测试结果。换言之，在 Windows 上，仅是 nslookup 失败不代表浏览器等真实用户访问行为调用的 DNS 解析也会失败。

「照理说 A 记录太多的网站肯定不止这一家...」
对于一般 web 服务的 GSLB, 国内一般都是地理+运营商分区解析，每个分区最终的 A/AAAA 记录真的远没这么多；对于国际化服务，虽然会使用 anycast, 但是 ADNS 会控制每次返回给 recursive DNS 的权威结果数量，也不会一次性返回好几十个 anycast 地址的 A 记录。