☰

为什么这个 DNS 查找对于我来说失败，但对于其他人来说却有效？

tag-icon • tag-icon domain-name-system
为什么这个 DNS 查找对于我来说失败，但对于其他人来说却有效？

第一天

我必须隐藏实际的主机名，所以我希望仍有足够的信息来回答这个问题......

我正在尝试解析某个主机名（我们假设它是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） 工作正常。
  • 这DNS 跟踪实用程序能够解析主机名，并且它清楚地显示它正在使用对我来说超时的名称服务器之一！

有人能帮我弄清楚发生了什么事吗？

编辑1：万一有帮助，应该发生的事情是，此主机名最终应解析为指向的 CNAME 记录www.example.com.edgesuite.net，而该记录又应解析为其他指向 Akamai 边缘服务器的 CNAME 记录。

编辑2：根据 Joris 的建议，我运行了dig +trace www.example.com，但实际上没有找到结果。它找到了我之前找到的相同权限列表example.com，然后就停在那里了。

缓存似乎是罪魁祸首（我之前确实想到了这一点），但奇怪的是实际的主机名并不那么受欢迎。如果我是第一个请求它的人，它会被缓存在两个不同的 ISP 本地名称服务器上吗？:-)

第二天

好的，我发现了一些事情：

  1. example.com我所知道的两个机构想法超时（与其他三个正在返回的情况相反SERVFAIL）实际上并没有超时。它们只是需要一个更更长超时。例如，如果我使用dig +time=10，那么我最终会得到一个结果。
  2. 我已经在美国各地的几台服务器上尝试过此操作，结果是一样的——使用可以dig www.example.com非常快速地返回结果，但dig @ns1.example.com（或@ns2.example.com）需要使用较大的超时参数。

所以我的新问题是：

  1. 即使结果不是常用的主机名，它真的可以缓存在各种代理 DNS 服务器上吗？TTL 是 54,000（如果我理解正确的话，是 15 小时）。
  2. 如果不是，那么是否有可能以ns1.example.com某种方式配置为向代理 DNS 服务器返回结果的速度比向我自己的查询（某种白名单）返回结果的速度更快dig？或者这只是胡言乱语？

答案1

寻求 DNS 问题帮助时，不要隐藏 DNS 数据。这是毫无意义和愚蠢的，这是一个典型的例子，说明它如何掩盖了你所面临的实际问题。

这里有两种主要的可能性：

  • 您与内容 DNS 服务器的连接时断时续。 此类问题的常见原因是 IP 流量路由问题，或者您与它们之间的跳数过多。找出有问题的 5 个内容 DNS 服务器的 IP 地址，然后使用traceroute或类似方法确定您确实与所有服务器都具有 IP 连接。测试与端口 53 的 UDP/IP 连接，具体来说，如果您的工具能够做到这一点。
  • 答案是在您手动执行操作时未采用的路径之一中提供的，并且您的解析代理 DNS 服务器有时仅采用该路径。 关于 DNS 查询解析的不幸事实是，它可以沿着 DNS 命名空间树走的路径比人们从现有的过程的表面解释中想象的要多得多。例如，第一个CNAME资源记录集（您无法获得）可能被提供，然后由您的解析代理 DNS 服务器在将某些较高级别的内容 DNS 服务器的名称映射到地址时。假设您的解析代理 DNS 服务器有时可以工作，您可以通过查看其查询/响应日志来了解它是如何发现答案的。（某些 DNS 服务器软件必须明确启用此日志记录。有些软件默认启用。如何为您的特定软件执行此操作（您尚未说明），这是另一个问题的范畴。）

请注意，此处发生的唯一缓存是本地的，你的解析代理 DNS 服务器。您查询的内容 DNS 服务器不会缓存。（或者，更严格地说，如果它们缓存，它们会缓存它们正在使用的后端数据库，缓存方式与资源记录 TTL 几乎没有关系，并且不会通过 DNS 协议公开显示。）

还有几种可能性较小且可能性不大，包括您站点上的愚蠢防火墙在 DNS 流量通过时对其进行动态重写。但由于您没有提供正确的数据，因此几乎没有其他方法可以缩小范围并排除您可以从互联网上的随机路人那里获得的可能性。

答案2

为了消除任何错误查询的可能性，您可以尝试 dig +trace example.com 吗？它将为您跟踪该链。如果成功，（它将在每个级别仅尝试其中一个权限），您至少有一个有效的线索。

如果多次尝试均失败，则说明存在问题。您很可能看到“正常”请求的缓存答案；预计问题会在 TTL 到期后立即显现。

答案3

此时，我尝试了 5 个 foo.com 权限中的每一个。

我获得两个授权：

;; AUTHORITY SECTION:
foo.com.        172800  IN  NS  ns.okdirect.com.
foo.com.        172800  IN  NS  ns2.okdirect.com.

两者都正确解析www.foo.com。

答案4

这听起来像是名称服务器上的 ACL 问题。最佳做法是将解析器和权威服务器分开。该域似乎有 2 个权威服务器和 3 个缓存解析器，这些解析器具有限制性 ACL，阻止您对域的查询。您的“但是”案例有效，因为请求是查询而不是要求递归。

在 bind 中您应该指定以下三个选项，否则将应用默认选项，该选项会随着 bind 版本而改变。

允许递归 { none; };
允许查询 { any; };
允许查询缓存 { ournets; };

相关内容