我必须隐藏实际的主机名，所以我希望有足够的信息来回答这个问题。
我试图解决某个主机名（让我们假装它是www.example.com ，但这不是实际的主机名）。 一个简单的dig请求的作品，但是当我尝试从根域名服务器开始一系列的dig ，我打了一个死胡同。 这是一个例子：
# Starting with arbitrarily-chosen root nameserver $ dig @198.41.0.4 www.example.com (returns the usual list of TLD .com nameservers) # Using a.gtld-servers.net $ dig @192.5.6.30 www.example.com (returns a list of 5 example.com authorities)
在这一点上，我尝试了5个example.com权威。 其中三个失败，状态SERVFAIL ，剩下的两个时间。 这是一个SERVFAIL示例：
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33577 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.example.com. IN A ;; Query time: 74 msec ;; SERVER: <intentionally removed> ;; WHEN: Tue Mar 8 10:10:33 2011 ;; MSG SIZE rcvd: 37
我多次尝试过，从我自己的机器在家里，从我们的远程机器，这两台机器始终得到相同的结果。
然而，
dig www.example.com （没有指定@server ）工作正常。 有人能帮我弄清楚发生了什么事吗？
编辑1：万一它有帮助， 应该发生的是，这个主机名应该最终parsing为指向www.example.com.edgesuite.net的CNAMElogging，该logging又应该parsing为指向Akamai边缘服务器的另一个 CNAMElogging。
编辑2：按照Joris的build议，我运行dig +trace www.example.com ，但实际上却找不到结果。 它到达我之前find的example.com权威机构的同一个列表，并停在那里。
caching看起来像是一个很可能的罪魁祸首（而且我早就想到了这一点），但奇怪的是，实际的主机名不是那么受欢迎。 如果我是第一个请求它，它会被caching在两个不同的ISP本地域名服务器上吗？ 🙂
好的，我发现了一些事情：
example.com权威机构是超时的（与另外三个正在返回SERVFAIL ）实际上并没有超时。 他们只需要更长的超时时间。 如果我使用dig +time=10 ，那么我最终会得到一个结果。 dig www.example.com快速返回结果，但是可以dig @ns1.example.com （或@ns2.example.com ）需要使用大的超时参数。 所以我的新问题是：
ns1.example.comconfiguration为更快地返回代理DNS服务器的结果比我自己的dig查询（某种白名单）？ 或者这只是疯狂的谈话？ 在请求DNS问题帮助时，请勿掩盖您的DNS数据 。 这是毫无意义和愚蠢的，这是一个典型的例子，它是如何掩盖了你的实际问题。
这里有两个主要的可能性：
traceroute或其他来确定你是否确实有IP连接。 testing端口53的UDP / IP连接性，具体来说，如果您的工具是可胜任的。 CNAME资源logging集（无法获取），然后由parsing代理DNS服务器caching。 考虑到您的parsing代理DNS服务器有时可以工作，您可以通过查看其查询/响应日志来了解它是如何发现答案的。 （有些DNS服务器软件必须显式地打开这个日志logging，有些默认情况下会启用它，但是你没有说明的特定软件怎么做是一个单独的问题。 请注意，这里发生的唯一caching是本地的，在您的parsing代理DNS服务器上。 您正在查询的内容DNS服务器不会caching。 （或者更确切地说，如果他们做了caching，他们就会caching他们正在工作的后端数据库，而这些数据库与资源loggingTTL几乎没有任何关系，并且不能通过DNS协议公开显示。 ）
还有一些小的和相当不太可能的可能性，包括在你的站点上的DNS防火墙在通过它们时重写DNSstream量。 但是，由于您没有提供正确的数据，因此缩小范围并排除从互联网上的随机路由器获得的可能性还有一点点。
为了消除任何错误查询的机会，你可以尝试dig + trace example.com吗？ 它会跟着你的链条。 如果成功的话，（只会尝试每一级的权威），至less有一条工作路线。
如果多次尝试都失败了，就会有一些事情发生。 机会是你看到与“正常”的请求caching的答案; 预计TTL到期时会发生破损。
在这一点上，我尝试了5个foo.com权威机构。
我得到两个权威：
;; AUTHORITY SECTION: foo.com. 172800 IN NS ns.okdirect.com. foo.com. 172800 IN NS ns2.okdirect.com.
正确解决www.foo.com 。
您是否更改了域的授权名称服务器的数量？ 在您查询的级别，这些都是在注册商级别处理的。 如果你以前看到过5，现在看到2，我不得不猜测你对授权名称服务器条目进行了更改。
下一次尝试一个简单的telnet到授权名称服务器的端口53
这听起来像名称服务器上的ACL问题。 最好的做法是将parsing器和权威服务器分开。 该域听起来有2个权威服务器和三个cachingparsing器，限制性ACL阻止您的域的查询。 由于请求是查询而不是要求recursion，你的“然而”情况是有效的。
在绑定中，您应该具有以下三个指定的选项，或者应用默认值，并且已经使用绑定版本进行了更改。
allow-recursion {none; };
allow-query {any; };
allow-query-cache {ournets; };
我刚刚发现了一个类似的问题的解决scheme：
在Windows Server 2003上注册的Debian服务器没有正确parsing。 有时我可以通过主机名到达服务器，有时候不能。
问题是Linux机器的ipv6地址。 禁用ipv6解决了这个问题。
问题是你没有使用正确的查询。 你必须向TLD的根服务器询问NS（例如dig @ROOT-NS com. ），然后询问你的域的TLD（例如dig @TLD-NS example.com ），然后向NS请求example.com关于www.example.com（例如dig @eaxmple.com-NS-IP www.example.com ）
编辑：这是一个完整的例子：
dig -t NS . # Find the root NS using local resolver dig -t NS @f.root-servers.net com. dig -t NS @a.gtld-servers.net example.com dig -t A @ns.example.com www.example.com