☰

NXDOMAIN con CNAME RR en la sección RESPUESTA

tag-icon • tag-icon domain-name-system
NXDOMAIN con CNAME RR en la sección RESPUESTA

Si resuelvo console.aws.amazon.comcon dig, obtengo:

; <<>> 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

Sin embargo, al resolverlo us-east-1.console.aws.amazon.comobtiene un 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

Parece que, incluso si tenemos un NXDOMAINcódigo de respuesta, continúa resolviendo el CNAME. Sin embargo, según el RFC (lo he visto en el n.° 8020), si hay un NXDOMAINcódigo de respuesta, significa que el dominio al final de la cadena no existe, por lo que se supone que debemos continuar ya que no vamos a obtener cualquier A RR...

Estoy un poco confundido por qué tenemos un punto NXDOMAINen el medio de la cadena. ¿Es seguro ignorar el NXDOMAINsi tenemos un CNAMEen la sección RESPUESTA y continuamos resolviendo la cadena de CNAME?

¿Existe algún RFC que resuelva este tipo de dudas?

Respuesta1

El tipo de respuesta CNAME(respuesta) + SOA(autoridad) + NXDOMAIN(rcode) es válido siempre que el servidor realmente conozca el estado del nombre canónico (el CNAME"objetivo").
En este caso parece que el servidor de nombres aws.amazon.comestá configurado para tener también una us-east-1.amazonaws.comzona (la zona a la que conduce este CNAME) donde busca y concluye que el nombre canónico no existe. El problema es que esta no es la us-east-1.amazonaws.comzona real que usa el mundo, la delegación real us-east-1.amazonaws.comconduce a servidores de nombres completamente diferentes.

Mirando la respuesta relevante (de la pregunta), tenga en cuenta la SOAsección de autoridad (parte de la respuesta negativa) y cómo proviene de la us-east-1.amazonaws.comzona "falsa" en 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

$

Lo "real" us-east-1.amazonaws.comse delega completamente en otra parte (no 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.

y tiene una SOA completamente diferente:

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

En cuanto a que las cosas funcionan relativamente bien a pesar de esta flagrante mala configuración, creo que los resolutores simplemente ven a través de esta afirmación NXDOMAIN, ya que los resolutores generalmente son buenos para confiar solo en datos "in bailiwick" en las respuestas.
Es decir, no confiar en datos adicionales en una respuesta que afirma que nombres pertenecen a zonas que en realidad no están alojadas en ese servidor de nombres.

información relacionada