我有一台机器运行Ubuntu 10.04服务器。 当使用curl和wget等工具连接局域网之外的某些站点时，我已经开始漫长（5-10秒）的延迟。
使用tcpdump和wireshark，我发现问题是在DNS查询中，正在build立连接：
例
当我运行：
wget www.site1.com
我看到以下行为：
LOOKUP: AAAA www.site1.com # => fail, no delay, site1 doesn't have an IPv6 AAAA record LOOKUP: AAAA www.site1.com.mydomain.lan # => fail, BIG DELAY, crazy domain doesn't exist LOOKUP: A www.site1.com # => success, no delay, resolves as expected (site1 has IPv4 A record) CONNECTION PROCEEDS ...
我的设置
我的服务器的resolv.conf如下所示：
nameserver 192.168.0.1 # my router domain mydomain.lan # made up domain name, for my lan search mydomain.lan
我的服务器的主机文件如下所示：
127.0.0.1 localhost.localdomain localhost 192.168.0.10 server1.mydomain.lan server1 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
决议？
为什么我的resolv.confsearch列表被用于构build第二次查找的名称，当resolv.conf手册页build议仅在查找主机名（无点）时使用它：
“parsing器查询中有less于ndots点（默认为1），将依次尝试使用searchpath的每个组件，直到find匹配。
我的印象是，第二次查找是错误的，不应该被执行…
如果我从resolv.conf中删除了domain和search行，那么第二次查找就不会再执行了，我的延迟就会消失。
（另外，如果我强迫wget只处理IPv4，AAAA查找没有完成，所以延迟消失）：
wget --inet4-only www.site1.com
此行为是devise使然。
IPv6是首选 – 所以首先确定AAAA条款中资源的状态。 NXDOMAIN响应返回 – 所以客户端需要附加searchpath。
请注意，你所做的ndots评论是正确的，但不是全部。 如果ndots数大于被查询的名称（如果是单个标签名称，在这种情况下），与查询行为唯一的区别是带有后缀的查询将在尝试原始名称之前发生。 既然你已经超过了ndots门槛，那么就按照规定先试试这个名字。 请参阅手册页中的更多内容：
n的缺省值是1，这意味着如果名称中有任何点，则在将任何search列表元素附加到名称之前，名称将首先作为绝对名称尝试。
该查询失败，所以必须使用search列表。 请注意查询行为与wget http://site1/的区别。
你所看到的是预期的行为 – 我认为你需要解决的是造成这种缓慢查找的因素的汇合。
NXDOMAIN 。 由于closuresIPv6修复它，您可能有一个DNS服务器的path，当涉及到AAAA查找时，无法caching的caching。 尝试改变你的parsing器到8.8.8.8来validation。 search设置必须具有的用途，因为它不是公共层级中的有效名称），它将立即作出响应。 你可能不需要这个searchconfiguration，但是将其设置为可以parsing的东西，这样它就不会尝试从机器的主机名猜测它。 search com应该做得很好。 如果在shell提示符下，你说$ hostname并取回foo.bar.baz ，那么DNSparsing器就知道你的主机名是foo而你的域名是bar.baz 。 一般情况下，/etc/resolv.conf中的“domain”和“search”行只有在不正确的情况下才会使用（或者如果你打算引起exception的行为）。
如果你的域名真的是bar.baz ，那么很可能你不应该在/etc/resolv.conf中指定“domain”或“search”这两行。 与其他地方经常出现的情况相反，在/etc/resolv.conf中通过重新指定已经从hostname获得的信息，通常会产生奇怪和不希望的行为（包括愚蠢的超时）。 在大型商业和小型家庭环境中都是如此。
（注意：每个应用程序都可能有不同的解释/etc/resolv.conf，所以理论上这可能不是普遍适用的。在大多数现代系统上，虽然99％的parsing器请求都通过GLIBC，但实际上，以上几乎总是如此。）