.NET Framework是否存在独立于操作系统的全局DNS缓存？

首先，我已经尝试了C# DNS相关SO帖子及其他互联网文章中的所有建议，调整ServicePointManager/ServicePoint设置、通过HTTP请求头设置自动关闭连接、修改连接租约时间，但均无效。这些设置似乎都是为解决长运行进程（如Web服务）的DNS问题设计的。进程自带DNS缓存以减少DNS查询或读取操作系统DNS缓存的逻辑确实合理，但不适用于我的场景。

我们的生产基础设施使用高可用（HA）DNS，用于在维护或功能故障时切换服务器节点。架构中多处存在多个CNAME记录指向同一个HA A记录的情况，示例如下：

• eu.site1.myprodserver.com (CNAME) > eu.ha.myprodserver.com (A)
• eu.site2.myprodserver.com (CNAME) > eu.ha.myprodserver.com (A)

所有上述记录的TTL均为60秒，因此当欧洲节点出现故障或进入维护时，A记录会切换为其他节点的IP地址。

我们有一个每5分钟执行一次的监控工具，会同时访问site1和site2。该工具正常运行的前提是两个域名指向同一个数据中心（DC），因为DC间的数据同步速度不足以支撑跨DC访问。由于两个CNAME实际上都绑定了短TTL的同一个A记录，乍看之下不会出现问题，但实际情况并非如此。

该工具基于.NET Framework 4.7.2用C#开发，使用HttpClient类向两个站点发起请求，它又出现了DNS变更不生效的问题。

我们发现当服务器节点切换发生时，该工具经常表现得像site1和site2处于不同DC中。异常场景下的行为模式非常固定，并不是运行过程中出现解析混乱，而是从运行初始就对其中一个或两个域名解析错误。

我开发了一个更简单的工具，仅向site1发送一个GET请求，之后主动切换节点开关并运行该工具，观察哪个DC处理了请求，结果非常令人沮丧。

即使Windows DNS缓存已经更新（通过ipconfig和Get-DnsClientCache命令确认），且所有记录TTL仅为60秒，HttpClient有时仍会在15-20分钟内持续向旧IP地址发送请求。即使我完全关停了“过时”的应用服务器，该工具仍持续尝试连接旧地址，连接失败都无法触发它更新解析结果。

更令人费解的是，如果在两次运行工具间隔执行ipconfig /flushdns，有时刷新后工具能识别到IP变更，但只要你再执行一次flushdns（甚至不需要这步，我还没完全复现规律）再次运行工具，它又会用回旧地址，非常离谱。

还有更奇怪的情况：如果在调用HttpClient之前，在同一个工具内用Dns.GetHostEntry方法（根据相关评论说明，该方法本身也使用缓存）解析域名，得到的结果是正确的，但HttpClient还是会按自己的选择连接IP，看起来HttpClient完全不依赖.NET Framework内置的DNS解析逻辑。

因此我有以下疑问：

1. 新建的.NET Framework进程从哪里获取到这些缓存的DNS结果？
2. 就算真的存在某种神秘的.NET专属全局DNS缓存，为什么它完全忽略TTL设置？
3. 为什么它已经“知晓”地址变更后，还能恢复使用过时的旧IP地址？

附注：我通过自定义HttpClientHandler解决了该问题，自定义Handler会在每个域名首次使用时执行DNS查询，因此不受外部DNS缓存影响（中间DNS服务器的缓存仍会产生一定影响）。但该方案在TLS证书验证方面存在一定复杂度，最终方案不适用于生产环境，不过我们仅用于监控场景，因此可以接受。如果有人感兴趣，我可以提供和相关回答示例类似的类代码。

该工具运行在企业代理之后，实际有多台代理做负载均衡，因此我正在验证以下猜测：

• 如果DNS解析由代理完成，且代理不遵守TTL，或者代理按域名缓存（保持长连接）TCP连接，就能解释所有问题
• 如果工具每次运行时由不同代理处理HTTP请求，就能解释最奇怪的第三个问题

“.NET Framework是否存在独立于操作系统的全局DNS缓存？”这个问题的答案是否。HttpClient类乃至整个.NET Framework都和该问题无关，我已经将调查结果作为采纳答案发布。

内容的提问来源于stack exchange，提问作者Stanislav Bakharev