☰

dig 可以解析子域名，但其他工具都无法做到

tag-icon • tag-icon networking dns
dig 可以解析子域名，但其他工具都无法做到

我在我的域名下创建了一个新的 CNAME 并等待了一段时间（大约 1 小时）。

然后我尝试创建一个 letsencrypt 证书并收到 DNS 解析错误，因此我开始自行测试名称解析。

事实证明，dig无论我使用哪个名称服务器，都可以毫无问题地找到 CNAME，但是 nslookup 和 host 却找不到。

例如，下面是我使用时得到的输出1.1.1.1：

root@pre ~ # dig my.subdomain.com @1.1.1.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> my.subdomain.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8098
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;my.subdomain.com.             IN      A

;; ANSWER SECTION:
my.subdomain.com.      113     IN      CNAME   \@.

;; AUTHORITY SECTION:
.                       9382    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2020040300 1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Apr 03 12:37:55 CEST 2020
;; MSG SIZE  rcvd: 136

root@pre ~ # nslookup my.subdomain.com 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

** server can't find my.subdomain.com: NXDOMAIN

root@pre ~ # host my.subdomain.com
Host my.subdomain.com not found: 3(NXDOMAIN)
root@pre ~ # cat /etc/resolv.conf
nameserver 1.1.1.1

一些注意事项：

  1. 存在类似的问题，但我发现这些问题最终要么只比较 dig 和 nslookup，要么查询不同的名称服务器。
  2. 我知道 nslookup 弃用警告，但据我所知，如果 host 和 dig 使用相同的名称服务器，它们应该彼此一致。
  3. 如果我尝试任何其他操作，例如 curl 或 ping，名称解析也会失败。似乎dig只能解决这个问题。
  4. 如果我在其他计算机和网络上运行命令，甚至使用在线工具，也可以观察到相同的行为。Google dig 有效（https://toolbox.googleapps.com/apps/dig/），但 Kloth.net nslookup 没有（http://www.kloth.net/services/nslookup.php）

你能帮助我了解发生了什么事吗？

答案1

不，如果你仔细观察，你会发现 dig 实际上给出了与 host/nslookup 相同的响应。标头显示一模一样NXDomain（“不存在的域”）错误代码。

跟踪 CNAME 记录是递归解析器（本例中为 1.1.1.1）的责任，而不是客户端的责任。由于您查询的是“A”记录，解析器将尝试跟踪整个 CNAME 链，直到到达最终目标，这样它才能真正为您提供所请求的“A”记录。

但在这种情况下，解析器无法做到这一点，因为你的 CNAME指向不存在的目标。解析器是否能找到 CNAME 本身并不重要——那只是部分它的工作，并返回一个 NXDomain 错误，因为它无法解析完整的链。

解析器做过返回一个“答案”部分，其中包含它能够找到的链的一部分——请注意您的 CNAME 目标是@.，这肯定不是一个有效的 TLD。

宏@不是 DNS 网络协议的一部分 – 它只是“区域文件”的一部分配置格式通常用于将 DNS 条目存储在文本文件中。名称服务器在将数据加载到内存中时会将其扩展为真实区域名称，并且客户端永远不应该看到它（就像浏览器永远不应该<?php在网页中看到它一样）。

但是，每个基于 Web 的 DNS 控制面板基本上都发明了自己的配置格式。它们并不总是遵循此类快捷方式，或者仅在“名称”字段中遵循它们，而不在“目标”字段中遵循它们，等等。（还有其他变化；例如，如果目标不是以 结尾，某些控制面板会添加域名后缀，.但其他地方则不以 结尾，以“方便”为名。）

通过手动更改 CNAME 目标subdomain.com.而不是使用 @ 宏来解决此问题。

相关内容