Un error de configuración que casi todos cometen alguna vez
Despliegas una aplicación en una plataforma como Heroku, Vercel, Netlify, un balanceador de carga en la nube o una CDN, y el proveedor te indica que apuntes tu dominio a un nombre de host como mi-app.plataforma.app. Para www.tudominio.com no hay problema: creas un registro CNAME y todo funciona. Pero cuando intentas hacer lo mismo con tudominio.com, sin el www, el panel de DNS se niega o, peor aún, te deja guardarlo y algo deja de funcionar días después, como la recepción del correo electrónico.
Esta situación tiene una explicación concreta en las reglas que gobiernan el sistema de nombres de dominio. La raíz de un dominio, también llamada apex o dominio desnudo, no puede contener un registro CNAME. No es una limitación arbitraria de un proveedor concreto, sino una consecuencia directa de cómo están definidos los estándares del DNS desde hace décadas.
En este artículo vamos a entender el problema desde la base. Repasaremos cómo funciona una consulta DNS, qué tipos de registros existen y cómo inspeccionarlos con dig. Después veremos qué es exactamente un CNAME, por qué choca con los registros obligatorios de la raíz y qué consecuencias reales tiene ignorar la regla. Por último, revisaremos todas las soluciones disponibles hoy, desde los registros ALIAS y el aplanamiento de CNAME hasta el registro HTTPS estandarizado, y cómo elegir entre ellas.
Cómo funciona una consulta DNS
El DNS es el sistema que traduce nombres legibles, como tienda.ejemplo.com, en direcciones IP que los equipos pueden usar para conectarse. Funciona como una base de datos distribuida y jerárquica, repartida entre miles de servidores en todo el mundo.
Cuando escribes una dirección en el navegador, intervienen varios tipos de servidores:
- El resolvedor recursivo, normalmente el de tu proveedor de internet o uno público, recibe la pregunta y se encarga de encontrar la respuesta.
- Los servidores raíz indican qué servidores gestionan cada dominio de nivel superior, como
.como.es. - Los servidores del dominio de nivel superior indican qué servidores son autoritativos para cada dominio registrado.
- Los servidores autoritativos del dominio contienen los registros reales y devuelven la respuesta definitiva.
El resolvedor guarda en caché las respuestas durante el tiempo indicado por cada registro, su TTL, para no repetir todo el recorrido en cada consulta.
Conviene distinguir dos conceptos que a menudo se mezclan. Un nombre de dominio es la cadena completa, como api.ejemplo.com. El dominio raíz o apex es el nivel registrado, ejemplo.com, sin ningún subdominio delante. En la terminología del DNS, cada nombre es un nodo del árbol, y cada nodo puede tener asociados varios registros de distintos tipos.
. (raíz del DNS)
└── com
└── ejemplo ← apex: SOA, NS, A, MX, TXT
├── www ← CNAME → ejemplo-app.plataforma.app
├── api ← A
└── correo ← A
Los tipos de registro más habituales
Cada registro del DNS tiene un tipo que indica qué información contiene. Los más comunes en la gestión diaria de un dominio son estos:
- A: asocia un nombre a una dirección IPv4.
- AAAA: asocia un nombre a una dirección IPv6.
- CNAME: indica que el nombre es un alias de otro nombre, el nombre canónico.
- MX: indica qué servidores reciben el correo del dominio y con qué prioridad.
- TXT: almacena texto arbitrario, usado para verificaciones de propiedad, SPF, DKIM o DMARC.
- NS: indica qué servidores son autoritativos para la zona.
- SOA: el registro de inicio de autoridad, con información administrativa de la zona.
- CAA: indica qué autoridades de certificación pueden emitir certificados para el dominio.
Un archivo de zona típico, en el formato estándar que usan servidores como BIND, se ve así:
$ORIGIN ejemplo.com.
$TTL 3600
@ IN SOA ns1.proveedor-dns.net. admin.ejemplo.com. (
2026101701 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
300 ) ; minimum
@ IN NS ns1.proveedor-dns.net.
@ IN NS ns2.proveedor-dns.net.
@ IN A 203.0.113.10
@ IN MX 10 mx1.correo-ejemplo.net.
@ IN TXT "v=spf1 include:_spf.correo-ejemplo.net -all"
www IN CNAME ejemplo-app.plataforma.app.
api IN A 203.0.113.25
El símbolo @ representa el apex del dominio. Fíjate en que el apex acumula varios registros de distintos tipos: SOA, NS, A, MX y TXT. Esa acumulación es la clave de todo el problema, como veremos enseguida.
Inspeccionar registros con dig
La herramienta de referencia para hacer consultas DNS con dig es la propia dig, incluida en el paquete de utilidades de BIND. Viene instalada en macOS y en la mayoría de las distribuciones Linux, y en Windows puede usarse a través de WSL o instalando las herramientas de BIND:
# Debian y Ubuntu
sudo apt install dnsutils
# Fedora y RHEL
sudo dnf install bind-utils
Una consulta básica devuelve los registros A de un nombre:
dig ejemplo.com A
;; QUESTION SECTION:
;ejemplo.com. IN A
;; ANSWER SECTION:
ejemplo.com. 3600 IN A 203.0.113.10
;; Query time: 18 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
La sección de respuesta muestra el nombre, el TTL en segundos, la clase, el tipo y el valor. Con la opción +short, dig muestra solo los valores, lo que resulta muy cómodo para seguir cadenas de alias:
dig www.ejemplo.com +short
ejemplo-app.plataforma.app.
plataforma-lb-eu.edge.plataforma.net.
198.51.100.42
198.51.100.43
Aquí se ve cómo el resolvedor sigue una cadena: www.ejemplo.com es un alias de ejemplo-app.plataforma.app, que a su vez es un alias de un balanceador, que finalmente devuelve dos direcciones IP.
Otras opciones muy útiles son consultar un servidor concreto, por ejemplo el autoritativo, para evitar respuestas en caché, o pedir todos los registros de un tipo:
dig @ns1.proveedor-dns.net ejemplo.com MX +short
dig ejemplo.com NS +short
dig ejemplo.com SOA +noall +answer
En Windows, sin instalar nada adicional, puedes obtener información similar con el cmdlet Resolve-DnsName de PowerShell:
Resolve-DnsName -Name www.ejemplo.com -Type CNAME
Qué es exactamente un CNAME
Un registro CNAME, abreviatura de nombre canónico, declara que un nombre es un alias de otro. Cuando un resolvedor pregunta por un nombre que tiene un CNAME, el servidor responde con el registro CNAME, y el resolvedor reinicia la búsqueda con el nombre de destino.
Su gran ventaja es la indirección. Imagina que tienes varios subdominios que deben apuntar al mismo servicio:
fotos IN CNAME galeria.ejemplo.com.
imagenes IN CNAME galeria.ejemplo.com.
media IN CNAME galeria.ejemplo.com.
galeria IN A 203.0.113.50
Si el servidor de la galería cambia de dirección IP, solo hay que modificar el registro A de galeria. Los tres alias heredan el cambio automáticamente.
Esta ventaja es todavía mayor con los servicios en la nube. Las plataformas como servicio, las CDN y los balanceadores de carga gestionados cambian sus direcciones IP sin previo aviso: escalan, migran entre regiones o reparten el tráfico entre muchos nodos. Por eso nunca te piden que configures una IP fija, sino que apuntes un CNAME a un nombre de host que ellos controlan. Así, cuando cambian su infraestructura, tu dominio sigue funcionando.
Es importante entender que un CNAME no es una redirección HTTP. El navegador sigue mostrando el nombre original en la barra de direcciones y envía ese nombre al servidor en la cabecera Host y en la negociación TLS. El alias solo actúa en la capa de resolución de nombres.
La regla que lo impide: un CNAME no puede convivir con otros registros
Aquí llegamos al centro del problema. Las especificaciones del DNS establecen que si un nodo tiene un registro CNAME, ese debe ser su único registro. La razón es lógica: un CNAME significa “este nombre es en realidad otro nombre”. Si el nodo tuviera además un registro MX o TXT, no quedaría claro qué respuesta es la correcta: ¿la del alias o la del propio nodo?
Esta regla está recogida en los estándares del DNS. El RFC 1034, que define los conceptos fundamentales del sistema, ya establecía que cuando existe un CNAME en un nodo, no debe haber otros datos. El RFC 2181, que aclara varios aspectos de la especificación, lo reitera, y la única excepción admitida son ciertos registros de seguridad de DNSSEC, como las firmas, que necesitan acompañar al propio CNAME.
Por otro lado, el apex de cualquier zona está obligado a tener al menos dos tipos de registro: el SOA, que define la autoridad de la zona, y los NS, que indican sus servidores autoritativos. Sin ellos, la zona simplemente no puede existir ni delegarse.
Juntando ambas reglas, la conclusión es inevitable. Si el apex necesita obligatoriamente SOA y NS, y un CNAME no puede convivir con ningún otro registro, entonces el apex nunca puede tener un CNAME. Un CNAME en el dominio raíz viola la especificación por definición, independientemente de lo que permita el panel de un proveedor concreto.
Muchos servidores DNS rechazan directamente la zona si encuentran esta combinación. Por ejemplo, BIND la detecta al validar el archivo:
named-checkzone ejemplo.com /etc/bind/zonas/ejemplo.com.db
zone ejemplo.com/IN: loading from master file /etc/bind/zonas/ejemplo.com.db failed: CNAME and other data
zone ejemplo.com/IN: not loaded due to errors.
Conviene precisar que se trata de una restricción del contrato del protocolo, no de una imposibilidad técnica absoluta. Algunos servidores permiten guardar la configuración, pero cada resolvedor y cada aplicación que consulte el dominio puede reaccionar de forma diferente, y ahí empiezan los problemas.
Qué pasa si lo fuerzas de todos modos
Cuando un CNAME convive con otros registros en el apex, el comportamiento deja de ser predecible. Lo habitual es que los resolvedores, al ver el CNAME, sigan el alias y descarten el resto de registros del nodo, porque la especificación les dice que un nombre con CNAME no tiene otros datos.
Las consecuencias más frecuentes son estas:
- El correo deja de llegar, porque los registros MX del apex se ignoran y los servidores de correo remitentes buscan los MX en el destino del alias, que no es tu proveedor de correo.
- Las verificaciones de dominio fallan, porque los registros TXT usados por servicios como Google Workspace, Microsoft 365 o los proveedores de certificados no se encuentran.
- Las políticas de SPF, DKIM y DMARC dejan de aplicarse, lo que hace que tus correos acaben en la carpeta de spam o que otros puedan suplantar tu dominio con más facilidad.
- La emisión de certificados puede bloquearse si los registros CAA no se resuelven como se espera.
El caso del correo es especialmente traicionero porque el fallo puede ser intermitente. Algunos servidores de correo consultan los MX de una forma y otros de otra, de modo que unos mensajes llegan y otros no, y además los resultados en caché pueden mantener el comportamiento anterior durante horas. Puedes comprobar rápidamente qué ven los resolvedores con dig:
dig ejemplo.com MX +short
dig ejemplo.com TXT +short
Si estos comandos no devuelven los valores que configuraste, o devuelven los del destino del alias, el CNAME está ocultando tus registros.
Por qué no basta con una redirección
Ante el problema, una idea tentadora es no complicarse con el DNS: apuntar el apex a un servidor propio con un registro A y redirigir todo el tráfico a www mediante una redirección HTTP 301:
server {
listen 80;
listen 443 ssl;
server_name ejemplo.com;
ssl_certificate /etc/letsencrypt/live/ejemplo.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ejemplo.com/privkey.pem;
return 301 https://www.ejemplo.com$request_uri;
}
Es una solución válida y muy común, pero tiene inconvenientes que conviene conocer. Necesitas mantener un servidor, aunque sea pequeño, con una IP fija y alta disponibilidad, porque si cae, el dominio raíz deja de funcionar. Ese servidor debe tener un certificado TLS válido para el apex, ya que la redirección solo se produce después de establecer la conexión segura. Además, la redirección añade una ida y vuelta adicional en la primera visita, y la URL visible para el usuario cambia, algo que no siempre se desea.
Muchos proveedores DNS y CDN ofrecen redirecciones gestionadas que resuelven estos problemas sin servidor propio, pero sigue siendo una solución en la capa HTTP. Si lo que quieres es que el apex sirva directamente la aplicación, necesitas una solución en la capa DNS.
La solución moderna: registros ALIAS, ANAME y aplanamiento de CNAME
La industria resolvió el problema con un enfoque ingenioso. En lugar de publicar un CNAME en el apex, el servidor DNS autoritativo resuelve él mismo la cadena de alias y responde con los registros A y AAAA finales. Para el resto del mundo, el apex simplemente tiene direcciones IP normales, que conviven sin conflicto con SOA, NS, MX y TXT.
Esta técnica recibe nombres distintos según el proveedor. Los registros ALIAS y ANAME son los más extendidos: DNSimple y otros proveedores usan el nombre ALIAS, mientras que DNS Made Easy, easyDNS y algunos más usan ANAME. Cloudflare lo llama aplanamiento de CNAME, o CNAME flattening, y lo aplica automáticamente cuando configuras un CNAME en el apex. AWS Route 53 ofrece registros de alias, aunque con una particularidad: solo pueden apuntar a recursos de AWS, como balanceadores, distribuciones de CloudFront o buckets de S3. Otros proveedores, como Azure DNS, ofrecen funciones equivalentes con nombres similares.
Una configuración típica en un panel que admite ALIAS se vería así:
@ IN ALIAS ejemplo-app.plataforma.app.
@ IN MX 10 mx1.correo-ejemplo.net.
@ IN TXT "v=spf1 include:_spf.correo-ejemplo.net -all"
www IN CNAME ejemplo-app.plataforma.app.
Pero si consultas el dominio desde fuera, el registro ALIAS no aparece. Lo que ves son registros A ordinarios:
dig ejemplo.com A +short
198.51.100.42
198.51.100.43
Es importante entender que ALIAS y ANAME no son tipos de registro estándar del protocolo. Existen solo dentro del servidor autoritativo del proveedor, que los traduce en el momento de responder. Hubo un intento de estandarizar ANAME en el IETF, pero el borrador no llegó a convertirse en estándar, y la comunidad se orientó hacia otra solución que veremos más adelante. Por eso, si cambias de proveedor DNS, esta configuración no se exporta como un registro estándar y tendrás que recrearla.
En Terraform, por ejemplo, un registro de alias en Route 53 hacia un balanceador se declara así:
resource "aws_route53_record" "apex" {
zone_id = aws_route53_zone.principal.zone_id
name = "ejemplo.com"
type = "A"
alias {
name = aws_lb.web.dns_name
zone_id = aws_lb.web.zone_id
evaluate_target_health = true
}
}
Las limitaciones del aplanamiento
El aplanamiento resuelve el problema de la especificación, pero introduce matices que conviene conocer antes de adoptarlo.
El primero tiene que ver con la geolocalización. Muchas CDN devuelven direcciones IP distintas según la ubicación de quien consulta, para dirigir a cada usuario al nodo más cercano. Con un CNAME normal, la consulta llega a la CDN desde el resolvedor del usuario, que suele estar cerca de él. Con el aplanamiento, quien consulta a la CDN es el servidor autoritativo del proveedor DNS, que puede estar en otra región. Si el proveedor no lo compensa, el usuario podría recibir la IP de un nodo lejano. Los proveedores más grandes mitigan esto con la extensión EDNS Client Subnet o con redes propias distribuidas por todo el mundo.
El segundo es la propagación de cambios. Cuando la plataforma cambia sus direcciones IP, tu proveedor DNS tiene que volver a resolver la cadena para actualizar las respuestas aplanadas. Esto depende del TTL del registro de destino y de la frecuencia con la que el proveedor refresca sus datos, lo que puede introducir un pequeño retraso respecto a un CNAME directo.
El tercero es la dependencia del proveedor, como ya mencionamos: la configuración no es portable y cada servicio la implementa a su manera.
El cuarto afecta a la seguridad con DNSSEC. Como el servidor autoritativo genera las respuestas A en el momento, tiene que firmarlas dinámicamente. Los grandes proveedores lo resuelven, pero es un punto a comprobar si tu dominio usa DNSSEC.
El registro HTTPS: el sucesor estandarizado
La comunidad del DNS buscó durante años una solución estándar para este problema, y la encontró en los registros SVCB y HTTPS, publicados como estándar en el RFC 9460. El registro HTTPS es una especialización de SVCB pensada para servicios web, y entre sus capacidades incluye un modo de alias que funciona perfectamente en el apex.
El registro HTTPS en DNS tiene dos modos. En el modo alias, indicado con prioridad cero, el registro dice a los clientes que el servicio HTTPS de ese nombre está en realidad en otro nombre de host. A diferencia de un CNAME, solo afecta a los clientes que buscan el servicio web, por lo que puede convivir sin problemas con SOA, NS, MX y TXT:
@ IN HTTPS 0 ejemplo-app.plataforma.app.
@ IN MX 10 mx1.correo-ejemplo.net.
@ IN A 203.0.113.10
En el modo de servicio, con prioridad mayor que cero, el registro anuncia parámetros de conexión, como los protocolos admitidos, el puerto o pistas de direcciones IP. Esto permite, por ejemplo, que el navegador sepa de antemano que el servidor admite HTTP/3 y se conecte directamente con QUIC sin una negociación previa:
ejemplo.com. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint="198.51.100.42"
Puedes consultar estos registros con las versiones actuales de dig:
dig ejemplo.com HTTPS +short
1 . alpn="h3,h2" ipv4hint=198.51.100.42
Varios navegadores modernos ya consultan registros HTTPS al conectarse a un sitio, especialmente cuando usan DNS sobre HTTPS, y algunos proveedores como Cloudflare los publican automáticamente para los dominios que gestionan. Sin embargo, no todos los clientes los entienden todavía. Herramientas de línea de comandos, bibliotecas HTTP antiguas, servidores de correo y muchos otros sistemas siguen consultando solo registros A y AAAA. Por eso, hoy por hoy, el registro HTTPS en modo alias funciona como complemento y no como sustituto: lo recomendable es mantener también registros A y AAAA, ya sean estáticos o generados por aplanamiento, para los clientes que no lo admiten.
Cómo elegir la solución adecuada
Con todas las opciones sobre la mesa, la decisión depende de tu proveedor DNS y de dónde se aloja la aplicación.
Si tu proveedor DNS ofrece ALIAS, ANAME o aplanamiento de CNAME, esa es la vía más sencilla y robusta para apuntar el apex a una plataforma que solo proporciona un nombre de host. Configúralo en el apex y usa un CNAME normal para www.
Si tu aplicación está en AWS y usas Route 53, los registros de alias son la opción natural, sin coste por consulta y con soporte para comprobaciones de estado.
Si tu proveedor DNS no ofrece ninguna de estas funciones, tienes dos alternativas. La primera es comprobar si la plataforma de alojamiento publica direcciones IP estables para el apex; muchas, como Vercel, Netlify o GitHub Pages, documentan una o varias IP fijas o anycast para este caso concreto. La segunda es trasladar la gestión de la zona a un proveedor que admita aplanamiento, algo que no exige cambiar de registrador, solo los servidores NS del dominio.
Si prefieres que la dirección canónica sea www y el apex solo redirija, una redirección gestionada por tu proveedor DNS o CDN es una solución limpia que evita mantener servidores propios.
Y, en cualquier caso, publicar además un registro HTTPS es una mejora progresiva que beneficia a los clientes modernos sin perjudicar a los demás.
Un pequeño script ayuda a verificar que, tras cualquier cambio, el apex responde correctamente y conserva sus registros críticos:
#!/usr/bin/env bash
DOMINIO="ejemplo.com"
for tipo in A AAAA MX TXT CAA HTTPS; do
echo "== $tipo =="
dig +short "$DOMINIO" "$tipo"
done
echo "== CNAME en el apex (debe estar vacío) =="
dig +short "$DOMINIO" CNAME
Errores comunes y cómo diagnosticarlos
Al configurar el apex aparecen siempre los mismos problemas.
El primero es crear el CNAME en el apex en un proveedor que lo permite sin aplanamiento. El panel acepta el cambio, la web funciona, pero el correo empieza a fallar. Comprueba con dig ejemplo.com CNAME que el apex no publica ningún CNAME.
El segundo es olvidar el subdominio www. Configurar correctamente el apex no sirve de mucho si www.ejemplo.com no resuelve o apunta a otro sitio. Define ambos y decide cuál es la dirección canónica.
El tercero es no tener en cuenta los certificados. Si el apex y www apuntan a la misma plataforma, el certificado TLS debe cubrir ambos nombres. La mayoría de las plataformas lo generan automáticamente, pero solo después de verificar que el DNS apunta a ellas, por lo que pueden pasar unos minutos hasta que el sitio funcione por HTTPS.
El cuarto es la impaciencia con la caché. Tras un cambio, los resolvedores pueden seguir devolviendo los valores anteriores hasta que expire su TTL. Consultar directamente al servidor autoritativo permite saber si el cambio ya está publicado:
dig @ns1.proveedor-dns.net ejemplo.com A +short
Reducir el TTL unas horas antes de una migración planificada acelera la propagación cuando llega el momento del cambio.
El quinto es apuntar el alias a un destino que es a su vez una cadena larga de CNAME. Cada salto añade latencia y puntos de fallo. Cuando sea posible, apunta directamente al nombre de host que te indica la plataforma.
Conclusiones
La raíz de un dominio no puede ser un CNAME por una combinación de dos reglas del DNS: el apex debe tener obligatoriamente registros SOA y NS, y un CNAME no puede convivir con ningún otro registro en el mismo nodo. Como ambas condiciones son incompatibles, cualquier CNAME en el apex viola la especificación, y forzarlo provoca efectos tan graves como la pérdida de correo o el fallo de las verificaciones de dominio.
El problema se volvió especialmente relevante con la llegada de las plataformas en la nube, las CDN y los balanceadores gestionados, que solo proporcionan nombres de host porque sus direcciones IP cambian constantemente. Las redirecciones HTTP ofrecen una salida parcial, pero obligan a mantener infraestructura adicional y cambian la URL visible.
La solución práctica más extendida hoy son los registros virtuales, conocidos como ALIAS, ANAME, aplanamiento de CNAME o alias de Route 53, que resuelven la cadena en el servidor autoritativo y publican registros A y AAAA compatibles con el resto del apex. Su principal inconveniente es que no son estándar y dependen del proveedor.
El futuro pasa por el registro HTTPS, estandarizado en el RFC 9460, que incluye un modo de alias válido en el apex y añade información útil para conexiones más rápidas. Mientras su adopción se completa, la combinación de aplanamiento para los clientes tradicionales y registros HTTPS para los modernos es la configuración más sólida para cualquier dominio que deba apuntar su raíz a un servicio en la nube.