Cadenas CNAME en DNS: cuando son un problema de rendimiento y fiabilidad

Qué es realmente una cadena CNAME (y qué cuesta)

Un registro CNAME dice: “este nombre es un alias de ese otro nombre.” No dice dónde vive el servicio. Dice quién sabe dónde
vive el servicio.

Una cadena CNAME ocurre cuando el alias apunta a otro alias, que apunta a otro alias, y así sucesivamente, hasta que finalmente
llegas a un registro de dirección (A o AAAA), o a una respuesta terminal como NXDOMAIN.

En una pizarra, una cadena parece inofensiva:

• api.example.com → CNAME api.edge.vendor.net
• api.edge.vendor.net → CNAME api.geo.vendor.net
• api.geo.vendor.net → A/AAAA 203.0.113.10 / 2001:db8::10

En producción, el coste se paga en:

• Viajes extra (o trabajo recursivo adicional dentro de tu resolvedor) para seguir cada salto.
• Puntos de fallo adicionales (más zonas, más servidores autoritativos, más aristas de TTL, más políticas, más caídas).
• Mayor complejidad de caché (diferentes TTL en cada salto, comportamiento de caché inconsistente entre resolvers).
• Más momentos de “funciona en mi portátil” (resolvedores locales, VPNs, y operadores móviles actúan de forma distinta).

No hay un “número malo” universal, pero como operador trato cualquier cosa más allá de un salto CNAME como una decisión de riesgo.
Más allá de dos saltos quiero una razón, un responsable y monitorización.

Broma #1: Una cadena CNAME es como reenviar llamadas en una oficina—genial hasta que tu llamada pasa por tres asistentes y nadie sabe quién hace el trabajo.

Cómo ocurre realmente la resolución (rápido, pero correcto)

Con un resolvedor stub típico (el host de tu app) y un resolvedor recursivo (tu DNS corporativo o un resolvedor público), el stub pregunta al recursivo:
“¿qué es api.example.com?” El resolvedor recursivo hace la persecución: contacta servidores autoritativos según haga falta,
sigue CNAMEs, valida DNSSEC si está activado, y devuelve las respuestas finales A/AAAA (y normalmente incluye la cadena CNAME en la respuesta).

Si la caché del recursivo está caliente y todo encaja en las ventanas de TTL, puede que pagues casi cero tiempo extra. Si las cachés están frías,
o los TTL son pequeños, o cruzas regiones, esos saltos se convierten en latencia real.

El multiplicador oculto: reutilización de conexiones y fallos de caché DNS

Una sola búsqueda DNS no importa mucho. Lo que importa es cuántas haces, con qué frecuencia fallas la caché y qué bloqueas en ese proceso.
Los clientes modernos abren muchas conexiones (o las reutilizan, idealmente). Cuando los pools de conexión churnean—por despliegues, autoscaling, timeouts de NAT,
o resets HTTP/2—DNS vuelve al camino caliente.

Ahí es cuando las cadenas CNAME dejan de ser “trivia DNS” y se convierten en un factor de disponibilidad.

Por qué las cadenas CNAME afectan el rendimiento y la fiabilidad

1) Latencia: cada salto añade oportunidades para respuestas lentas

Un resolvedor recursivo puede tener que hablar con múltiples servidores autoritativos en varios dominios. Cada salto puede implicar:
RTT de red, temporizadores de reintento, retroceso a TCP (cuando las respuestas son grandes), validación DNSSEC y limitación de tasa. Si tienes mala suerte,
también sufrirás pérdida de paquetes y retransmisiones—DNS sobre UDP es rápido hasta que deja de serlo.

El “salto extra” no siempre es un RTT extra, porque un resolvedor a veces puede obtener varios registros de forma eficiente. Pero en la práctica, más saltos
significa más dependencias externas y más oportunidades de cruzar una frontera de caché fría.

2) Desajuste de TTL: la cadena se cachea mal

Cada registro en la cadena tiene su propio TTL. Los resolvers cachean cada RRset según su TTL. Si tienes:

• un TTL largo en el primer salto (tu zona),
• un TTL corto en el segundo salto (zona del proveedor),
• y un TTL medio en el registro de dirección,

…entonces puedes acabar en una situación donde algunos resolvers mantienen tu alias en caché mientras vuelven a buscar constantemente el siguiente salto del proveedor.
La cadena se convierte en un generador periódico de fallos de caché.

3) Radio de impacto: más zonas, más caídas

Con un registro A/AAAA directo en tu zona, tus dependencias son tu proveedor DNS y tus servidores autoritativos. Con una cadena,
dependes también de los servidores autoritativos del proveedor. Añade un segundo proveedor (CDN a WAF a GSLB), y básicamente has construido una pequeña
cadena de suministro.

Las cadenas de suministro fallan.

4) Ambigüedad operativa: depurar se vuelve “arqueología DNS”

Cuando un usuario reporta “timeouts intermitentes,” los ingenieros primero revisan la app. Luego el balanceador. Luego el firewall. DNS suele ser lo último,
porque se siente como fontanería. Las cadenas CNAME hacen esa fontanería dinámica y multi-propietaria. Estás depurando no solo tu configuración, sino el
comportamiento de tus proveedores, su política de TTL, sus caídas y su lógica de enrutamiento.

5) Comportamiento específico del resolvedor: la misma cadena puede comportarse distinto

No todos los resolvers se comportan idénticamente. Las diferencias incluyen:

• políticas de expulsión de caché y tamaño máximo de caché
• qué tan agresivamente hacen prefetch
• límites en la profundidad de encadenamiento CNAME
• timeouts, estrategia de reintentos y cambio UDP/TCP
• configuración y modos de fallo de validación DNSSEC
• comportamiento EDNS0 y manejo del tamaño de respuesta

No necesitas memorizar las rarezas de cada resolvedor. Necesitas aceptar que una cadena frágil se comportará como un sistema distribuido: a veces degradará
de formas que tus pruebas internas nunca reproducen.

6) La falacia de “es solo un salto más”

Cada salto extra se siente como una decisión pequeña: alias al endpoint SaaS, alias al CDN, alias a la plataforma de marketing, alias al gestor de tráfico.
Individualmente racional. Colectivamente, una cadena.

Esa falacia termina cuando debes responder: “¿Cuál es el tiempo máximo para resolver nuestro endpoint de login con caché fría desde un operador móvil en otro país?”
Si no puedes responder eso, has introducido incertidumbre en tu flujo de login. Eso no es una característica.

Una cita para llevar en una nota: “La esperanza no es una estrategia.” — General Gordon R. Sullivan.

Hechos y contexto histórico que explican el lío actual

DNS no es nuevo, pero la forma en que lo usamos hoy es muy nueva. Las cadenas CNAME son comunes porque seguimos superponiendo sistemas sobre un protocolo
diseñado para una internet más pequeña y calma.

1. CNAME existe desde los primeros RFCs de DNS, creado para evitar duplicar registros de dirección en muchos alias.
   Es una herramienta para la indirecta, y la indirecta siempre se usa.
2. DNS fue diseñado asumiendo que el caché haría el trabajo pesado. Toda la arquitectura espera que las consultas repetidas sean baratas
   porque los resolvers recursivos almacenan respuestas.
3. El cache negativo se estandarizó después (cachear NXDOMAIN y resultados similares), lo que redujo carga pero introdujo
   su propio retraso de “¿por qué sigue roto?” al corregir errores tipográficos.
4. EDNS0 se introdujo para lidiar con límites de tamaño de respuesta. Eso importa porque las cadenas CNAME más DNSSEC pueden inflar respuestas,
   provocando fragmentación o retroceso a TCP.
5. Los CDN popularizaron el enrutamiento basado en DNS a gran escala. Eso suele significar TTL cortos y respuestas más dinámicas.
   Genial para el enrutamiento; duro para las cachés.
6. Muchas empresas empezaron a tratar DNS como gestión de configuración: “simplemente CNAMEalo a eso.” Es cómodo y peligrosamente fácil de hacer sin medir el coste.
7. Algunos resolvers aplican límites prácticos al seguimiento de alias para evitar bucles y abuso de recursos. Si tu cadena es larga o rara,
   algunos clientes fallarán antes que otros.
8. La adopción de DNSSEC introdujo una nueva clase de fallos: las respuestas pueden estar “presentes pero inválidas,” y las fallas de validación pueden
   parecer timeouts según el comportamiento del cliente.
9. El “aplanamiento de CNAME” surgió como solución para registros apex donde los CNAME están restringidos. Mejora algunas cosas y rompe otras (más adelante lo explico).

Modos de fallo que verás en producción

La profundidad de la cadena alcanza los límites del resolvedor

Algunos resolvers limitan el número de CNAMEs que perseguirán. Otros limitan el trabajo recursivo total por consulta. Una cadena larga puede alcanzar esos límites,
lo que para el cliente se ve como SERVFAIL o timeouts.

NXDOMAIN intermitente desde upstream

Los proveedores a veces despliegan cambios de DNS y brevemente sirven zonas inconsistentes: algunos servidores autoritativos conocen un registro, otros no,
o los cambios de delegación se propagan de forma desigual. Tu resolvedor puede alcanzar un servidor autoritativo “malo” y cachear NXDOMAIN (caché negativa),
convirtiendo un problema transitorio del proveedor en una caída más larga para ti.

Fragmentación UDP y retroceso a TCP

Las respuestas DNS grandes pueden fragmentarse. El UDP fragmentado no se entrega de forma fiable en todas las redes. Cuando la fragmentación falla, los resolvers
reintentan, cambian a TCP o agotan el tiempo. Las cadenas CNAME contribuyen a respuestas más grandes, y DNSSEC puede empeorar esto añadiendo firmas.

Rarezas de dual-stack (AAAA vs A)

Si tu cadena termina con A y AAAA, los clientes pueden preferir IPv6 y luego volver a IPv4 (o viceversa). Si la conectividad IPv6 es inestable,
el fallo se ve como “DNS lento,” porque la resolución funcionó pero el establecimiento de la conexión se queda atascado.

Sorpresas de split-horizon

Internamente, service.example.com podría resolverse a un VIP interno. Externamente, hace CNAME a un proveedor. Si tu cadena mezcla
vistas internas y externas, alguien acabará usando el resolvedor equivocado en el lugar equivocado y se preguntará por qué staging está llamando a prod.

Bucle de CNAME

Las malas configuraciones ocurren: a hace CNAME a b y b hace CNAME de vuelta a a. Los buenos resolvers
detectan bucles, pero los clientes siguen viendo fallo. Los bucles suelen colarse durante migraciones donde nombres antiguos y nuevos coexisten.

Guion de diagnóstico rápido

Cuando se sospecha DNS, no “huronees.” Ejecuta un bucle estrecho de comprobaciones que te diga de dónde vienen el tiempo y los fallos.
Este es el orden que ahorra tiempo.

Primero: verifica si tienes una cadena y cuán profunda es

• Consulta con dig e inspecciona la sección ANSWER en busca de múltiples CNAMEs.
• Nota los TTL en cada salto.
• Decide si la cadena es estable (mismos resultados) o dinámica (respuestas que varían rápidamente).

Segundo: separa la latencia del resolvedor de la latencia autoritativa

• Consulta tu resolvedor recursivo normal y registra el tiempo de consulta.
• Luego consulta directamente los servidores autoritativos para cada salto.
• Si el resolvedor recursivo es lento pero los autoritativos son rápidos, estás viendo fallos de caché, coste de validación DNSSEC, limitación de tasa o sobrecarga del resolvedor.
• Si las respuestas autoritativas son lentas o inconsistentes, tu cadena te ha convertido en cliente de la fiabilidad DNS de otra entidad.

Tercero: prueba comportamiento con caché fría vs caliente

• Ejecuta consultas repetidas y comprueba si la latencia colapsa después del primer acierto.
• Si no lo hace, los TTL pueden ser demasiado bajos, las respuestas demasiado dinámicas o la caché deshabilitada/bypasseada.

Cuarto: verifica retroceso a TCP / truncamiento

• Busca comportamiento “TC” (truncado), respuestas grandes o sobrecarga DNSSEC.
• Prueba con +tcp para ver si TCP lo hace fiable (y más lento).

Quinto: correlaciona con los síntomas de la aplicación

• Confirma si la app bloquea en DNS (común en clientes HTTP síncronos durante el establecimiento de conexión).
• Revisa churn en pools de conexión alrededor de despliegues/autoscaling.
• Busca picos en la tasa de “nuevas conexiones” y consultas DNS por segundo.

Si haces solo una cosa: mide el tiempo de resolución desde la misma ruta de red que usan los clientes afectados. Los problemas de DNS adoran esconderse detrás
de “pero es rápido desde mi estación de trabajo.”

Tareas prácticas: comandos, salidas y decisiones

Estas son las comprobaciones que realmente ejecuto. Cada una incluye: un comando, qué significa una salida típica, y la decisión que impulsa.
Sustituye los nombres de ejemplo por los tuyos. Mantén la estructura.

Task 1: Muestra toda la respuesta y detecta la cadena

cr0x@server:~$ dig api.example.com A +noall +answer
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

Qué significa: Dos saltos CNAME antes del registro A. Los TTL son 300 → 60 → 60, así que refrescarás los saltos del proveedor con frecuencia.
Decisión: Si este es un endpoint crítico (login, checkout, API), apunta a reducir a ≤1 salto o negocia TTLs más largos con el proveedor.

Task 2: Mide el tiempo de consulta desde tu resolvedor habitual

cr0x@server:~$ dig api.example.com A +stats | tail -n 3
;; Query time: 84 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:03:11 UTC 2025

Qué significa: 84 ms para una búsqueda desde tu entorno. Eso no es gratis.
Decisión: Si ves >20 ms dentro de un centro de datos, trátalo como sospechoso y continúa con el aislamiento autoritativo.

Task 3: Compara con un resolvedor público (chequeo de cordura, no una solución)

cr0x@server:~$ dig @1.1.1.1 api.example.com A +stats | tail -n 3
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Dec 31 12:03:26 UTC 2025

Qué significa: El resolvedor público es más rápido. Tu resolvedor interno podría estar sobrecargado, mal configurado o lejos.
Decisión: Investiga la salud y topología del resolvedor interno; no te limites a “cambiar a DNS público” y dar por hecha la tarea.

Task 4: Fuerza una vista relativamente fría evitando la caché (en lo posible)

cr0x@server:~$ dig api.example.com A +nocache +stats | tail -n 3
;; Query time: 92 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:03:45 UTC 2025

Qué significa: Sigue siendo lento. O el resolvedor no puede cachear eficazmente (TTL muy bajos / respuestas dinámicas), o la parte lenta está upstream.
Decisión: Pasa a comprobaciones autoritativa-por-autoritativa para localizar el salto lento.

Task 5: Encuentra los nameservers autoritativos para tu zona

cr0x@server:~$ dig example.com NS +noall +answer
example.com.          172800 IN NS ns1.dns-provider.net.
example.com.          172800 IN NS ns2.dns-provider.net.

Qué significa: Tu zona es servida por ns1/ns2.
Decisión: Consulta estos directamente para ver si tus registros son correctos y consistentes.

Task 6: Consulta tu servidor autoritativo directamente (verifica tu primer salto)

cr0x@server:~$ dig @ns1.dns-provider.net api.example.com CNAME +noall +answer +stats
api.example.com.        300 IN CNAME api.edge.vendor.net.
;; Query time: 12 msec
;; SERVER: ns1.dns-provider.net#53(ns1.dns-provider.net) (UDP)

Qué significa: Tu autoritativo responde rápido y devuelve el CNAME esperado.
Decisión: Probablemente tu zona no es el problema; persigue el salto del proveedor a continuación.

Task 7: Encuentra los servidores autoritativos de la zona del proveedor

cr0x@server:~$ dig edge.vendor.net NS +noall +answer
edge.vendor.net.      3600 IN NS ns-101.vendor-dns.net.
edge.vendor.net.      3600 IN NS ns-102.vendor-dns.net.

Qué significa: El proveedor usa infraestructura autoritativa separada. Esa es una dependencia que no operas.
Decisión: Consulta estos directamente y mide. Si son lentos, tienes evidencia para abrir un ticket con el proveedor.

Task 8: Consulta el autoritativo del proveedor directamente (mide el segundo salto)

cr0x@server:~$ dig @ns-101.vendor-dns.net api.edge.vendor.net CNAME +noall +answer +stats
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
;; Query time: 97 msec
;; SERVER: ns-101.vendor-dns.net#53(ns-101.vendor-dns.net) (UDP)

Qué significa: 97 ms a un autoritativo del proveedor. Eso muy probablemente es el culpable de la latencia DNS.
Decisión: Considera reducir la profundidad de la cadena (integración directa), presiona por mejores TTL/latencia, o añade un endpoint de tráfico más fiable que controles.

Task 9: Comprueba inconsistencias entre servidores autoritativos del proveedor

cr0x@server:~$ for ns in ns-101.vendor-dns.net ns-102.vendor-dns.net; do dig @$ns api.edge.vendor.net CNAME +noall +answer; done
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.edge.vendor.net.     60 IN CNAME api-alt.geo.vendor.net.

Qué significa: Dos servidores autoritativos discrepan. Eso no es “balanceo DNS.” Es inconsistencia.
Decisión: Trátalo como riesgo de incidente del proveedor. Si tu resolvedor golpea el “equivocado”, obtendrás objetivos distintos y potencialmente comportamiento distinto.

Task 10: Detecta bucles CNAME o persecuciones excesivas con trace

cr0x@server:~$ dig api.example.com A +trace
; <<>> DiG 9.18.24 <<>> api.example.com A +trace
;; Received 525 bytes from 10.0.0.53#53(10.0.0.53) in 1 ms
example.com.     172800 IN NS ns1.dns-provider.net.
example.com.     172800 IN NS ns2.dns-provider.net.
api.example.com.    300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net. 60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.  60 IN A 203.0.113.10

Qué significa: Trace muestra la cadena claramente. Si vieras rebotes repetidos entre dos nombres, eso es un bucle.
Decisión: Si aparece un bucle o una cadena muy larga, arréglalo de inmediato; no “esperes y veas.”

Task 11: Revisa truncamiento y riesgo de retroceso a TCP

cr0x@server:~$ dig api.example.com A +dnssec +bufsize=1232 +noall +comments +answer
;; Got answer:
;; WARNING: Message has 1 extra bytes at end
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

Qué significa: Estás empujando hacia los límites de tamaño/transporte (la advertencia exacta varía). Con DNSSEC, las respuestas pueden crecer rápido.
Decisión: Si ves truncamiento (“TC” flag) en capturas reales, evalúa el tamaño de respuesta DNS, acorta la cadena o ajusta el resolvedor/red para manejar TCP de forma fiable.

Task 12: Fuerza TCP para ver si “UDP es inestable”

cr0x@server:~$ dig api.example.com A +tcp +stats | tail -n 3
;; Query time: 143 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (TCP)
;; WHEN: Wed Dec 31 12:05:02 UTC 2025

Qué significa: TCP es más lento pero puede ser más fiable en algunas redes. Si los resultados UDP son timeouts y TCP funciona, tienes un problema de ruta/MTU/fragmentación.
Decisión: Arregla problemas de la ruta de red y el tamaño de respuesta. No fuerces TCP por todas partes como “solución” a menos que te guste pagar impuestos de latencia para siempre.

Task 13: Inspecciona la configuración del resolvedor local (ver qué estás usando realmente)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.example

Qué significa: Estás usando resolvedores internos; la validación DNSSEC está desactivada en esta capa (puede seguir activa río arriba).
Decisión: Si la latencia difiere mucho entre 10.0.0.53 y 10.0.0.54, la distribución de carga o las comprobaciones de salud están mal. Arregla la salud de la flota de resolvedores antes de tocar registros.

Task 14: Mide el comportamiento del resolvedor en el tiempo (distribución de latencia, no una muestra)

cr0x@server:~$ for i in {1..10}; do dig api.example.com A +stats +noall +answer; done
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10

Qué significa: La salida muestra un mapeo estable (bien), pero aún necesitas inspeccionar los tiempos de consulta. En la práctica incluirías las líneas de stats o capturarías con un script.
Decisión: Si la primera búsqueda es lenta y las siguientes nueve son rápidas, la caché funciona y los TTL no son terribles. Si las diez varían, la cadena es dinámica o el resolvedor está sufriendo.

Task 15: Comprueba si el host de tu app está golpeando DNS (vista del sistema)

cr0x@server:~$ sudo ss -uapn | grep ':53 ' | head
UNCONN 0 0 10.10.5.21:58642 10.0.0.53:53 users:(("python3",pid=24817,fd=9))
UNCONN 0 0 10.10.5.21:49811 10.0.0.53:53 users:(("java",pid=11302,fd=123))

Qué significa: Puedes ver qué procesos hablan con DNS. Si un servicio está golpeando mucho DNS, el pooling de conexiones o el caché podrían estar rotos.
Decisión: Arregla el comportamiento del cliente (reutiliza conexiones, habilita caché DNS donde proceda) antes de rediseñar registros DNS.

Task 16: Valida que el final de la cadena devuelve A y AAAA (o que no lo hace intencionalmente)

cr0x@server:~$ dig api.example.com A AAAA +noall +answer
api.example.com.        300 IN CNAME api.edge.vendor.net.
api.edge.vendor.net.     60 IN CNAME api.geo.vendor.net.
api.geo.vendor.net.      60 IN A     203.0.113.10
api.geo.vendor.net.      60 IN AAAA  2001:db8::10

Qué significa: Hay dual-stack en juego. Bien—si tu red soporta IPv6 de forma fiable.
Decisión: Si clientes en algunos entornos fallan con IPv6, verás retrasos “aleatorios”. Considera la salud de IPv6, el comportamiento Happy Eyeballs, o desactivar AAAA intencionadamente si no puedes soportarlo.

Tres micro-historias corporativas (anonimizadas, dolorosamente plausibles)

Micro-historia 1: El incidente causado por una suposición equivocada

Un equipo de producto migró su endpoint público de API detrás de una pasarela de seguridad. El plan de migración parecía “seguro” porque no cambiaron
IPs; simplemente actualizaron DNS. El original api.example.com pasó a ser un CNAME al hostname de la pasarela.

La suposición equivocada: “DNS es básicamente instantáneo.” Tenían pruebas de carga para throughput, latencia en la pasarela y rendimiento de la base de datos de backend.
No probaron clientes en arranque frío a escala—pods nuevos arrancando, pools de conexión vacíos, cachés frías. El comportamiento real del sistema estuvo
dominado por búsquedas DNS repetidas durante el establecimiento de conexiones.

La cadena terminó teniendo tres CNAMEs porque el proveedor de la pasarela usaba un alias regional, que luego apuntaba a un alias por POP, que
finalmente devolvía A/AAAA. Los TTL del proveedor eran de 30–60 segundos. Bajo carga sostenida estaba bien. Durante una ola de despliegue, la flota
empezó a resolver agresivamente. La QPS de los resolvers recursivos se disparó, luego la latencia de resolución se disparó, luego la latencia de petición se disparó,
y finalmente los timeouts del cliente se convirtieron en reintentos. Bucle clásico de realimentación positiva.

El incidente parecía “la pasarela está lenta.” No lo estaba. La pasarela estaba inactiva. DNS era el punto de estrangulamiento, y nadie quería creerlo
porque, culturalmente, DNS es algo que solo tocas cuando compras un dominio.

La solución no fue heroica. Colapsaron la cadena usando un hostname “directo” proporcionado por el proveedor para clientes API de alta QPS, aumentaron TTL
donde fue posible, y escalaron la flota de resolvedores internos. La verdadera victoria fue añadir un punto en la lista de comprobación de despliegue:
medir la latencia de búsqueda DNS en pods fríos para cada hostname crítico.

Micro-historia 2: La optimización que salió mal

Marketing quería “conmutación instantánea” entre dos CDNs, además de un WAF y un servicio de optimización de imágenes. Alguien sugirió una indirección DNS elegante:
CNAME a todo, TTLs bajos, y dejar que los proveedores enruten dinámicamente. Sonaba moderno. También era un sándwich de dependencias.

Construyeron: assets.example.com CNAME a un gestor de tráfico, que hacía CNAME al WAF, que hacía CNAME al CDN elegido, que hacía CNAME a un nombre de edge regional.
En papel son solo alias. En práctica es una cadena entre varios proveedores con diferentes características de fallo y distintas ideas de lo que significa “TTL de 60 segundos.”

El fracaso ocurrió durante un incidente de proveedor que ni siquiera fue una caída total: los servidores autoritativos de un proveedor eran accesibles pero lentos.
Los resolvers recursivos empezaron a agotar timeouts y reintentar. Algunos devolvieron SERVFAIL, otros datos en caché obsoletos, otros cambiaron a TCP. Las experiencias
de usuario divergieron por geografía e ISP.

La parte realmente molesta: incluso después de que el proveedor se recuperó, la caché negativa y el comportamiento inconsistente de los resolvers hicieron que los síntomas persistieran.
Algunos usuarios “se arreglaron”, otros no. Llegaron olas de tickets de soporte. La compañía quemó tiempo de ingeniería haciendo diagnósticos cliente por cliente, porque la capa DNS
se había convertido en una ruleta.

Al final simplificaron: un proveedor controló el edge para ese hostname, y la conmutación por fallo pasó de “magia DNS” a un runbook controlado y probado con tiempo de conmutación medido.
El sistema dejó de ser tan ingenioso y ganó fiabilidad, que es la dirección correcta.

Micro-historia 3: La práctica aburrida y correcta que salvó el día

Un equipo de plataforma mantenía un pequeño estándar interno: cualquier hostname crítico externamente debía tener un “presupuesto de cadena DNS” documentado (máx. saltos),
y debía monitorearse con comprobaciones sintéticas de resolución desde múltiples redes. No era glamuroso. Nadie ganó premios.

Una tarde, su monitorización detectó que el tiempo de resolución de login.example.com había superado el umbral en dos regiones.
No la latencia de la app. Ni el handshake TLS. Solo resolución DNS. La alerta incluía la cadena observada y qué salto era lento.

Consultaron su inventario existente: login.example.com tenía permitido un CNAME a su propio gestor de tráfico, y luego debía terminar en registros A/AAAA que controlaban.
Eso significaba que los únicos servidores autoritativos implicados eran los suyos. Sin dependencia de terceros en la cadena. El salto lento estaba dentro del edge de su proveedor DNS para esas regiones.

Ejecutaron una contingencia aburrida: cambiar la delegación NS a su proveedor secundario (preconfigurado, probado trimestralmente), esperar propagación,
y ver cómo los tiempos de resolución bajaban. Los usuarios apenas lo notaron. El incidente no llegó a ser una caída completa.

La “salvación” no fue el cambio en sí. Fue que habían limitado la indirección CNAME para el hostname más crítico y habían ensayado una conmutación DNS.
Lo aburrido vuelve a ganar.

Broma #2: DNS es el único lugar donde añadir “solo un alias” puede convertirse en una novela de suspense con múltiples autores y sin editor.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: picos aleatorios en la latencia de la API que no coinciden con métricas de backend

Causa raíz: La resolución DNS está en la ruta de la petición debido a nuevas conexiones frecuentes; una cadena CNAME con TTL corto aumenta los fallos de caché.

Solución: Reduce la profundidad de la cadena para hostnames críticos; aumenta TTLs donde sea seguro; mejora la reutilización de conexiones; añade un resolvedor local en los nodos si procede.

2) Síntoma: algunos clientes fallan mientras otros funcionan, por geografía o ISP

Causa raíz: Los servidores autoritativos del proveedor son inconsistentes o lentos en algunas regiones; los resolvers recursivos se comportan distinto; el comportamiento EDNS0 varía.

Solución: Consulta los autoritativos del proveedor directamente desde regiones afectadas; exige consistencia; considera terminar la cadena en tu propia zona con A/AAAA hacia endpoints anycast del proveedor si lo ofrecen.

3) Síntoma: aparece SERVFAIL tras un cambio DNS y luego “se arregla solo”

Causa raíz: Fallos de validación DNSSEC (firmas malas, delegación rota) o despliegue autoritativo inconsistente; la caché negativa prolonga el dolor.

Solución: Valida la cadena de confianza DNSSEC; comprueba registros DS y respuestas autoritativas; revierte rápido; mantiene TTLs sensatos durante migraciones.

4) Síntoma: la resolución funciona desde portátiles pero falla en contenedores

Causa raíz: Resolvedores diferentes (VPN/corp vs DNS del clúster), rutas de salida distintas, o diferencias en caché DNS local del nodo; la cadena golpea límites del resolvedor bajo carga.

Solución: Prueba desde el mismo entorno que la carga problemática; ajusta CoreDNS/DNS local de nodo; reduce la profundidad de la cadena; evita TTLs ultra-bajos que derrotan la caché.

5) Síntoma: “fallo temporal en resolución de nombre” durante despliegues/autoscaling

Causa raíz: Sobrecarga del resolvedor por arranques fríos súbitos; la cadena CNAME multiplica búsquedas upstream; TTL corto causa refrescos frecuentes.

Solución: Escala la flota de resolvers; añade capas de caché; escalona los despliegues; precalienta cachés DNS críticos; minimiza saltos CNAME en hostnames del hot-path.

6) Síntoma: consultas DNS cambian repentinamente a TCP y la latencia sube

Causa raíz: Respuestas grandes (cadena CNAME + DNSSEC), truncamiento o problemas de MTU/fragmentación en la ruta.

Solución: Reduce el tamaño de respuesta (acorta la cadena, elimina registros innecesarios), asegura que los resolvers soporten EDNS0 correctamente, y valida MTU/manejo de fragmentos en la red.

7) Síntoma: NXDOMAIN intermitente para un hostname que existe

Causa raíz: Inconsistencia autoritativa durante el despliegue del proveedor; el resolvedor alcanza un autoritativo retrasado y cachea la respuesta negativa.

Solución: Consulta todos los servidores autoritativos; captura evidencia; pide al proveedor que mejore la disciplina de propagación; mientras tanto, evita encadenar a través de zonas inestables para nombres críticos.

Listas de verificación / plan paso a paso

Checklist A: Decide si un CNAME es apropiado

1. ¿El hostname es crítico para la misión? (login, checkout, API, receptor de webhooks) Si es así, limita agresivamente la profundidad de la cadena.
2. ¿Controlas el siguiente salto? Si no, estás importando la disponibilidad de otro en la tuya.
3. ¿Los TTL son < 60s? Si es así, asume alta carga en resolvers y mayor latencia en la cola bajo churn.
4. ¿Necesitarás comportamiento apex? Si es así, ten cuidado con el aplanamiento; entiende qué hace tu proveedor detrás del telón.
5. ¿Puedes usar A/AAAA de forma segura? Si las IPs objetivo son estables o anycast, prefiere registros directos para endpoints críticos.

Checklist B: Reducir profundidad de cadena de forma segura (plan de migración)

1. Haz inventario de la cadena actual con dig; registra saltos y TTLs.
2. Confirma si el proveedor ofrece un endpoint estable pensado para A/AAAA directos (algunos lo hacen).
3. Baja el TTL en el registro actual antes del corte (horas/días antes, según el TTL existente).
4. Implementa el nuevo objetivo en paralelo (si es posible) y prueba desde múltiples redes.
5. Corta durante una ventana de bajo riesgo; monitoriza latencia de resolución y tasas de error.
6. Tras la estabilidad, sube el TTL a un valor sensato (a menudo minutos a horas, según tu cadencia de cambios).
7. Documenta la propiedad: quién aprueba futuras indirecciones DNS para ese nombre.

Checklist C: Monitorea la cadena como una dependencia SLO

1. Rastrea la latencia de resolución DNS (p50/p95/p99) desde redes representativas de clientes.
2. Alerta por cambio de profundidad de cadena (un cambio silencioso del proveedor puede añadir saltos).
3. Alerta por inconsistencia autoritativa (respuestas distintas entre NS).
4. Rastrea tasas de SERVFAIL/NXDOMAIN separadas de errores de la app.
5. Durante incidentes, captura: resolvedor usado, tiempo de consulta, cadena de respuesta y si fue necesario TCP.

Checklist D: Si debes mantener una cadena (por negocio)

1. Manténla corta: un salto es preferible, dos es una excepción negociada, tres es olor a diseño defectuoso.
2. Exige SLOs del proveedor para su DNS autoritativo y publica rutas de escalado.
3. Pide endpoints anycast regionales o hostnames “directos” para casos de uso API de alta QPS.
4. Haz explícita la política de TTL: TTL extremadamente bajos deben tratarse como una solicitud de rendimiento que necesita pruebas de carga.
5. Ten un plan de respaldo que controles (hostname secundario, proveedor alternativo o endpoint caché) y practícalo.

Preguntas frecuentes

1) ¿Cuántos CNAMEs son “demasiados”?

Para rutas críticas: más de uno ya es una decisión de riesgo. Más de dos debería ser raro y justificado con mediciones y monitorización.
Para nombres no críticos (páginas de marketing, hostnames de vanidad), puedes tolerar más—pero aun así vigílalo.

2) ¿Las cadenas CNAME siempre añaden latencia?

No siempre. Con cachés calientes y TTLs estables, una cadena puede ser efectivamente gratuita. El problema es que tus peores momentos (despliegues, caídas,
picos de tráfico) son precisamente cuando las cachés están frías y ocurren reintentos.

3) ¿Por qué un TTL corto empeora las cosas si es “más dinámico”?

Un TTL corto aumenta la frecuencia de consultas. Eso incrementa la carga del resolvedor y la probabilidad de que un cliente experimente un fallo de caché.
También aumenta la tasa a la que pagas la latencia autoritativa upstream.

4) ¿Deberíamos ejecutar nuestros propios resolvers recursivos en todas partes?

A veces. Resolvedores node-local o VPC-local pueden reducir latencia y protegerte de cierta flakiness upstream. Pero también te convierten en operador
de otro sistema distribuido. Si no puedes monitorizarlo y escalarlo, crearás un nuevo modo de fallo.

5) ¿Qué hay del aplanamiento de CNAME?

El aplanamiento es una función del proveedor que devuelve A/AAAA en el apex mientras configuras un alias tipo CNAME. Puede reducir la profundidad visible
por el cliente, pero desplaza la complejidad al proveedor y puede cambiar el comportamiento de TTL. Trátalo como una característica de producto con compensaciones,
no como una comida gratis.

6) ¿Las cadenas CNAME pueden romper TLS o certificados?

No directamente. TLS verifica el hostname al que el cliente se conecta, no el nombre objetivo del CNAME. Pero las cadenas pueden direccionar a los clientes
a endpoints distintos inesperadamente, y si la configuración del proveedor es inconsistente, puedes acabar con desajustes de certificado en la IP a la que llegaste.

7) ¿Por qué vemos NXDOMAIN para un registro que existe?

Porque DNS es distribuido y también cachea resultados negativos. Si un servidor autoritativo sirve brevemente NXDOMAIN (problema de propagación, split brain),
los resolvers pueden cachearlo por un tiempo. Ese “tiempo” lo definen los ajustes SOA y la política del resolvedor, no tu paciencia.

8) ¿Cómo pruebo ante un proveedor que su DNS es lento?

Consulta sus servidores autoritativos directamente (por nombre), registra tiempos de consulta desde regiones afectadas y muestra inconsistencias entre su conjunto NS.
Aporta marcas temporales, el nombre consultado y si UDP vs TCP cambió resultados.

9) ¿Las cadenas CNAME afectan la caché en CDNs y navegadores?

Los navegadores y los resolvedores stub del OS cachean de forma distinta, a menudo con sus propios límites y comportamientos. La complejidad principal de caché está
en los resolvers recursivos, pero el comportamiento del cliente puede amplificar problemas—especialmente cuando las apps evitan el caché del OS o crean contextos frecuentes de búsqueda.

10) ¿Reemplazar CNAME por A/AAAA siempre es mejor?

Es mejor para rendimiento y fiabilidad cuando las IPs del endpoint son estables y puedes operar cambios de forma segura. Es peor cuando el proveedor cambia IPs sin aviso,
o cuando pierdes lógica de enrutamiento que realmente necesitas. Si usas A/AAAA, estás aceptando más responsabilidad operativa.

Próximos pasos (los que reducen el ruido del pager)

Las cadenas CNAME no son malas per se. Son solo indirectas, y la indirecta es cómo escalamos la complejidad sin admitir que lo hicimos.
El problema comienza cuando una cadena se vuelve larga, dinámica y propiedad de un proveedor—entonces deja de ser “configuración DNS” y pasa a ser un grafo de dependencias en tiempo de ejecución.

Pasos prácticos que puedes hacer esta semana:

1. Inventario de hostnames críticos y registra su profundidad de cadena y TTLs.
2. Mide la latencia de resolución DNS (p50/p95/p99) desde las mismas redes que usan tus usuarios y cargas.
3. Fija un presupuesto: un salto CNAME para nombres críticos salvo excepción por escrito.
4. Simplifica a los peores: colapsa cadenas, prefiere endpoints estables o termina la indirección en zonas que controlas.
5. Monitorea la deriva de cadena: los proveedores cambian comportamiento DNS sin avisar, claro que lo hacen.
6. Ensaya una contingencia DNS para un hostname crítico. La primera vez que lo practiques no debería ser durante un incidente.

Si aprendes solo una lección: cuando tu sistema depende de DNS a escala, trata DNS como infraestructura de producción, no como un formulario que rellenas una vez al año.