· 12 min read
El problema del CNAME en el ápex ya está resuelto. Los navegadores aún no se han enterado.
El RFC 9460 resolvió el alias de ápex en el protocolo, pero los clientes nunca siguieron. En DNS multi-proveedor, donde los parches propietarios no son una opción, eso te deja sin salida.
Esta es la versión en español de The apex CNAME problem is solved. Most browsers never got the memo..
RFC 9460 cerró una brecha que llevaba abierta desde principios de los años ochenta. Por fin existe una forma estándar de hacer un alias del ápex de una zona, la única cosa que el CNAME nunca tuvo permitida. La solución es real, sobrevive a DNSSEC y funciona con varios proveedores de DNS. Hay un problema: solo funciona de extremo a extremo cuando el cliente coopera, y a mediados de 2026 la mayoría de clientes todavía no lo hace.
Si tu DNS está detrás de un solo proveedor, esto no te afecta mucho. Puedes cerrar el hueco del ápex con el truco propietario de ese proveedor y seguir adelante. Si corres varios proveedores de DNS en paralelo por redundancia, como debería hacer cualquier entidad financiera, procesador de pagos u operador del sector público, esos trucos propietarios desaparecen y te quedas dependiendo de un soporte de cliente que aún no ha llegado. Este post trata de esa brecha: por qué existe y por qué una arquitectura multi-proveedor es exactamente donde duele más.
El caso límite de cuarenta años
Un ápex de zona tiene dos trabajos que no puede delegar. Lleva el registro SOA, la escritura de la zona: quién es autoritativo, el número de serie, los TTLs. También lleva el conjunto de NS, el directorio de qué servidores responden por la zona. Ambos son obligatorios.
Un CNAME no puede vivir junto a ellos. El significado de un CNAME es: “este nombre no es más que un puntero; ve a resolver el destino y usa lo que encuentres allí.” Como un cartel en un edificio que dice “nos hemos mudado, todo está allá.” No puedes colgar ese cartel en un edificio que es también la sede central con la escritura de la zona y su directorio. Esas dos afirmaciones se contradicen, así que el RFC 1034 prohíbe que CNAME coexista con cualquier otro tipo de registro, y el RFC 1912, sección 2.4, explicita la consecuencia para el ápex.
Los subdominios escapan a esta limitación. El registro www puede ser un CNAME porque no hay nada más que deba vivir allí. El ápex no puede, y esa única restricción ha marcado el proceso de incorporación a CDNs durante más de dos décadas.
La era propietaria y su supuesto oculto
Los vendors llenaron el hueco con maquinaria privada. Akamai construyó Zone Apex Mapping con el registro AKAMAICDN. Cloudflare lanzó el CNAME flattening. Otros vendieron pseudo-registros ALIAS. Difieren en los detalles y coinciden en el espíritu: cuando llega una consulta para el ápex, el servidor autoritativo resuelve un nombre de host destino en segundo plano y sintetiza respuestas A y AAAA frescas al vuelo.
Ese diseño lleva implícito un supuesto que rara vez se nombra en voz alta. El servidor que hace la síntesis tiene que ser el mismo que responde la consulta. Con un solo proveedor, eso se cumple y el truco funciona.
Añade un segundo proveedor y se rompe por dos razones independientes.
La primera es mecánica. Una respuesta sintetizada se calcula en el momento de la consulta a partir de datos de mapeo en vivo. No puedes escribir un destino móvil en un archivo de zona y entregárselo a otro proveedor por transferencia de zona. No hay nada estático que transferir.
La segunda es DNSSEC. Una firma cubre bytes fijos y la produce por adelantado el titular de la clave. Una respuesta sintetizada por consulta no puede firmarse de antemano, así que un proveedor secundario no tiene respuesta firmada que entregar, y un resolver que valida rechaza una sin firma. Akamai lo dejó claro en un post de 2020: el propietario de una zona puede firmarla y usar un solo proveedor, o no firmarla y distribuirla entre varios, pero no las dos cosas a la vez.
Alias de ápex propietario y DNS multi-proveedor son, por tanto, mutuamente excluyentes. Ese es el núcleo de todo el asunto, y la razón por la que un operador serio no tiene ningún atajo.
Antes del estándar: dos intentos que no llegaron a buen puerto
El RFC 9460 no fue el primer intento. El IETF lo intentó dos veces antes y en ambas falló.
En 2010, Ondřej Surý propuso permitir que CNAME coexistiera con otros registros en el ápex, en draft-sury-dnsext-cname-at-ápex. Era la solución más directa imaginable: cambiar la regla que obliga a CNAME a estar solo. Murió por compatibilidad hacia atrás. Todos los resolvers desplegados ya aplicaban la regla antigua, así que un CNAME junto a un SOA habría significado una cosa para los resolvers actualizados y otra para el resto de la base instalada, al mismo tiempo.
El esfuerzo más ambicioso fue ANAME, draft-ietf-dnsop-aname, en el que se trabajó de 2017 a 2019. Definía un registro dedicado que hacía alias solo de los tipos de dirección y dejaba que el servidor autoritativo, o el resolver, sustituyera los A y AAAA del destino al responder. Expiró sin convertirse en estándar, y el motivo importa aquí. ANAME ponía el trabajo del alias en el servidor, el mismo movimiento que hacen los registros propietarios, así que heredó los mismos dos problemas: una respuesta sintetizada por el servidor es difícil de firmar y no replica bien entre proveedores independientes. El grupo de trabajo incorporó el caso de uso a SVCB, y el RFC 9460 dedica una sección (Apéndice C.3) a explicar por qué eligió su enfoque en lugar de ANAME.
El patrón merece nombrarse. Todos los intentos anteriores a SVCB intentaron que el servidor realizara el alias, que es exactamente lo que se rompe con DNSSEC y múltiples proveedores. SVCB ganó haciendo lo contrario: un registro estático que el cliente o el resolver sigue. Esa única decisión es también la raíz del hueco de adopción que veremos a continuación. Lo que hizo a SVCB seguro para múltiples proveedores, un nuevo tipo de registro que los clientes deben aprender a seguir, es lo mismo que ha dejado a la mayoría de clientes sin poder seguirlo.
Lo que el RFC 9460 resolvió de verdad
Los tipos de registro HTTPS y SVCB permiten hacer alias del ápex dentro del protocolo. Pon el campo de prioridad a cero y tienes AliasMode:
bank.com. 3600 IN HTTPS 0 pool.bank.com.Esto coexiste con SOA y NS por una razón sencilla: su alcance está limitado al tipo. El registro solo responde consultas HTTPS. No hace ninguna reclamación sobre el resto del nombre, así que MX, TXT y los registros obligatorios del ápex siguen funcionando junto a él. CNAME reclama el nombre completo; AliasMode reclama un solo servicio.
La propiedad que importa para la redundancia es que este registro son datos estáticos. Lo produces una vez, lo firmas y lo transfieres a todos los proveedores autoritativos que gestiones. DNSSEC funciona porque los bytes nunca cambian. El multi-proveedor funciona porque hay algo concreto que replicar. Eso es exactamente lo que la síntesis en tiempo de consulta nunca pudo ofrecer, y es por lo que el estándar, y no la funcionalidad propietaria, es la única respuesta correcta para un ápex firmado con múltiples proveedores.
La mitad sin resolver
Aquí el relato da un giro, porque resolver el lado de la publicación no resolvió el lado del cliente.
En casi todos los artículos se mezclan dos capacidades distintas. La primera es consumir los parámetros de ServiceMode: un cliente consulta el registro HTTPS y lo usa para elegir HTTP/3, cargar las claves de Encrypted Client Hello o anticipar las pistas de IP. La segunda es seguir AliasMode: un cliente recibe un registro con prioridad cero y persigue el destino para encontrar la dirección. Solo la segunda entrega el alias del ápex. Tienen historias de soporte completamente distintas.
El consumo de ServiceMode es amplio. Chrome, Firefox, Safari, Edge y Opera consultan registros HTTPS y usan sus parámetros. Seguir AliasMode es, en la práctica, exclusivo de Apple.
La evidencia está en el código fuente del navegador. Un estudio de medición de 2024 leyó el código de Chromium y probó navegadores en producción, y encontró que la pila de red de Chromium no emite una consulta de seguimiento para un destino de AliasMode que difiera del nombre consultado.1 Apunta un ápex a un destino de AliasMode sin registro A, y solo Safari emitió la segunda consulta y se conectó; Chrome, Firefox, Edge, Opera y Chromium en Android consultaron el ápex, no encontraron dirección y fallaron. Apple resuelve los registros HTTPS a nivel del sistema operativo, así que toda app en iOS y macOS que use el sistema de red del SO hereda el comportamiento. El resto del mercado, no.
El resolver recursivo tampoco te rescata. Los resolvers públicos sirven el registro correctamente, pero no aplanan un AliasMode del ápex en respuestas A y AAAA para el nombre del ápex, así que un navegador que no lo sigue no obtiene nada útil.
Eso era a principios de 2024. Dos años después, no hay señales públicas de que Chromium o Firefox hayan empezado a seguir AliasMode, así que el panorama a mediados de 2026 no ha cambiado:
La brecha además es difícil de detectar. caniuse, el sitio de referencia para comprobar el soporte de los clientes, no tiene ninguna entrada para esto: no hay ninguna API de script de página que pueda sondear el manejo de los registros HTTPS, porque el trabajo ocurre por debajo del navegador en la ruta de conexión. En consonancia, la petición de añadir el seguimiento de registros DNS allí (issue #6091) lleva abierta desde noviembre de 2021, sin ninguna matriz que mostrar.
La adopción en el lado de la publicación es igual de escasa. Una medición de registros HTTPS en producción encontró AliasMode en unas pocas docenas de dominios ápex al día, frente a un uso prácticamente universal de ServiceMode. Casi nadie publica AliasMode en el ápex, porque solo llega a los clientes de Apple y aún necesitas A y AAAA para todos los demás.
Por qué los diseños multi-proveedor lo sufren más
Imagina un gran banco que gestiona su propio DNS autoritativo primario con un secundario de terceros, cuatro autoridades en total, con la zona firmada con DNSSEC. Quieren añadir un CDN como autoridad de failover para poder desviar tráfico si su infraestructura primaria falla.
$ dig NS bank.com
bank.com. 300 IN NS ns1.bankdns.com.
bank.com. 300 IN NS ns2.bankdns.com.
bank.com. 300 IN NS nsa.secondary-dns.com.
bank.com. 300 IN NS nsb.secondary-dns.com.
$ dig +dnssec bank.com SOA
bank.com. 300 IN SOA ns1.bankdns.com. hostmaster.bank.com. 2026010101 3600 360 2592000 900
bank.com. 300 IN RRSIG SOA 5 2 300 ...No pueden usar la funcionalidad de ápex propietaria del CDN. La zona está firmada y servida por múltiples autoridades, lo que descarta la síntesis en tiempo de consulta por las dos razones anteriores. Así que AliasMode es la única forma estándar de apuntar su ápex al CDN.
Pero AliasMode solo llega a los clientes de Apple. La mayoría del tráfico del banco, Chrome y Android, consultará A y AAAA en el ápex y necesitará registros reales allí. Así que el operador publica A y AAAA de todas formas, y ese movimiento recupera exactamente el problema que la síntesis propietaria fue creada para resolver. Esas direcciones del ápex tienen que ser IPs estables que el CDN se comprometa a mantener, porque nadie puede sintetizarlas por consulta entre múltiples proveedores.
Vuelve a leer esa secuencia, porque ahí está todo el argumento. El alias de ápex basado en estándares, en 2026, es una optimización para una minoría de tus usuarios encima de un suelo de A/AAAA estáticas que todavía tienes que diseñar a mano. El tipo de registro está resuelto. El problema operativo que se suponía que iba a eliminar sigue ahí.
Qué hacer con esto
Publica el registro HTTPS AliasMode. Es correcto, se firma bien, replica entre proveedores y les da a tus usuarios de Apple HTTP/3 y ECH sin coste adicional.
Mantén A y AAAA en el ápex y trátalos como el camino de carga real, no como un legado a eliminar. Soportan la mayoría de tu tráfico y seguirán haciéndolo hasta que la pila de red de Chromium y Firefox aprenda a seguir AliasMode.
Si tu ápex está detrás de un CDN que usa mapeo dinámico, la pregunta que lo decide todo es si ese CDN te dará un conjunto estable de IPs de ápex que puedas codificar en la zona y firmar. Eso, y no la elección del tipo de registro, determina si ápex-en-CDN funciona en un diseño multi-proveedor.
Y vigila a los clientes, porque ahí está el cuello de botella ahora. El IETF terminó su parte en noviembre de 2023. El trabajo restante está en los navegadores y los stub resolvers, y el problema del CNAME en el ápex seguirá medio resuelto hasta que Chromium, Firefox y los demás decidan seguir un registro de prioridad cero.
Referencias y lecturas adicionales
- RFC 9460, Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) — https://datatracker.ietf.org/doc/rfc9460/
- RFC 1912, sección 2.4, sobre las restricciones de CNAME en el ápex
- draft-ietf-dnsop-aname, la propuesta ANAME expirada (2017–2019) — https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
- draft-sury-dnsext-cname-at-ápex, la propuesta de CNAME en el ápex abandonada (2010) — https://datatracker.ietf.org/doc/draft-sury-dnsext-cname-at-ápex/
- Jim Gilbert, Akamai, Redundant, Secure, and Open Short Domains: A Vision for Multi-Provider Apex Domain Aliases — https://www.akamai.com/blog/security/redundant—secure—and-open-short-domains—a-vision-for-multi-pr
- Simon Painter, DNS Service Binding (SVCB) and HTTPS Records: A Practical Guide — https://www.simonpainter.com/svcb-https-records/
- Deciphering the Digital Veil: Exploring the Ecosystem of DNS HTTPS Resource Records (estudio de medición 2024, análisis del código fuente de Chromium) — https://arxiv.org/abs/2403.15672
caniuseissue #6091, Add support for DNS RRs, like HTTPS and SVCB — https://github.com/Fyrd/caniuse/issues/6091
Footnotes
-
Deciphering the Digital Veil: Exploring the Ecosystem of DNS HTTPS Resource Records, arXiv:2403.15672 (2024). Los autores analizaron el código fuente de Chromium a fecha de febrero de 2024 y realizaron pruebas controladas con navegadores actuales, reportando que solo Safari sigue un destino de AliasMode mientras que los clientes basados en Chromium y Firefox no emiten la consulta de seguimiento. https://arxiv.org/abs/2403.15672 ↩