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


Esto es un Pregunta canónica sobre los CNAMEs en los vértices (o raíces) de las zonas

Es relativamente común que CNAME Los registros en el vértice de un dominio son una práctica tabú.

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

En el mejor de los casos, el software del servidor de nombres podría rehusarse a cargar la configuración, y en el peor de los casos, podría aceptar esta configuración e invalidar la configuración de example.com.

Hace poco, una empresa de alojamiento web pasó las instrucciones a una unidad de negocios que necesitábamos para NOMBRAR el ápice de nuestro dominio a un nuevo registro. Sabiendo que esta sería una configuración suicida cuando se la enviaran a BIND, les dije que no podríamos cumplir y que este era un consejo de literas en general. La empresa de alojamiento web adoptó la postura de que no está totalmente prohibido por las RFC de definición estándar y que su El software lo soporta. Si no pudiéramos CNAME el ápice, su consejo era no tener ningún registro de apex en absoluto y no proporcionarían un servidor web de redireccionamiento. ...¿Qué?

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

Si un CNAME RR está presente en un nodo, ningún otro dato debe ser   presente; Esto asegura que los datos para un nombre canónico y sus alias   no puede ser diferente

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

Esto nos lleva a las preguntas y respuestas. Por una vez me gustaría que consiguiéramos De Verdad técnico acerca de la locura de los CNAME del ápice, y no esquivar el tema como solemos hacer 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é. Vamos a cerrar a este bebé.


107
2017-07-19 10:53


origen


RFC 1034 es anterior a RFC 2119 por bastante tiempo y experiencia. - Michael Hampton♦


Respuestas:


CNAME los registros fueron originalmente creado para permitir que varios nombres que proporcionan el mismo recurso se aliasen a un solo "nombre canónico" para el recurso. Con la llegada del alojamiento virtual basado en nombres, se ha convertido en un lugar común para 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 CNAME registros para indicar equivalencia en el DNS, que nunca ha sido la intención. El vértice contiene tipos de registro que son claramente no utilizado en la identificación de un recurso host canónico (NS, SOA), que no puede ser alias sin romper el estándar en un nivel fundamental. (particularmente en lo que respecta a cortes de zona)

Desafortunadamente, el estándar de DNS original se redactó antes de que los organismos reguladores de los estándares se dieran cuenta de que era necesario un lenguaje explícito para definir un comportamiento coherente (RFC 2119). Fue necesario crear. RFC 2181 para aclarar varios casos de esquina debido a una redacción vaga, y la palabrería actualizada aclara que una CNAME  no poder ser utilizado para lograr el alias apex 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 Inicio de Autoridad      (SOA) registro son los registros obligatorios en cada zona.  Tal servidor      es autoritario 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 los      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 un      zona no debe devolver respuestas autorizadas para consultas relacionadas con      nombres en otra zona, que incluye los registros NS, y tal vez A,      en un corte de zona, a menos que también sea un servidor para el otro      zona.

Esto establece que SOA y NS Los registros son obligatorios, pero no dice nada. A u otros tipos que aparecen aquí. Puede parecer superfluo que cite esto entonces, pero se volverá más relevante en un momento.

RFC 1034 Fue un tanto vago acerca de los problemas que pueden surgir cuando una CNAME Existe junto a otros tipos de registro. RFC 2181 elimina la ambigüedad e indica explícitamente los tipos de registro 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 a un nombre de alias. Puede haber solo uno      dicho nombre canónico para cualquier alias. Ese nombre debe ser generalmente      un nombre que existe en otras partes del DNS, aunque hay algunos raros      Solicitudes de alias con el nombre canónico adjunto.      indefinido en el DNS. Un nombre de alias (etiqueta de un registro CNAME) puede,      Si DNSSEC está en uso, tenga SIG, NXT y RR CLAVE, pero puede que no tenga      otros datos  Es decir, para cualquier etiqueta en el DNS (cualquier nombre de dominio)      exactamente uno de los siguientes es cierto:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

"nombre de alias" en este contexto se refiere al lado izquierdo de la CNAME grabar. La lista con viñetas deja explícitamente claro que un SOA, NSy A los registros no se pueden ver en un nodo donde una CNAME También aparece. Cuando combinamos esto con la sección 6.1, es imposible para un CNAME Para existir en el vértice, ya que tendría que vivir junto a obligatorio SOA y NS archivos.

(Esto parece hacer el trabajo, pero si alguien tiene un camino más corto para probar, por favor, inténtelo).


Actualizar:

Parece que la confusión más reciente viene de Reciente decisión de Cloudflare para permitir que un registro ilegal de CNAME se defina en el vértice de los dominios, para lo cual sintetizarán los 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 de DNS más grande: de hecho, no es un registro CNAME, y confunde a la gente para que crea que otro software es deficiente por no permitirlo. (como demuestra mi pregunta)


85
2017-07-19 10:53



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 la zona del ápice tiene al menos SOA + NS registros, 2. CNAME Los registros no pueden coexistir con otros datos) - Håkan Lindqvist
En general, creo que es una muy buena explicación. Si se pudiera agregar algo, creo que posiblemente sería una explicación más detallada de lo que CNAME grabar en realidad significa, ya que es probablemente el tipo de registro más incomprendido. A pesar de que eso va 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 de CNAME. - Håkan Lindqvist
@Denis Eso no se puede responder de manera integral en un comentario. La respuesta más corta es que necesita leer los RFC (1034, 1035) y tener una buena comprensión de qué son las referencias, cuáles son los comportamientos requeridos para una referencia (AUTORIDAD, presencia de registros SOA, etc.) y por qué este tipo de el alias "sin referencia" 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á arraigada en un problema con el que se encontraría trabajando con un servidor DNS que cumpla con los estándares y que esté diseñado correctamente. - Andrew B
@DenisHowe en breve: no existe tal cosa como "un dominio" sin los registros NS y SOA. Esos son los registros no opcionales. - hakamadare
@Ekevoo One puede argumentar que las implementaciones HTTP deberían haber sido adoptadas SRV en su lugar, eso también habría hecho que esto no fuera un problema. El problema no se limita a lo que se discute aquí; CNAME Es, contrariamente a la creencia popular, no es un gran complemento para lo que se necesita. Al final, como CNAME no funciona como la gente espera (!) y no se puede rediseñar de forma retroactiva y las implementaciones HTTP no se utilizan SRV parece más probable que la funcionalidad del estilo de "alias" sea más frecuente para atender a HTTP (el aliasing específico del tipo de registro implementado detrás de la escena en lugar de un tipo de registro visible) - Håkan Lindqvist


Si está redireccionando una zona completa, debe usar DNAME. De acuerdo a RFC 6672,

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

Por ejemplo, mire a través de una zona (vea RFC 1034 [RFC1034],      Sección 4.3.2, paso 3) para el nombre de dominio "foo.example.com", y una      El registro de recursos de DNAME se encuentra en "example.com" indicando que todos      las consultas en "example.com" se deben dirigir a "example.net". La busqueda      El proceso volverá al paso 1 con el nuevo nombre de consulta de      "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".


0
2018-03-27 15:41



Esta es una interpretación incorrecta. Consulte la segunda línea de la tabla en RFC 6672 §2.2. Un DNAME de vértice no resultará en ninguna coincidencia para tipos de consulta distintos de DNAME en el vértice, es decir, no da como resultado un alias real de un registro de ápice A o AAAA. - Andrew B
Un apodo DNAME resultará en no redirección Para consultas del nombre del vértice. No es técnicamente correcto decir que no resultará en ningún partido. Seguirá obteniendo una coincidencia si consulta NS, SOA o cualquier otro tipo de RR que en realidad sea presente por el nombre del vértice. Desde RFC 6672: "Si un registro de DNAME está presente en el vértice de la zona, todavía es necesario tener también los registros de recursos de SOA y NS habituales. Tal DNAME no se puede usar para espejo Una zona completamente, como no lo hace. espejo el vértice de la zona ". - Quuxplusone