☰

NXDOMAIN mit CNAME RR im Abschnitt ANTWORT

tag-icon • tag-icon domain-name-system
NXDOMAIN mit CNAME RR im Abschnitt ANTWORT

Wenn ich console.aws.amazon.commit auflöse dig, erhalte ich:

; <<>> 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.comBeim Auflösen erhält man jedoch ein 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

Es sieht so aus, als ob NXDOMAINder CNAME auch dann weiter aufgelöst wird, wenn wir einen Antwortcode haben. Laut RFC (ich habe das in #8020 gesehen) NXDOMAINbedeutet ein Antwortcode jedoch, dass die Domäne am Ende der Kette nicht existiert. Wir müssen also fortfahren, da wir kein A RR erhalten werden ...

Ich bin etwas verwirrt, warum wir ein NXDOMAINin der Mitte der Kette haben. Ist es sicher, das zu ignorieren, NXDOMAINwenn wir ein CNAMEim Abschnitt ANTWORT haben, und mit der Auflösung der CNAME-Kette fortzufahren?

Gibt es ein RFC, das diese Art von Fragen löst?

Antwort1

Die Antwort vom Typ CNAME(Antwort) + SOA(Autorität) + (Rcode) ist gültig, vorausgesetzt, dass der Server den Status des kanonischen Namens (das „Ziel“) tatsächlich kennt. In diesem Fall scheint der Nameserver für so eingerichtet zu sein, dass er auch eine Zone hat (die Zone, zu der dieser CNAME führt), in der er nachsieht und zu dem Schluss kommt, dass der kanonische Name nicht existiert. Das Problem ist, dass dies nicht die tatsächliche Zone ist, die die Welt verwendet, die tatsächliche Delegierung für führt zu völlig anderen Nameservern.NXDOMAINCNAME
aws.amazon.comus-east-1.amazonaws.comus-east-1.amazonaws.comus-east-1.amazonaws.com

Wenn Sie sich die entsprechende Antwort (aus der Frage) ansehen, beachten Sie den SOAAbschnitt „Autorität“ (Teil der negativen Antwort) und dass diese aus der „gefälschten“ us-east-1.amazonaws.comZone stammt unter 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

$

Das „Eigentliche“ us-east-1.amazonaws.comwird ganz woanders hin delegiert (nicht 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.

und hat eine völlig andere SOA:

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

Dass die Dinge trotz dieser offensichtlichen Fehlkonfiguration relativ gut funktionieren, liegt meiner Meinung nach daran, dass Resolver diese Behauptung einfach durchschauen NXDOMAIN, da Resolver im Allgemeinen gut darin sind, nur „in bailiwick“ Daten in Antworten zu vertrauen.
Das heißt, sie vertrauen keinen zusätzlichen Daten in einer Antwort, die Behauptungen über Namen aufstellt, die zu Zonen gehören, die tatsächlich nicht auf diesem Nameserver gehostet werden.

verwandte Informationen