Un registro CNAME (por Nombre Canónico ) es un tipo de registro de recurso en el Sistema de Nombres de Dominio ( DNS) que asigna un nombre de dominio (el alias) a otro (el nombre canónico). [ 1 ] : § 3.6.2
Esto puede resultar conveniente al ejecutar varios servicios (como un servidor FTP y un servidor web , cada uno en puertos diferentes) desde una única dirección IP . Por ejemplo, se pueden usar registros CNAME para que ftp.example.com y www.example.com apunten a la entrada DNS de example.com , que a su vez tiene un registro A que apunta a la dirección IP. De esta forma, si la dirección IP cambia, solo hay que registrar el cambio en un único lugar de la red: en el registro DNS A de example.com .
Los registros CNAME siempre deben apuntar a otro nombre de dominio, nunca directamente a una dirección IP.
Detalles
Los registros DNS CNAME se especifican en RFC 1034 [ 1 ] y se aclaran en la Sección 10 de RFC 2181. [ 2 ]
Los registros CNAME se gestionan de forma especial en el sistema de nombres de dominio y tienen varias restricciones de uso. Cuando un resolvedor DNS encuentra un registro CNAME al buscar un registro de recurso normal, reinicia la consulta utilizando el nombre canónico en lugar del nombre original. Sin embargo, si se le indica específicamente al resolvedor que busque registros CNAME , se devuelve el nombre canónico (lado derecho) en lugar de reiniciar la consulta. El nombre canónico al que apunta un registro CNAME puede estar en cualquier lugar del DNS, ya sea local o en un servidor remoto en una zona DNS diferente .
$ORIGIN example.com. […] bar.example.com. 3600 IN CNAME foo.example.com. foo.example.com. 3600 IN A 192.0.2.23Considere la zona DNS que se muestra a la derecha: cuando se realiza una búsqueda de registro A para bar.example.com , el resolvedor verá un registro CNAME y reiniciará la búsqueda para foo.example.com , devolviendo finalmente 192.0.2.23 .
Posible confusión
Con un registro CNAME, se puede redirigir un nombre como bar.example.com a foo.example.com . Por ello, en conversaciones informales, la parte izquierda ( bar.example.com ) de una entrada DNS puede identificarse erróneamente como el CNAME ; sin embargo, esto es incorrecto. El registro CNAME almacena el nombre canónico (verdadero) de un host, por lo que la parte derecha es el CNAME real .
bar.example.com. 3600 EN CNAME foo.example.com.Esta confusión se menciona específicamente en RFC 2181, "Aclaraciones a la especificación DNS". La etiqueta de la izquierda es un alias para el lado derecho (la porción RDATA), que es (o debería ser) un nombre canónico. [ 2 ] : § 10.1.1 En otras palabras, considere el registro CNAME que se muestra a la derecha. Esto puede leerse como que bar.example.com es un alias para el nombre canónico foo.example.com . Un cliente solicitará bar.example.com y la respuesta será foo.example.com .
Restricciones
- Los registros CNAME siempre deben apuntar a otro nombre de dominio, nunca a una dirección IP.
- Si un registro CNAME está presente en un nodo, no debería haber otros datos; esto garantiza que los datos de un nombre canónico y sus alias no puedan ser diferentes. [ 1 ] : 15 [ 3 ] La excepción es cuando se utiliza DNSSEC , en cuyo caso puede haber registros relacionados con DNSSEC, como RRSIG , NSEC , etc. [ 2 ] : § 10.1
- Los registros CNAME que apuntan a otros registros CNAME deben evitarse debido a su falta de eficiencia, pero no constituyen un error. [ 1 ] Es posible, entonces, crear bucles irresolubles con registros CNAME , como en:
$ORIGIN example.com. […] foo.example.com. 3600 IN CNAME bar.example.com. bar.example.com. 3600 IN CNAME foo.example.com.
- RFC 1034 también establece la presencia de un registro SOA en el ápice de la zona como un requisito adicional, [ 1 ] : § 4.2.1 presentando otra barrera para colocar un registro CNAME que aparezca en el ápice de la zona.
- Los registros CNAME que son gestionados por registros DNAME pueden provocar bucles recursivos en los resolvedores más antiguos.
- Los registros MX y NS nunca deben apuntar a un alias CNAME . [ 2 ] : § 10.3 Por lo tanto, por ejemplo, una zona no debe contener construcciones como:
$ORIGIN example.com. @ 3600 IN SOA ns1.example.com. hostmaster@example.com ( zone-admin.example.com. […] ) @ 2400 IN MX 0 foo.example.com. foo.example.com. 3600 IN CNAME host.example.com. host.example.com. 3600 IN A 192.0.2.1
- Los dominios que se utilizan en los comandos MAIL y RCPT del Protocolo simple de transferencia de correo pueden no tener un registro CNAME . [ 4 ] En la práctica, esto puede funcionar, pero puede tener un comportamiento diferente con distintos servidores de correo y puede tener efectos no deseados. [ 5 ]
Registro DNAME
Un registro DNAME (por DElegation NAME ) se define en la RFC 6672 [ 6 ] (la RFC 2672 [ 7 ] anterior está obsoleta). El registro DNAME proporciona redirección (alias) para un subárbol del árbol de nombres de dominio en el DNS. Es decir, todos los nombres que terminan con un sufijo particular se redirigen a otra parte del DNS. En cambio, el registro CNAME crea un alias para un solo nombre y no para sus subdominios. Al igual que con el registro CNAME , la búsqueda DNS continuará reintentando la búsqueda con el nuevo nombre. El servidor de nombres sintetiza un registro CNAME para aplicar realmente el registro DNAME al nombre solicitado; los CNAME para cada nodo en un subárbol tienen el mismo efecto que un DNAME para todo el subárbol.
$ORIGIN example.com. […] foo.example.com. 1200 IN DNAME bar.example.com. bar.example.com. 3600 IN A 192.0.2.23 xyzzy.bar.example.com. 3600 IN A 192.0.2.24 *.bar.example.com. 3600 IN A 192.0.2.25Por ejemplo, si hay una zona DNS como la que se muestra a la derecha, una búsqueda de registro A para foo.example.com no devolverá datos porque un DNAME no es un CNAME y no hay ningún registro A definido para el host.foo
Sin embargo, una búsqueda de xyzzy. foo .example.com se asignará mediante DNAME y devolverá el registro A para xyzzy. bar .example.com , que es 192.0.2.24 ; si el registro DNAME hubiera sido un registro CNAME , esta solicitud habría devuelto nombre no encontrado.
Por último, una solicitud para foobar.foo.example.com se mapearía mediante DNAME y devolvería 192.0.2.25 .
Registro ANAME
Varias plataformas DNS gestionadas implementan un tipo de registro ALIAS [ 8 ] o ANAME [ 9 ] no estándar . Estos pseudoregistros son gestionados por administradores DNS como los registros CNAME , pero son publicados y resueltos por (algunos) clientes DNS como los registros A. Los registros ANAME suelen estar configurados para apuntar a otro dominio, pero cuando un cliente los consulta, responden con una dirección IP. Si bien los tipos de registro ANAME se presentaron para su estandarización, [ 10 ] existen otras implementaciones no conformes, por lo que pueden hacer lo que el propietario de la plataforma DNS decida, incluyendo existir en la raíz de una zona y existir para dominios que reciben correo.
La principal ventaja de los registros ANAME sobre los registros CNAME es que pueden usarse en el ápice de una zona, mientras que un resolvedor que sigue estándares no tratará los nombres de dominio con registros CNAME como un ápice de zona. [ 11 ] Además, mientras que un cliente DNS requiere al menos dos consultas para resolver un CNAME a un registro A y a una dirección IP, un ANAME traslada la segunda y las subsiguientes consultas al servidor. Si el servidor DNS puede resolver el registro A y almacenar en caché la dirección IP solicitada de manera más eficiente y con menor latencia que sus clientes DNS, entonces el cliente DNS puede resolver la consulta más rápidamente.
El tipo de registro ANAME se presentó como un borrador de estándar al grupo de trabajo de Operaciones del Sistema de Nombres de Dominio (DNSOP) del IETF ; sin embargo, su revisión más reciente expiró en enero de 2020, [ 10 ] al no haber alcanzado el consenso necesario para una propuesta. Desde entonces, ha sido reemplazado por una serie de borradores para otros dos nuevos tipos de registro que dieron como resultado que el RFC 9460, titulado "Enlace de servicio y especificación de parámetros a través del DNS ( registros de recursos SVCB y HTTPS )", fuera aprobado como estándar propuesto en noviembre de 2023. [ 12 ]
Véase también
Referencias
- 1 2 3 4 5 Mockapetris, Paul V. (1 de noviembre de 1987). Nombres de dominio: conceptos y funcionalidades . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC1034 . RFC 1034. Archivado del original el 18 de agosto de 2023. Recuperado el 16 de marzo de 2019 .
- 1 2 3 4 Elz, Robert y Bush, Randy (1 de julio de 1997). Aclaraciones a la especificación DNS . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC2181 . RFC 2181. Archivado del original el 19 de agosto de 2023. Recuperado el 30 de junio de 2026 .
- ↑ Barr, David (1 de febrero de 1996). "Registros CNAME" . Errores comunes de operación y configuración de DNS . Grupo de trabajo de ingeniería de Internet . sec. 2.4. doi : 10.17487/RFC1912 . RFC 1912. Archivado del original el 15 de agosto de 2023. Recuperado el 4 de julio de 2026 .
- ↑ Braden, Robert T. (1 de octubre de 1989). "Canonicalización" . Requisitos para hosts de Internet: aplicación y soporte . Grupo de trabajo de ingeniería de Internet . sec. 5.2.2. doi : 10.17487/RFC1123 . STD 3. RFC 1123. Archivado del original el 6 de septiembre de 2023. Recuperado el 23 de julio de 2020 .
- ↑ Bernstein, DJ (2000). "Registros CNAME en el correo" . Infraestructura del correo de Internet . Archivado del original el 6 de marzo de 2016. Recuperado el 3 de junio de 2011 .
- ↑ Rose, Scott y Wijngaards, Wouter (18 de junio de 2012). Redirección de DNAME en el DNS . Grupo de Trabajo de Ingeniería de Internet . doi : 10.17487/RFC6672 . ISSN 2070-1721 . RFC 6672. Archivado del original el 31 de octubre de 2024. Recuperado el 30 de junio de 2026 .
- ↑ Crawford, Matt (1 de agosto de 1999). Redirección de nombres DNS no terminales . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC2672 . RFC 2672. Archivado del original el 18 de agosto de 2024. Recuperado el 30 de junio de 2026 .
- ↑ "¿Qué es un registro ALIAS?" . Ayuda de DNSimple . 2013. Archivado del original el 7 de mayo de 2017 . Consultado el 26 de julio de 2019 .
- ↑ "Registros ANAME" . DNS simplificado . 2015. Archivado del original el 18 de noviembre de 2025. Consultado el 24 de septiembre de 2022 .
- 1 2 Finch, Tony; Hunt, Evan; van Dijk, Peter; Eden, Anthony y Mekking, Matthijs (8 de julio de 2019). Alias DNS específicos de dirección (ANAME) . Grupo de trabajo de ingeniería de Internet . ID draft-ietf-dnsop-aname-04 . Archivado del original el 3 de octubre de 2023. Recuperado el 26 de julio de 2019 .
- ↑ Goldlust, Suzanne; Almond, Cathy y Choules, Greg (31 de julio de 2024). "CNAME en el ápice de una zona" . Base de conocimientos de código abierto de ISC . Consorcio de Sistemas de Internet . Archivado del original el 14 de febrero de 2026. Recuperado el 8 de abril de 2023 .
- ↑ Schwartz, Benjamin M.; Bishop, Mike y Nygren, Erik (6 de noviembre de 2023). Enlace de servicio y especificación de parámetros a través del DNS (registros de recursos SVCB y HTTPS) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9460 . ISSN 2070-1721 . RFC 9460. Archivado del original el 3 de diciembre de 2025. Recuperado el 30 de junio de 2026 .
Lecturas adicionales
- RFC 2219 – Uso de alias DNS para servicios de red
- RFC 6672 – Replicación de un subárbol de zona DNS en un segundo nombre de host
- RFC 9460 – Aumento de la eficiencia de la conexión de red mediante la publicación de los detalles de configuración del servidor en el DNS.
- Tipos de registros DNS