☰

ANSWER 部分中帶有 CNAME RR 的 NXDOMAIN

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

如果我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 中看到過），如果有一個NXDOMAINas 響應代碼，則意味著鏈末尾的域不存在，因此我們應該繼續，因為我們不打算獲得任何 A RR...

我有點困惑為什麼我們NXDOMAIN在鏈條中間有一個。NXDOMAIN如果我們在 ANSWER 部分中有 aCNAME並繼續解析 CNAME 鏈，是否可以安全地忽略它？

有沒有 RFC 可以解決這類問題？

答案1

如果伺服器實際上知道規範名稱（「目標」）的狀態，則（答案CNAME）+ SOA（權威）+ （rcode）類型的答案是有效的。 在這種情況下，名稱伺服器似乎也設定了一個區域（此 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，因為解析器通常擅長僅信任響應中的“轄區內”數據。
即，不信任回應中的附加數據，這些數據聲明屬於實際上並未託管在該名稱伺服器上的區域的名稱。

相關內容