☰

NXDOMAIN 和 ANSWER 部分中的 CNAME RR

tag-icon • tag-icon domain-name-system
NXDOMAIN 和 ANSWER 部分中的 CNAME RR

如果我console.aws.amazon.com使用解决dig，我会得到：

; <<>> DiG 9.10.6 <<>> console.aws.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35338
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;console.aws.amazon.com.        IN  A

;; ANSWER SECTION:
console.aws.amazon.com. 4   IN  CNAME   lbr-optimized.console-l.amazonaws.com.
lbr-optimized.console-l.amazonaws.com. 4 IN CNAME us-east-1.console.aws.amazon.com.
us-east-1.console.aws.amazon.com. 4 IN  CNAME   gr.console-geo.us-east-1.amazonaws.com.
gr.console-geo.us-east-1.amazonaws.com. 4 IN CNAME console.us-east-1.amazonaws.com.
console.us-east-1.amazonaws.com. 59 IN  A   54.239.30.25

然而，解析时us-east-1.console.aws.amazon.com得到NXDOMAIN：

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33652
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; ANSWER SECTION:
us-east-1.console.aws.amazon.com. 60 IN CNAME   gr.console-geo.us-east-1.amazonaws.com.

;; AUTHORITY SECTION:
us-east-1.amazonaws.com. 60 IN  SOA ns-912.amazon.com. root.amazon.com. 1609664924 3600 900 7776000 60

;; Received 147 bytes from 52.9.146.37#53(ns-912.amazon.com) in 270 ms

看起来，即使我们有一个NXDOMAINas 响应代码，它也会继续解析 CNAME。但是，根据 RFC（我在 #8020 中看到过），如果有 as 响应代码NXDOMAIN，则意味着链末尾的域不存在，因此我们应该继续，因为我们不会得到任何 A RR...

我有点困惑，为什么NXDOMAIN链中间会有 。NXDOMAIN如果我们在 ANSWER 部分有 ，那么忽略CNAME并继续解析 CNAME 链是否安全？

是否有一个 RFC 可以解决此类问题？

答案1

如果服务器确实知道规范名称（“目标”）的状态，则 (answer) + (authority) + (rcode) 类型的答案是有效的。在CNAME这种SOA情况 下，名称服务器似乎也设置了一个区域（此 CNAME 指向的区域），它在该区域查找并得出结论，规范名称不存在。问题是，这不是世界使用的实际区域，真正的委托指向完全不同的名称服务器。NXDOMAINCNAME
aws.amazon.comus-east-1.amazonaws.comus-east-1.amazonaws.comus-east-1.amazonaws.com

查看相关答案（来自问题），请注意SOA权威部分（负面回应的一部分）以及它是如何来自“假”us-east-1.amazonaws.com区域的ns-912.amazon.com：

$ dig @ns-912.amazon.com us-east-1.console.aws.amazon.com +norec

; <<>> DiG 9.11.25-RedHat-9.11.25-2.fc33 <<>> @ns-912.amazon.com us-east-1.console.aws.amazon.com +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19359
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;us-east-1.console.aws.amazon.com. IN   A

;; ANSWER SECTION:
us-east-1.console.aws.amazon.com. 60 IN CNAME   gr.console-geo.us-east-1.amazonaws.com.

;; AUTHORITY SECTION:
us-east-1.amazonaws.com. 60     IN      SOA     ns-912.amazon.com. root.amazon.com. 1609723312 3600 900 7776000 60

;; Query time: 152 msec
;; SERVER: 52.9.146.37#53(52.9.146.37)
;; WHEN: Mon Jan 04 01:21:54 UTC 2021
;; MSG SIZE  rcvd: 147

$

“真实”us-east-1.amazonaws.com完全被委托在其他地方（不是ns-912.amazon.com）：

us-east-1.amazonaws.com. 86400  IN      NS      ns2.p31.dynect.net.
us-east-1.amazonaws.com. 86400  IN      NS      ns4.p31.dynect.net.
us-east-1.amazonaws.com. 86400  IN      NS      pdns5.ultradns.info.
us-east-1.amazonaws.com. 86400  IN      NS      pdns3.ultradns.org.
us-east-1.amazonaws.com. 86400  IN      NS      ns1.p31.dynect.net.
us-east-1.amazonaws.com. 86400  IN      NS      ns3.p31.dynect.net.
us-east-1.amazonaws.com. 86400  IN      NS      pdns1.ultradns.net.
us-east-1.amazonaws.com. 86400  IN      NS      u2.amazonaws.com.
us-east-1.amazonaws.com. 86400  IN      NS      u6.amazonaws.com.
us-east-1.amazonaws.com. 86400  IN      NS      u3.amazonaws.com.
us-east-1.amazonaws.com. 86400  IN      NS      u5.amazonaws.com.
us-east-1.amazonaws.com. 86400  IN      NS      u1.amazonaws.com.
us-east-1.amazonaws.com. 86400  IN      NS      u4.amazonaws.com.

并具有完全不同的 SOA：

us-east-1.amazonaws.com. 900    IN      SOA     dns-external-master.amazon.com. root.amazon.com. 8548 180 60 2592000 5

至于尽管存在这种明显的配置错误，但一切运行得相对良好，我相信解析器只是看穿了这种声称NXDOMAIN，因为解析器通常只信任响应中的“管辖范围内”数据。
即，不信任响应中的其他数据，这些数据声称名称属于实际上未托管在该名称服务器上的区域。

相关内容