我遇到了一个问题，我无法用我对“事物如何运作”的有限理解来解释。我连接到各种服务器（我将以此svn.mycompany.com为例）进行工作。我们openvpn通常与这些服务器建立安全连接。公司已设置 OpenDNS 来为服务器提供普通解析，而生成的地址当然只能通过已建立的 VPN 隧道工作。
在对一些服务器进行了一些无害的重新配置之后（不是我做的，显然对其他人都有效），我注意到以下模式。我有一个 VPN 隧道，我尝试了一个svn命令：
svn update
我立即收到错误消息，表示主机svn.mycompany.com无法解析。如果我进行查找host：
host -a svn.mycompany.com
它会以正确的 IP 地址做出响应。如果我再次尝试该svn命令，它会工作，并且svn会持续工作一段时间。然而，在一段未测量的时间段之后，它又停止工作，并重复这个循环。
隧道另一侧的其他服务器也存在同样的情况。我在不同的网络中都看到过这种情况（例如，在我家、在咖啡店等）。
我并不是在寻找一个整体解决方案。我真正的问题是，仅仅运行如何host -a至少暂时“修复”域名无法解析的情况？是否host做了一些特殊的事情来绕过本地缓存？（如果是这样，我仍然感到困惑，因为服务器的地址不会改变，或者很少改变。）
编辑— 好的，更多信息。通过打开 的日志记录systemd-resolved，我能够使用它journalctl来跟踪我的本地计算机对 DNS 查找的操作。我看到的内容似乎很有趣，但我仍然不太了解它的含义：查询类型的 DNS 查找请求ANY似乎溢出了 UDP 数据包大小，因此systemd-resolved会退回到进行 TCP 查询。对于ANY这些foo.mycompany.com名称的正常非查找，我没有得到数据包溢出，但它会继续进行NODATA本地缓存条目。
当ANY查询强制 TCP 回退时，systemd-resolved会获得有用的结果并产生积极的缓存条目。
对我来说，这意味着 UDP 响应发生了一些奇怪的事情，但我不知道这暗示了什么根本原因。