Kubuntu（Ubuntu 14.04.2 LTS，内核 3.13.0-48-generic）于 2 个月前安装（尚未安装最新更新）。
我注意到我的解析器出现故障：
root@arrakis:~# telnet onet.pl
telnet: could not resolve onet.pl/telnet: No address associated with hostname
root@arrakis:~# ssh onet.pl
ssh: Could not resolve hostname onet.pl: No address associated with hostname
strace并wireshark确认我发送了两个 DNS 查询：A 和 AAAA，并收到了两个答案 - 正确的 A 和空的 AAAA。收到第二个响应后，应用程序 ( telnet/ ssh) 立即发送该解析错误。
使用 google dns (8.8.8.8) 时一切正常 - 但使用我公司的 DNS 时则不然。
好的，进行了额外的故障排除并测试了谷歌（8.8.8.8）并与我的公司 DNS 进行了比较，结果如下：输入时，telnet www.onet.pl我的本地解析器始终发送 A 和 AAAA 记录的 DNS 查询，并且始终得到两个答案。此外，挖掘两个 DNS 服务器返回类似结果（A IN 记录和空的 AAAA IN 记录）。但工作（谷歌 DNS）与非工作（公司 DNS）场景的区别是：标记递归：谷歌可以进行递归，而我的公司 DNS 服务器不能。这是唯一的区别。为什么我的本地解析器不想接受禁用递归的响应（当已经提供 IN A 地址时）？
从用户角度的工作场景（google DNS）：
root@arrakis:/tmp# telnet onet.pl 80
Trying 213.180.141.140...
Connected to onet.pl.
Escape character is '^]'.
非工作场景（公司 DNS）：
root@arrakis:/tmp# telnet onet.pl 80
telnet: could not resolve onet.pl/80: No address associated with hostname
附上两种场景的屏幕截图。
我认为唯一合理的解释是：如果我在查询中写到“需要递归”，而在响应中我看到它不受支持 - 那么我会放弃该响应？有人能证实吗？这有点疯狂，因为我发送的所有 DNS 查询都有“需要递归”......（根据我对 rfc1035 的理解，这是不正确的行为，我们应该接受响应）
工作和非工作场景之间还有一个小区别。对于工作（谷歌 DNS），响应仅包含带有 IP 地址的 IN。对于非工作（公司 DNS），响应包括相同的以及另外多个额外的权威服务器。我想这是正常的，因为它是来自非递归服务器的响应，只是前面提到的差异的结果。我们确实额外包含了一个 IN 记录，这可能有点奇怪（如果我们确实返回了一个 IN 记录，可能是因为它之前被缓存了，所以不需要返回额外的权威记录）但我相信仍然应该可以接受。
需要确认的是，A 的 DNS 响应始终在答案部分返回正确的条目：
root@arrakis:/tmp# dig @8.8.8.8 www.onet.pl -t A | grep "213"
www.onet.pl. 15 IN A 213.180.141.140
root@arrakis:/tmp# dig @173.38.200.100 www.onet.pl -t A | grep "213"
www.onet.pl. 60 IN A 213.180.141.140
对于相同的请求，但是“-t AAAA”，我们没有答案部分。只有权限。
我目前正在使用一种非常好的解决方法。我的笔记本电脑上有绑定服务器，启用了递归，转发器指向谷歌和公司 DNS。并通过我的绑定传递所有流量。一切都运行良好 - 正如预期的那样。
总结一下：在我看来，Linux 中存在错误的行为。