Qué es un registro CNAME
Un registro CNAME (canonical name record) dice que un nombre DNS es el alias de otro. www.example.com CNAME example.net significa: lo que quieras saber sobre www.example.com, pregúntaselo en su lugar a example.net. El nombre de la izquierda es el alias; el de la derecha es el nombre canónico, también llamado destino (target).
Un CNAME contiene un nombre de host, nunca una dirección IP. No dice dónde vive el sitio; dice qué otro nombre lo sabe. Ese es justamente su objetivo: el propietario del destino puede cambiar sus direcciones en cualquier momento, y cada alias que apunta a él lo sigue sin que nadie edite su propia zona.
El registro tiene las mismas cuatro partes que cualquier otro registro DNS: un nombre, un TTL, el tipo y el valor. En un archivo de zona se ve como el ejemplo de abajo. Fíjate en el punto final tras el destino: marca el nombre como completo, un detalle al que vuelve la sección de errores.
Los CNAME están en todas partes en cuanto te fijas. www apuntando al nombre de host de un CDN, shop.example.com apuntando a una plataforma de tienda alojada, status.example.com apuntando a un servicio de página de estado, y los registros de verificación que piden muchas herramientas SaaS suelen ser CNAME. La guía de DNS cubre el resto de tipos de registro; esta se queda en el alias.
Registros CNAME en un archivo de zona
$ORIGIN example.com.
; name TTL class type target (canonical name)
www 3600 IN CNAME example.cdn-provider.net.
shop 3600 IN CNAME shops.hosted-store.example.
status 3600 IN CNAME example.status-service.example.Cómo sigue un resolver un CNAME
Los navegadores nunca piden un CNAME. Piden una dirección: un registro A para IPv4 y un AAAA para IPv6. El CNAME entra en juego cuando el resolver que hace la consulta por ellos encuentra uno en el camino.
El resolver pide a los servidores autoritativos de example.com el registro A de www.example.com. En lugar de una dirección, responden con el CNAME: www.example.com es un alias de example.cdn-provider.net. El resolver vuelve a empezar la consulta para el nombre destino, esta vez en los servidores de cdn-provider.net, y obtiene allí el registro A. Devuelve ambos registros al navegador: el CNAME y después la dirección.
Cuando el mismo servidor de nombres es autoritativo para los dos nombres, pone toda la cadena en una sola respuesta y ahorra el segundo viaje. En caso contrario, cada salto es una consulta aparte, por lo que un CNAME puede costar unos milisegundos con la caché fría y nada en cuanto las respuestas quedan cacheadas.
Si pides directamente el tipo CNAME, el resolver se detiene en el alias y no lo sigue. Eso es lo que hace un CNAME lookup en la mayoría de las herramientas en línea: te dice a qué nombre apunta un alias, no la dirección a la que finalmente llega.
$ dig www.example.com A +noall +answer
www.example.com. 3600 IN CNAME example.cdn-provider.net.
example.cdn-provider.net. 60 IN A 203.0.113.25
$ dig www.example.com CNAME +short
example.cdn-provider.net.CNAME frente a registros A y AAAA
Un registro A asocia un nombre a una dirección IPv4, y un registro AAAA a una dirección IPv6. Son el final de toda consulta: sea cual sea la cadena de alias que siga un resolver, se detiene en un registro A o AAAA. Un CNAME asocia un nombre a otro nombre y siempre necesita un paso más.
Usa un registro A o AAAA cuando controlas la dirección y rara vez cambia: tu propio servidor, un balanceador de carga con IP fija, un VPS. Mantienes la dirección tú mismo, y si cambia tienes que editar cada registro que la contenga.
Usa un CNAME cuando la dirección la controla otro: un CDN, una plataforma alojada, una herramienta SaaS. Sus direcciones pueden cambiar, ser distintas por región, o venir de un pool, y tú no deberías tener que saberlo. Un CDN en particular puede responder al mismo nombre de host con direcciones de edge distintas según el lugar; un CNAME a su nombre de host obtiene ese comportamiento gratis, mientras que una IP copiada congela una sola respuesta.
La diferencia práctica de velocidad es pequeña. Un CNAME añade una consulta solo cuando el destino no está en caché, y los destinos populares casi siempre lo están. La diferencia de mantenimiento es grande: un registro A fijo con la IP de un proveedor es la causa clásica de que un sitio se quede sin servicio meses después, cuando el proveedor renumera.
Por qué el dominio raíz no puede ser un CNAME
La regla viene de la especificación original de DNS. RFC 1034, sección 3.6.2, dice que si hay un CNAME en un nombre, no debería haber ningún otro dato ahí, y RFC 2181 lo confirma. El motivo es cómo funciona la resolución: un CNAME significa "todo sobre este nombre vive en otra parte", así que un resolver que encuentra uno deja de buscar cualquier otra cosa en ese nombre. Un segundo registro junto a él sería ignorado o contradictorio. Las únicas excepciones son los registros DNSSEC que firman el propio CNAME.
El dominio raíz (el apex, el example.com desnudo) siempre tiene otros registros. Toda zona debe tener un registro SOA y registros NS en su apex, y la mayoría de los dominios también tienen ahí registros MX para el correo y TXT para SPF y verificación de dominio. Un CNAME en el apex tendría que sustituir a todos ellos, así que el estándar lo prohíbe, y la mayoría de los proveedores de DNS se niegan a guardar uno.
Los proveedores que sí lo aceptan producen una zona que falla de forma impredecible: algunos resolvers devuelven el CNAME y pierden los registros MX, así que el correo empieza a rebotar; otros devuelven los registros MX e ignoran el alias. Por eso www es el lugar clásico para un CNAME, y por eso el dominio desnudo necesita otra respuesta, que cubre la siguiente sección.
Por qué el apex ya tiene registros con los que un CNAME chocaría
example.com. 3600 IN SOA ns1.dns-host.example. hostmaster.example.com. ( ... )
example.com. 3600 IN NS ns1.dns-host.example.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 include:_spf.mail.example ~all"
; example.com. 3600 IN CNAME example.cdn-provider.net. <- not allowed here
www.example.com. 3600 IN CNAME example.cdn-provider.net. ; fine: www has no other recordsALIAS, ANAME y CNAME flattening
Como la gente también quiere el dominio desnudo en un CDN, los proveedores de DNS construyeron soluciones. Tienen nombres distintos, pero todas hacen lo mismo: el proveedor sigue el alias por ti y publica el resultado como registros A y AAAA normales en el apex.
Configuras algo parecido a un CNAME en example.com. Cuando llega una consulta, el servidor de nombres del proveedor resuelve el destino por su cuenta, toma las direcciones que encuentra y responde con ellas. De cara al exterior, el apex tiene registros A y AAAA normales, así que SOA, NS, MX y TXT pueden estar legalmente junto a ellos. Algunos proveedores lo llaman registro ALIAS, otros ANAME, y otros CNAME flattening. Amazon Route 53 tiene sus propios registros alias, que solo apuntan a recursos de AWS. ANAME se propuso como estándar pero nunca se terminó, así que cada una de estas es una característica del proveedor, no un tipo de registro que te acompañe de un proveedor a otro.
Merece la pena conocer las contrapartidas. Las direcciones se eligen desde donde está el servidor de nombres del proveedor, no desde donde está el visitante, así que un CDN que responde distinto según la región puede entregar un edge menos adecuado, salvo que el proveedor transmita la red del visitante (EDNS Client Subnet). El proveedor también controla con qué frecuencia refresca la respuesta, lo que puede ir por detrás del TTL del destino. Y cuando cambias de proveedor de DNS, la función no te acompaña.
También hay una respuesta estándar más nueva: el tipo de registro HTTPS (RFC 9460) tiene una forma de alias permitida en el apex. El soporte de los navegadores para esa forma todavía es limitado, así que trátala como una opción de futuro, no como la solución de hoy.
Lo que un CNAME no hace
Un CNAME no es una redirección. Cambia a qué direcciones resuelve un nombre y nada más. La barra de direcciones sigue mostrando www.example.com, y el navegador sigue enviando Host: www.example.com en cada petición y pide en el handshake TLS un certificado válido para www.example.com.
Eso tiene dos consecuencias con las que la gente tropieza. Primero, el servidor detrás del destino debe estar configurado para aceptar tu nombre de host. Apuntar www a somebody-else.example.net con un CNAME no hace que su servidor sirva tu sitio; sirve lo que sirva para un Host desconocido, a menudo una página de error o un sitio por defecto. Por eso los CDN y las plataformas de hosting te piden añadir primero el nombre de host en su panel y apuntar el DNS después.
Segundo, el certificado debe cubrir tu nombre, no el del destino. Un certificado para example.cdn-provider.net no sirve a un visitante de www.example.com; sin un certificado para tu propio nombre, los navegadores muestran una advertencia de certificado aunque el DNS sea correcto.
Si lo que quieres es enviar a los visitantes de una URL a otra, de modo que la barra de direcciones cambie, eso es una redirección HTTP, un 301 o un 302 respondido por un servidor web. Consulta redirecciones 301 frente a 302.
Errores comunes con CNAME
Un CNAME en el apex. Ya lo vimos arriba: usa las opciones para el dominio raíz que ofrece tu proveedor de DNS en lugar de forzar un CNAME en example.com.
Un CNAME junto a otros registros. La regla se aplica a cualquier nombre, no solo al apex. Si www necesita un registro TXT para una verificación, o shop ya tiene un registro MX, no puedes añadir también un CNAME ahí. La mayoría de los proveedores lo rechazan; los que no lo hacen te dejan con un nombre que responde distinto según el resolver. Pon los registros de verificación en su propio nombre cuando el servicio lo permita.
El punto final que falta. En un archivo de zona, un nombre sin un punto final es relativo y se le añade el nombre de la zona. www CNAME example.cdn-provider.net dentro de example.com se convierte en example.cdn-provider.net.example.com., un nombre que no existe. Escribe el destino con su punto final. Los editores de DNS web varían: la mayoría toma el destino sin punto y lo añade ellos mismos, y algunos lo exigen. Comprueba el resultado con dig en lugar de confiar en el formulario.
Un CNAME a una dirección IP. El valor de un CNAME debe ser un nombre de host. www CNAME 203.0.113.25 se rechaza o se guarda como un nombre que nunca resuelve. Una dirección pertenece a un registro A o AAAA.
Cadenas largas. Un CNAME puede apuntar a otro CNAME, pero cada salto es otra consulta posible y otro TTL. Los resolvers se rinden tras un número fijo de saltos, y un bucle (a a b, b de vuelta a a) falla directamente. Apunta directo al nombre final que te da tu proveedor.
MX o NS apuntando a un alias. RFC 2181, sección 10.3, dice que los destinos de los registros MX y NS deben tener sus propias direcciones, no ser CNAME. Algunos servidores de correo igualmente entregan, otros no.
CNAME colgantes. Cuando cancelas un servicio pero dejas promo.example.com CNAME old-campaign.platform.example en su sitio, cualquiera que después reclame ese nombre en la misma plataforma puede servir contenido en tu subdominio. Esto es un subdomain takeover. Borra el CNAME cuando borres el servicio.
El punto final, bien y mal (archivo de zona de example.com)
; wrong: relative target, becomes example.cdn-provider.net.example.com.
www 3600 IN CNAME example.cdn-provider.net
; right: fully qualified target
www 3600 IN CNAME example.cdn-provider.net.
; wrong: a CNAME plus another record at the same name
shop 3600 IN CNAME shops.hosted-store.example.
shop 3600 IN MX 10 mail.example.com.Cómo consultar un registro CNAME
dig (Linux, macOS, Windows a través de WSL) es la herramienta más clara. dig www.example.com CNAME +short imprime el destino del alias. dig www.example.com +noall +answer imprime toda la cadena hasta las direcciones. dig @1.1.1.1 ... o dig @8.8.8.8 ... pregunta a un resolver público concreto, lo que ayuda cuando sospechas de una respuesta en caché. Y dig +trace recorre la delegación desde los servidores raíz hacia abajo, lo que muestra lo que dicen ahora mismo los servidores autoritativos, sin pasar por ninguna caché.
nslookup está disponible en todas partes, también en Windows puro: nslookup -type=CNAME www.example.com. En PowerShell de Windows, Resolve-DnsName www.example.com -Type CNAME da una respuesta más ordenada.
Las herramientas de consulta en línea responden desde sus propios resolvers, a menudo desde varios países a la vez. Son útiles para una pregunta en concreto: ¿el resto del mundo ve la misma respuesta que tú? Si algunas ubicaciones muestran el destino antiguo y otras el nuevo, el cambio todavía se está propagando.
Cuando la respuesta parece incorrecta, pregunta directamente al servidor de nombres autoritativo. Primero localízalo con dig NS example.com +short, y luego consúltalo con @. Si el servidor autoritativo tiene la respuesta correcta y un resolver público no, estás ante una caché que aún no ha caducado. Si el servidor autoritativo está equivocado, hay que arreglar el registro, en el proveedor de DNS al que apuntan los registros NS.
# the target of the alias
dig www.example.com CNAME +short
# the full chain, alias to address, from a public resolver
dig @1.1.1.1 www.example.com +noall +answer
# straight from the authoritative nameserver, no cache involved
dig NS example.com +short
dig @ns1.dns-host.example www.example.com CNAME +short
# Windows
nslookup -type=CNAME www.example.com
Resolve-DnsName www.example.com -Type CNAMETTL y propagación de un CNAME
Cada registro de una cadena se cachea con su propio TTL. En el ejemplo de dig de arriba, el CNAME tiene un TTL de 3600 segundos y el registro A del destino, 60. Un resolver conserva el alias durante una hora y la dirección durante un minuto. Ese reparto es exactamente lo que quieres con un CDN: el proveedor puede mover sus direcciones en un minuto, mientras que tu propio registro casi nunca cambia.
Eso también te dice cuánto tardan tus propios cambios. Si rediriges www de un destino a otro, los resolvers que cachearon el CNAME antiguo lo siguen usando hasta que su TTL se agota, así que con un TTL de 3600 el cambio se completa en una hora como máximo desde que guardas. Baja el TTL a 300 un día antes de un cambio planeado, haz el cambio, y luego súbelo de nuevo.
Hay dos cosas que tardan más que el TTL del registro. Un nombre que antes no existía puede quedar cacheado como "no existe" durante el tiempo de caché negativa del registro SOA de la zona; añadir el CNAME justo después de que alguien lo consultara puede tardar ese tiempo en verse. Y cambiar los servidores de nombres en tu registrador es una operación distinta de cambiar un registro: depende del TTL que el registry da a la delegación, que a menudo es de uno o dos días. La guía de DNS cubre la propagación en general.
Apuntar un dominio a un CDN con un CNAME, en CDN.com.tr
La configuración típica de un CDN pone www y otros subdominios con un CNAME al nombre de host del CDN, y gestiona el dominio raíz por separado. En CDN.com.tr elige uno de tres métodos de entrega en el panel.
Default Endpoint sirve tu contenido desde un nombre de host xyz.cdn.com.tr, sin ningún trabajo de DNS. Es la forma más rápida de probar, y puedes pasar a tu propio dominio más adelante.
Custom Domain/Subdomain (CNAME) mantiene tu DNS donde está. Añades el nombre de host en el panel, por ejemplo www.example.com o assets.example.com, y creas un CNAME en tu proveedor de DNS que lo apunta al destino que muestra el panel, con la forma <tunombre>.cdn.com.tr. Copia el destino exactamente, sin prefijos adicionales. El dominio raíz no puede usar este método; para él, el panel ofrece un registro A o Full DNS Transfer. Un nombre de host conectado por CNAME obtiene su propio certificado, validado por HTTP en cuanto las peticiones llegan al edge. Como los nombres de host del CDN llevan registros AAAA junto a sus registros A, un CNAME hacia nosotros también da al nombre IPv6, sin ningún registro adicional de tu parte.
Full DNS Transfer mueve los servidores de nombres del dominio a CDN.com.tr. Es la respuesta limpia al problema del apex: el panel se convierte en tu editor de zona, el dominio raíz se enruta al edge sin ningún truco de CNAME, y la raíz obtiene un certificado wildcard que cubre sus subdominios. El panel escanea e importa tus registros existentes (MX, TXT, subdominios) antes del cambio de servidores de nombres, y puedes pedir que el certificado se emita mediante un registro TXT de DNS en tu proveedor actual antes de cambiar, de modo que HTTPS funcione desde el primer minuto.
La guía de configuración de DNS para CDN explica el cambio paso a paso. Una vez que el CNAME resuelve, comprueba que las peticiones realmente pasan por el edge: la cabecera de respuesta X-Proxy-Cache-MT muestra si el edge sirvió la respuesta desde su caché.
$ dig www.example.com CNAME +short
yourname.cdn.com.tr.
$ curl -sI https://www.example.com/ | grep -i x-proxy-cache-mt
X-Proxy-Cache-MT: HITPreguntas frecuentes sobre registros CNAME
¿Puedo usar un registro CNAME para mi dominio raíz?
No, según las reglas estándar de DNS. Un CNAME debe ser el único registro en ese nombre, y el dominio raíz siempre tiene registros SOA y NS, y normalmente también MX y TXT. Usa registros A y AAAA, la función ALIAS, ANAME o de flattening de tu proveedor de DNS, o traslada tu DNS al proveedor que sirve el sitio para que pueda responder directamente en el apex.
¿Un CNAME es lo mismo que una redirección?
No. Un CNAME solo cambia a qué direcciones resuelve un nombre; el navegador conserva tu nombre de host en la barra de direcciones, en la cabecera Host y en la comprobación del certificado. Una redirección es una respuesta HTTP como 301 que envía al visitante a otra URL.
¿Puede un CNAME apuntar a un dominio distinto?
Sí, es su uso más habitual: www.example.com apuntando a un nombre de host de un CDN o SaaS en el dominio de otra persona. El destino solo tiene que ser un nombre de host que resuelva. El servicio detrás también debe estar configurado para aceptar tu nombre de host y tener un certificado para él.
¿Puedo tener un CNAME y un registro MX o TXT en el mismo nombre?
No. Un nombre con un CNAME no puede contener ningún otro registro aparte de firmas DNSSEC. Si un servicio necesita un registro TXT y un CNAME en el mismo nombre, pon el TXT en otro nombre si el servicio lo permite, o usa un registro A en lugar del CNAME.
¿Es un CNAME más lento que un registro A?
Solo con la caché fría, cuando el resolver tiene que consultar el destino por separado; eso cuesta unos milisegundos. Las respuestas en caché no cuestan nada extra. La flexibilidad suele merecer con creces esa diferencia, sobre todo cuando el destino pertenece a un CDN que cambia sus direcciones.
¿Cuánto tarda en funcionar un cambio de CNAME?
Hasta el TTL del registro anterior: los resolvers conservan la respuesta previa hasta que caduca. Con un TTL de 3600 segundos, eso es una hora como máximo. Un nombre recién creado puede tardar más si se consultó hace poco y se cacheó como no existente. Baja el TTL un día antes de los cambios planeados.
¿Cuál es la diferencia entre un CNAME y un DNAME?
Un CNAME crea el alias de un nombre exacto. Un DNAME crea el alias de todo un subárbol: cada nombre bajo old.example.com se asocia al mismo nombre bajo new.example.net, pero no old.example.com en sí. DNAME es raro en sitios web y muchos proveedores de DNS no lo ofrecen.