NXDOMAIN with CNAME RR in ANSWER section
If I resolve console.aws.amazon.com with dig, I get:
; <<>> 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
However, when resolving us-east-1.console.aws.amazon.com it gets an 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
It looks like, even if we have a NXDOMAIN as response code, it continues to resolve the CNAME. However, according to the RFC (I have seen that in #8020), if there is a NXDOMAIN as response code, it means the domain at the end of the chain does not exist, so we are suppose to continue since we are not going to get any A RR...
I'm a bit confused here why we have a NXDOMAIN in middle of the chain. Is it safe to ignore the NXDOMAIN if we have a CNAME in the ANSWER section and continue to resolve the chain of CNAME?
Is there a RFC that solve this kind of question?
Solution 1:
The CNAME (answer) + SOA (authority) + NXDOMAIN (rcode) type of answer is valid provided that the server actually knows the status of the canonical name (the CNAME "target").
In this case it appears that the nameserver for aws.amazon.com is set up to also have a us-east-1.amazonaws.com zone (the zone where this CNAME leads) where it looks and concludes that the canonical name does not exist. The issue is that this is not the actual us-east-1.amazonaws.com zone that the world uses, the real delegation for us-east-1.amazonaws.com leads to entirely different nameservers.
Looking at the relevant answer (from the question), do note the SOA in the authority section (part of the negative response) and how that is from the "fake" us-east-1.amazonaws.com zone at 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
$
The "real" us-east-1.amazonaws.com is delegated elsewhere entirely (not 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.
and has a completely different SOA:
us-east-1.amazonaws.com. 900 IN SOA dns-external-master.amazon.com. root.amazon.com. 8548 180 60 2592000 5
As for things working relatively well despite this blatant misconfiguration, I believe resolvers simply see through this claimed NXDOMAIN, as resolvers are generally good at only trusting "in bailiwick" data in responses.
Ie, not trusting additional data in a response that makes claims about names belonging to zones that are not actually hosted at that nameserver.