¿En DNS puede un IN NS apuntar a un CNAME?

17

¿Está permitido que un registro NS sea un CNAME? P.ej:

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Esto no parece funcionar en enlace aunque esto (por supuesto) sí:

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Se agradecería cualquier puntero a RFC que prohíba esta configuración.

domain-name-system cname-record ns-record Mark Wagner
fuente

Respuestas:

20

El RFC real que define el NS RR ( RFC1035 ) simplemente dice que es un nombre de dominio sin especificar el tipo de RR del objetivo (aunque deja en claro que no puede ser una IP). Sin embargo, recibe una mención específica en RFC1912 , sección 2.4:

Tener registros NS que apuntan a un CNAME es malo y puede entrar en conflicto con los servidores BIND actuales. De hecho, las implementaciones actuales de BIND ignorarán dichos registros, posiblemente conduciendo a una delegación poco convincente. Hay una cierta cantidad de verificación de seguridad realizada en BIND para evitar la suplantación de registros DNS NS. Además, según se informa, los servidores BIND más antiguos quedarán atrapados en un bucle de consulta infinito al tratar de averiguar la dirección del servidor de nombres con alias, lo que provocará el envío continuo de solicitudes DNS.

No del todo DEBE NO, pero sin duda se ajusta al comportamiento que estás viendo

jj33
fuente
55
Y RFC1034 dice: "Los nombres de dominio en RR que apuntan a otro nombre siempre deben apuntar al nombre principal y no al alias. Esto evita indirecciones adicionales en el acceso a la información ... Por supuesto, por el principio de robustez, el software de dominio no debe fallar cuando se presenta con cadenas o bucles CNAME; las cadenas CNAME deben seguirse y los bucles CNAME deben señalarse como un error ".
larsks
10
Descubrí que RFC 2181 10.3 dice claramente que no es válido, pero su respuesta fue lo suficientemente buena.
Mark Wagner
1
Para mayor claridad: la MUST NOTverborrea no importa aquí porque RFC 1912 es informativo y no define un estándar. Mark tiene razón en que RFC 2181 es la referencia correcta. (RFC 1034 fue escrito antes de que los estándares del idioma se solidificaran, de ahí la vaguedad)
Andrew B