为什么 nslookup 提供 NXDOMAIN 但 dig 工作正常？

Question

我在其他地方没有看到这个问题的确切答案，所以我会勇敢地在这里问。我有一个 linode，并为我的主机设置了 DNS A 记录，我将其称为 A.wc.net。当我在 A.wc.net 上使用 nslookup 查找它时，我得到了这样的答案：

#  running on A.wc.net:  
root@linode (etc ): nslookup A.wc.net
Server:         173.255.243.5
Address:        173.255.243.5#53

** server can't find A.wc.net: NXDOMAIN

但是，在任何其他机器上， nslookup 都会给出正确的结果：

@HomeMac (~ (BARE:master)): nslookup A.wc.net
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   A.wc.net
Address: 173.255.111.911  (number changed for my protection ;-) 

另外，如果我在主机 A.wc.net 上运行 dig：

root@linode (etc ): dig @ns1.linode.com A.wc.net

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns1.linode.com A.wc.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55398
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 10
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;A.wc.net.                IN      A

;; ANSWER SECTION:
A.wc.net. 86400   IN      A       173.255.111.911  (number changed for my protection ;-) 

我的问题是，为什么

nslookup A.wc.net

在主机上运行 A.wc.net 本身唯一找不到正确答案，当在其他主机上运行相同的命令成功时，并且

挖@ns1.linode.com A.wc.net

在主机 A.wc.net 本身失败？

Answer 1

在这个答案中，我做了一个假设：您为域创建了一个新的 A 记录，并立即开始从其他系统进行查询。

让我们看看您在三个示例中的每一个中真正要问的是什么。

示例 1：您要求 nslookup 为 查找 A 记录A.wc.net，但您没有告诉 nslookup 使用什么名称服务器来查找该记录。操作系统有一些默认值 nslookup 告诉您它正在使用位于 173.255.243.5 的名称服务器来尝试查找。该查找失败。

示例 2：您要求另一台计算机上的 nslookupA.wc.net再次查找，而没有告诉 nslookup 使用什么名称服务器。默认情况下，此连接使用 8.8.8.8 的 google DNS。（个人咆哮}谷歌DNS速度很快，但我拒绝向谷歌提供他们需要知道的更多关于我的信息。{/个人咆哮谷歌为你提供了一个答案并告诉你，它也告诉你它不是这个域的权威 DNS——本质上~简单地说~说：这个域名服务器不是这个域的权威，这是给你的答案然而，我的记录可能会被缓存，在该域的权威 DNS 上可能有更新的记录。（完全解释权威/非权威答案等确实超出了您的问题范围，但快速回答是：权威名称服务器是您设置域使用的名称服务器。就当时的 wc.net 而言我正在发布这个答案 wc.net 的名称服务器是UDNS2.ULTRADNS.NET，UDNS1.ULTRADNS.NET如果您告诉 dig 或 nslookup 使用这些服务器中的任何一个进行查询，它们将提供权威答案。

示例 3：您要求 dig 使用名称服务器@ns1.linode.com进行查找A.wc.net，它找到了一条 A 记录并将其提供给您。这次我们获得了一条额外的信息 TTL 或生存时间，它设置为 86400 秒或 24 小时。

这样做的意义在于，处理查询的非权威域名服务器（在所有 3 个示例中，您都使用了 wc.net 的非权威域名服务器）将首先查看自己的缓存，看看它是否已经知道一个未过期的答案对于这个问题，如果出于速度和带宽的原因它会返回它已缓存的答案。24 小时的 TTL 是说~如果这个缓存的记录不到 24 小时，那么它就是答案，否则向上游 DNS 服务器查询更新的记录。~在现代，这个上游查询通常会直接转到权威域名服务器，

结论：对现有 A 记录的更改通常会在接下来的 86400 秒（24 小时）内从全球所有 DNS 服务器可用，如果需要更直接的答案，请查找域的权威服务器并进行 nslookup 或 dig使用其中之一进行查询。（在高级情况下，子域实际上可以拥有自己的~不同于主域~权威名称服务器，同样超出了范围。）

whatsmydns.net是一个工具，您可以使用它来观察传播或您的 DNS 更改在世界范围内发生的速度。与权威答案相比，绿色检查和红色 X 显示了各种 DNS 服务器的答案。请记住，whatsmydns.net 的地图上并没有世界上所有的域名服务器，因此即使所有的绿色支票也可能意味着仍有服务器具有缓存记录。使用此工具，您将更快地发现新记录在互联网上传播或更多，更改的记录可能需要 TTL 秒才能远程查看。我们不得不说“可能”，因为它实际上可能更多或更少，但可能更少。

底线：无需对 A 记录进行额外更改以A.wc.net等待 24 小时的 TTL，然后再次进行查询，届时大多数答案应该是正确的。