dig 返回错误的记录类型

Question

这似乎是我遗漏了一些明显的东西，或者之前已经被问过。当我使用

dig

参数指定 DNS 记录类型查询

-t

时，即使返回的记录是不同的记录类型，结果似乎也包含答案。这是一个例子：

$ dig -t A -q polestar.databaseguy.com.

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> -t A polestar.databaseguy.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33130
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;polestar.databaseguy.com.      IN      A

;; ANSWER SECTION:
polestar.databaseguy.com. 3600  IN      CNAME   databaseguy.ddns.net.
databaseguy.ddns.net.   60      IN      A       173.19.127.251

;; Query time: 30 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Mon Dec 10 14:41:50 STD 2018
;; MSG SIZE  rcvd: 103

CNAME

中列出的

A

和

ANSWER SECTION

记录是正确的。但是，

CNAME

代表

polestar.databaseguy.com.

，

A

代表

databaseguy.ddns.net.

。我查询的

A

没有

polestar.databaseguy.com.

记录，所以我预计不会有结果。

我非常有信心这是正确的行为，但我不理解它，也没有在

man dig

页面中看到任何解释。我也无法在本网站或其他地方找到其他在线讨论。有人可以帮我理解这个吗？

Answer 1

这是预期行为，会减少所需的交换量，并且特定于

CNAME

记录。

它包含在 DNS 核心文档中：RFC1034，第 3.6.2 节

看这个：

CNAME RR 会导致 DNS 软件采取特殊操作。 当名称服务器 未能在与该资源关联的资源集中找到所需的 RR 域名，它检查资源集是否包含 CNAME 记录与匹配的类。 如果是这样，名称服务器包括 响应中记录CNAME并在域名处重新启动查询 在 CNAME 记录的数据字段中指定。 唯一的例外是 此规则是，与 CNAME 类型匹配的查询不会 重新启动。

带有完全符合您的情况的清晰示例：

例如，假设名称服务器正在使用 for 处理查询 USC-ISIC.ARPA，要求提供 A 类信息，并有以下内容 资源记录：

USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

C.ISI.EDU       IN      A       10.0.0.52

这两个 RR 都将在对类型 A 的响应中返回 查询，而 CNAME 或 * 类型的查询应仅返回 CNAME。

其他请参见5.2.2节。 第 6.2.7 和 6.2.8 节也给出了示例。

这还取决于您是否查询递归名称服务器或权威名称服务器。

databaseguy.com

对于名称服务器：

pdns01.domaincontrol.com.
pdns02.domaincontrol.com.

如果您查询其中之一：

$ dig A polestar.databaseguy.com. @pdns01.domaincontrol.com.

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @pdns01.domaincontrol.com.
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64115
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e45ebc418c94c90a
;; QUESTION SECTION:
;polestar.databaseguy.com. IN A

;; QUERY SIZE: 65

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64115
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;polestar.databaseguy.com. IN A

;; ANSWER SECTION:
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.

您仅获得 CNAME 值，因为该权威名称服务器仅知道该值，并且对

ddns.net

不具有权威性。

但是，如果您询问任何递归名称服务器，它会执行递归并给您“完整”答复：

$ for ns in 1.1.1.1 8.8.8.8 9.9.9.9 80.80.80.80 ; do dig A polestar.databaseguy.com. @$ns +noall +ans ; done

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @1.1.1.1 +noall +ans
;; global options: +cmd
;; connection timed out; no servers could be reached

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @8.8.8.8 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 59m59s IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net.   59s IN A 173.19.127.251

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @9.9.9.9 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net.   1m IN A 173.19.127.251

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @80.80.80.80 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net.   1m IN A 173.19.127.251

（

1.1.1.1

没有回复我的询问，但这与这个问题无关）

关于“polestar.databaseguy.com 没有 A 记录，这是我查询的内容，所以我预计不会有结果。”这是错误的，因为该名称有一个 CNAME，这意味着另一个规范名称，而这个规范名称有一个

A

记录，因此到一天结束时，它就像起始名称有一个

A

记录一样。任何在本地向操作系统询问该主机的 IP 地址的应用程序都将获得 A 记录，因为操作系统将负责完整的递归解析并“取消引用”CNAME。

Answer 2

请告诉我是否有关于 NS 记录类型的任何解释。即使我们查询 NS 记录，响应也包含其他可用记录。