%20%E4%B8%8D%E8%BF%94%E5%9B%9E%E5%9C%B0%E5%9D%80%EF%BC%8C%E4%BD%86%E2%80%9C%E9%95%BF%E2%80%9D%EF%BC%88ANY%E3%80%81TCP%EF%BC%89%E6%9F%A5%E8%AF%A2%E4%BC%9A%E8%BF%94%E5%9B%9E%E5%9C%B0%E5%9D%80.png)
这是一个伴侣AskUbuntu在我了解足够的知识来提出这个问题之前，我发布了这个问题。
（这是针对 Ubuntu 18.04 的）
通过观察 的调试输出systemd-resolved，我可以执行如下查询：
host foo.mycompany.com
并看到发生的情况是systemd-resolved通过 UDP 查询推迟到我的本地 DNS 服务器（在我的路由器中）。返回的响应说服systemd创建一个NODATA缓存条目。
但是，当我这样做时：
host -a foo.mycompany.com
请求ANY查询时，调试输出清楚地表明 UDP 响应数据包被截断，因此它回退到 TCP 查询。当它返回时，systemd显然会看到一个有效的地址并创建一个积极的缓存条目。
host -a您可以检查链接的问题，但最重要的是，如果我查找域名，它会使某些域名仅工作（一段时间） 。
我不知道是什么可能会导致这种行为。我不认为它与它本身有任何关系systemd-resolved，因为如果我绕过它并直接从我的机器转到路由器 DNS，结果是相同的（尽管我当然看不到调试跟踪）。我不思考我的路由器是问题的一部分，因为一位同事能够看到相同的效果（而且他不在我家）。
答案1
我认为我们已经确定发生的情况是一些中间缓存服务器（例如，我的家庭路由器中的服务器）不愿意返回 RFC1918（“私有”）地址。因此，大多数软件（浏览器等）执行的简短查询将利用这些缓存，但服务器返回相当于“未找到”的内容。因此，本地systemd服务器缓存一个NODATA条目，因为它认为这是正确的做法。
中间服务器不会缓存查询ANY，因此本地服务器会从权威服务器获取响应。
或类似的东西。我暂时不回答这个问题，以防真正知道这些事情如何工作的人可以更好地解释。