¿Por qué no se puede usar un registro CNAME en el vértice (también conocido como raíz) de un dominio?

117

Esta es una pregunta canónica sobre CNAME en los vértices (o raíces) de las zonas

Es de conocimiento relativamente común que los CNAMEregistros en la cúspide de un dominio son una práctica tabú.

Ejemplo: example.com. IN CNAME ithurts.example.net.

En el mejor de los casos, el software de servidor de nombres podría negarse a cargar la configuración y, en el peor de los casos, podría aceptar esta configuración e invalidarla por ejemplo.com.

Recientemente, una empresa de alojamiento web pasó instrucciones a una unidad de negocios que necesitábamos para NOMBRAR el vértice de nuestro dominio a un nuevo registro. Sabiendo que esto sería una configuración suicida cuando se alimenta a BIND, les aconsejé que no podríamos cumplir y que este era un consejo de literas en general. La empresa de alojamiento web tomó la postura de que los RFC que definen estándares no lo prohíben por completo y que su software lo admite. Si no pudiéramos CNAME el vértice, su consejo era no tener ningún registro vértice en absoluto y no proporcionarían un servidor web de redireccionamiento. ...¿Qué?

La mayoría de nosotros sabemos que RFC1912 insiste en eso A CNAME record is not allowed to coexist with any other data., pero seamos honestos con nosotros mismos aquí, que RFC es solo informativo. Lo más cercano que conozco al verborrea que prohíbe la práctica es de RFC1034 :

Si un CNAME RR está presente en un nodo, no deben estar presentes otros datos; Esto asegura que los datos para un nombre canónico y sus alias no pueden ser diferentes.

Desafortunadamente, he estado en la industria el tiempo suficiente para saber que "no debería" no es lo mismo que "no debe", y eso es suficiente para que la mayoría de los diseñadores de software se ahorquen. Sabiendo que cualquier cosa menos que un enlace conciso a una volcada sería una pérdida de tiempo, terminé dejando que la compañía se saliera con la suya por recomendar configuraciones que podrían romper el software comúnmente utilizado sin una divulgación adecuada.

Esto nos lleva a las preguntas y respuestas. Por una vez, me gustaría que seamos realmente técnicos sobre la locura de los CNAME de ápice, y no eludir el problema como lo hacemos normalmente cuando alguien publica sobre el tema. RFC1912 está fuera de los límites, al igual que cualquier otro RFC informativo aplicable aquí que no pensé. Cerremos a este bebé.

Andrew B
fuente
1
RFC 1034 es anterior a RFC 2119 por bastante tiempo y experiencia.
Michael Hampton

Respuestas:

94

CNAMElos registros se crearon originalmente para permitir que se aliasen varios nombres que proporcionan el mismo recurso a un solo "nombre canónico" para el recurso. Con el advenimiento del alojamiento virtual basado en nombres, se ha convertido en algo común usarlos como una forma genérica de alias de direcciones IP. Desafortunadamente, la mayoría de las personas que provienen de un entorno de alojamiento web esperan que los CNAMEregistros indiquen equivalencia en el DNS , que nunca ha sido la intención. El vértice contiene tipos de registro que claramente no se utilizan en la identificación de un recurso de host canónico ( NS, SOA), que no se puede alias sin romper el estándar en un nivel fundamental. (particularmente en lo que respecta a los cortes de zona )

Desafortunadamente, el estándar de DNS original fue escrito antes de que los organismos rectores de estándares se dieran cuenta de que era necesario un lenguaje explícito para definir un comportamiento consistente ( RFC 2119 ). Era necesario crear RFC 2181 para aclarar varios casos de esquina debido a una redacción vaga, y la verborrea actualizada deja en claro que CNAME no se puede utilizar para lograr un alias de ápice sin romper el estándar.

6.1. Autoridad de zona

Los servidores autorizados para una zona se enumeran en los registros NS para el origen de la zona, que, junto con un registro de Inicio de Autoridad (SOA), son los registros obligatorios en cada zona. Dicho servidor tiene autoridad para todos los registros de recursos en una zona que no están en otra zona. Los registros NS que indican un corte de zona son propiedad de la zona secundaria creada, al igual que cualquier otro registro para el origen de esa zona secundaria, o cualquier subdominio de la misma. Un servidor para una zona no debe devolver respuestas autorizadas para consultas relacionadas con nombres en otra zona, que incluye los registros NS y quizás A, en un corte de zona, a menos que también sea un servidor para la otra zona.

Esto establece que SOAy los NSregistros son obligatorios, pero no dice nada acerca de Aotros tipos que aparecen aquí. Puede parecer superfluo citar esto entonces, pero será más relevante en un momento.

RFC 1034 fue algo vago sobre los problemas que pueden surgir cuando CNAMEexiste junto con otros tipos de registros. RFC 2181 elimina la ambigüedad y establece explícitamente los tipos de registros que pueden existir junto a ellos:

10.1 Registros de recursos CNAME

El registro DNS CNAME ("nombre canónico") existe para proporcionar el nombre canónico asociado con un nombre de alias. Puede haber solo un nombre canónico para cada alias. Ese nombre generalmente debería ser un nombre que exista en otras partes del DNS, aunque existen algunas aplicaciones raras para los alias con el nombre canónico que lo acompaña indefinido en el DNS. Un nombre de alias (etiqueta de un registro CNAME) puede, si DNSSEC está en uso, tener SIG, NXT y KEY RR, pero puede no tener otros datos. Es decir, para cualquier etiqueta en el DNS (cualquier nombre de dominio) exactamente uno de los siguientes es verdadero:

  • existe un registro CNAME, opcionalmente acompañado por SIG, NXT y RR KEY,
  • existen uno o más registros, ninguno de ellos registros CNAME,
  • el nombre existe, pero no tiene RR asociados de ningún tipo,
  • el nombre no existe en absoluto.

"nombre de alias" en este contexto se refiere al lado izquierdo del CNAMEregistro. La lista con viñetas deja explícitamente claro que a SOA, NSy los Aregistros no se pueden ver en un nodo donde CNAMEtambién aparece a. Cuando combinamos esto con la sección 6.1, es imposible que un CNAMEexistir en el ápice, ya que tendría que vivir junto obligatoria SOAy NSregistros.

(Esto parece hacer el trabajo, pero si alguien tiene un camino más corto para la prueba, dale una oportunidad).


Actualizar:

Parece que la confusión más reciente proviene de la reciente decisión de Cloudflare de permitir que se defina un registro CNAME ilegal en la cúspide de los dominios, para lo cual sintetizarán registros A. "Cumple con RFC" como se describe en el artículo vinculado se refiere al hecho de que los registros sintetizados por Cloudflare funcionarán bien con DNS. Esto no cambia el hecho de que es un comportamiento completamente personalizado.

En mi opinión, esto es un perjuicio para la comunidad DNS más grande: de hecho, no es un registro CNAME, y engaña a la gente a creer que otro software es deficiente por no permitirlo. (como lo demuestra mi pregunta)

Andrew B
fuente
8
Estoy de acuerdo con esta prueba y no creo que este camino de prueba de dos pasos sea particularmente largo o complicado. (1. se garantiza que el vértice de la zona tiene al menos SOA+ NSregistros, 2. los CNAMEregistros no pueden coexistir con otros datos)
Håkan Lindqvist
2
En general, creo que es una muy buena explicación. Si se pudiera agregar algo, creo que posiblemente explicaría aún más lo que CNAMErealmente significa un registro, ya que ese es probablemente el tipo de registro más incomprendido. A pesar de que eso está más allá del punto, creo que ser una pregunta frecuente es el resultado directo de que muchos (¿la mayoría?) No tienen una comprensión adecuada CNAME.
Håkan Lindqvist
2
OK, es ilegal pero ¿tiene sentido? ¿Por qué un dominio con un CNAME necesita registros NS y SOA? Y si es así, ¿por qué no puede tenerlos?
Denis Howe
2
@Denis Eso no se puede responder de manera exhaustiva en un comentario. La respuesta más breve es que necesita leer los RFC (1034, 1035) y comprender bien qué son las referencias, cuáles son los comportamientos necesarios para una referencia (AUTORIDAD, presencia de registros SOA, etc.) y por qué este tipo de referencias El alias "sin referencias" viola muchas expectativas de los servidores DNS a nivel funcional. Y eso es solo para empezar. Esa pregunta no es un buen tema aquí porque es especulativa y no está enraizada en un problema con el que se encontraría trabajando con un servidor DNS debidamente diseñado y que cumpla con los estándares.
Andrew B
66
@Ekevoo Uno puede argumentar que las implementaciones de HTTP deberían haber adoptado en su SRVlugar, eso también habría hecho que esto no sea un problema. El problema no se limita a lo que se discute aquí; CNAMEes contrario a la creencia popular, no una gran combinación para lo que se necesita. Al final, como CNAMEno funciona como la gente espera (!) Y no se puede rediseñar retroactivamente y como las implementaciones de HTTP no se usan SRV, parece más probable que la funcionalidad de estilo "alias" se vuelva más frecuente para atender a HTTP (tipo de registro específico alias implementado detrás de escena en lugar de como un tipo de registro visible)
Håkan Lindqvist
2

El Consorcio de Sistemas de Internet publicó recientemente una reseña en CNAME en el vértice de una zona , por qué existe esta restricción y una serie de alternativas. No es probable que esto cambie en el corto plazo, lamentablemente:

No podemos cambiar cómo se usa el registro CNAME especial sin cambiar todas las implementaciones de servidores DNS en el mundo al mismo tiempo. Esto se debe a que su significado e interpretación se definieron estrictamente en el protocolo DNS; Todas las implementaciones actuales de cliente y servidor DNS cumplen con esta especificación. Intentar 'relajar' cómo se usa CNAME en servidores autorizados sin cambiar simultáneamente todos los resolvers DNS actualmente en funcionamiento provocará que la resolución de nombre se rompa (y los servicios web y de correo electrónico no estén disponibles de forma intermitente para aquellas organizaciones que implementan soluciones de servidor autoritativo 'relajadas'.

Pero hay esperanza:

Otra posible solución que se está discutiendo actualmente sería agregar un nuevo tipo de registro de recursos dns que los navegadores buscarían, que podría existir en el ápice. Este sería un nombre de host específico de la aplicación para solicitudes http (similar a la forma en que funciona MX).

Pros: Esto es completamente consistente con el diseño de DNS.
Contras: Esto aún no está disponible y requeriría una actualización del cliente del navegador.

Daniel Liuzzi
fuente
2
"Esperanza"? Ya había una "solución", es decir, registros HTTP SRV, pero estos fueron rechazados universalmente. Lo que no está claro es cuál es el "problema".
Michael Hampton
Ni siquiera estaba al tanto de HTTP SRV, así que no tengo idea de por qué fue rechazado. Esperemos que esta nueva solución potencial tenga una mejor recepción cada vez que salga.
Daniel Liuzzi
0

Si está redirigiendo una zona completa, debe usar DNAME. De acuerdo con RFC 6672 ,

El DNAME RR y el CNAME RR [RFC1034] provocan una búsqueda para (potencialmente) devolver datos correspondientes a un nombre de dominio diferente del nombre de dominio consultado. La diferencia entre los dos registros de recursos es que el CNAME RR dirige la búsqueda de datos de su propietario a otro nombre único, mientras que un DNAME RR dirige las búsquedas de datos a los descendientes del nombre de su propietario a los nombres correspondientes en un nodo diferente (único) de el árbol.

Por ejemplo, mire a través de una zona (consulte RFC 1034 [RFC1034], Sección 4.3.2, paso 3) para el nombre de dominio "foo.example.com", y se encuentra un registro de recursos DNAME en "example.com" que indica que todas las consultas en "example.com" se dirijan a "example.net". El proceso de búsqueda volverá al paso 1 con el nuevo nombre de consulta "foo.example.net". Si el nombre de la consulta hubiera sido "www.foo.example.com", el nuevo nombre de la consulta sería "www.foo.example.net".

Brian Minton
fuente
3
Esta es una interpretación incorrecta. Consulte la segunda línea de la tabla en RFC 6672 §2.2 . Un DNAME de ápice no dará lugar a coincidencias para tipos de consulta que no sean DNAME en el vértice, es decir, no dará lugar a un alias real de un registro de ápice A o AAAA.
Andrew B
Un DNAME de ápice no dará como resultado ninguna redirección para consultas del nombre de ápice. No es técnicamente correcto decir que no dará lugar a ninguna coincidencia . Aún obtendrá una coincidencia si consulta NS, SOA o cualquier otro tipo de RR que esté realmente presente para el nombre del vértice. De RFC 6672 : "Si un registro DNAME está presente en el vértice de la zona, todavía es necesario tener allí los registros de recursos SOA y NS habituales. Tal DNAME no puede usarse para reflejar una zona por completo, ya que no reflejar el ápice de la zona ".
Quuxplusone