挖掘返回错误的记录类型

时间:2018-12-10 20:49:59

标签: dns cname dig a-records

这似乎是我遗漏了一些明显的东西,或者以前曾有人问过。当我使用dig参数查询-t来指定DNS记录类型时,即使返回的记录是其他记录类型,结果也似乎包含答案。这是一个示例:

$ 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中列出的AANSWER SECTION记录是正确的。但是,CNAME用于polestar.databaseguy.com.,而A用于databaseguy.ddns.net.。我查询的是A的{​​{1}}条记录,所以我希望没有结果。

我非常有信心这是正确的行为,但是我听不懂,也没有在polestar.databaseguy.com.页面上看到任何解释。在该站点或其他地方,我也找不到在线其他讨论。有人可以帮我理解吗?

1 个答案:

答案 0 :(得分:1)

这是预期的行为,减少了所需的交换次数,并且是CNAME记录的特定内容。

有关DNS的核心文档:RFC1034,第3.6.2节

看到这个:

  

CNAME RR在DNS软件中引起特殊动作。当名称服务器   无法在与该资源关联的资源集中找到所需的RR   域名,它会检查资源集是否包含CNAME   用匹配的类进行记录。如果是这样,名称服务器将包含   CNAME记录响应中的内容并重新启动域名查询   在CNAME记录的数据字段中指定。一个例外   该规则是与CNAME类型匹配的查询不是   重新启动。

有一个完全符合您情况的清晰示例:

  

例如,假设一个名称服务器正在使用来处理查询   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没有回复我的查询,但这与这个问题无关)

因此,“我没有查询forpolestar.databaseguy.com的记录,因此我希望不会有任何结果。”这是错误的一半,因为该名称具有一个CNAME,这意味着另一个规范名称,并且该规范名称具有一个A记录,因此在一天结束时,就像起始名称具有一个A记录一样。在本地向操作系统要求该主机的IP地址的任何应用程序都将获得A记录,因为操作系统将负责完整的递归解析并“取消引用” CNAME。