Supervisión DNS: Alertas antes de que los usuarios las noten (comprobaciones simples y efectivas)

Qué estás realmente supervisando (y por qué el DNS te engaña)

La supervisión de DNS suena a una sola cosa. En producción son al menos cuatro:
DNS autoritativo (tu zona se sirve correctamente),
resolución recursiva (los usuarios realmente pueden resolverla),
corrección de registros (las respuestas apuntan al lugar correcto),
y seguridad en los cambios (no lo rompes durante las actualizaciones).

La mayor trampa es pensar que “DNS está arriba” es booleano. DNS es un sistema distribuido, con caché y dependiente del tiempo. Puede estar “arriba” en un país y “caído” en otro.
Puede estar “arriba” para el registro exacto que probaste y “caído” para el registro que usan tus clientes móviles. Puede estar “arriba” para clientes con caché caliente y “caído”
para resolvers nuevos. Y puede estar “arriba” hasta que expire el TTL, momento en que se vuelve muy abajo, muy rápido.

Las cuatro capas que fallan de forma diferente

• Servidores de nombres autoritativos: Tu conjunto de NS responde consultas para tu zona. Las fallas aparecen como SERVFAIL, timeouts, respuestas incorrectas, delegaciones “lame”, errores de DNSSEC.
• Capa de delegación (registrador + zona padre): La zona padre apunta a tus registros NS y glue. Las fallas se muestran como resolución intermitente o NXDOMAIN total según el caché.
• Resolvers recursivos: Lo que la mayoría de usuarios realmente golpea (resolvers ISP, públicos, empresariales). Las fallas aparecen como retrasos, respuestas obsoletas o picos de SERVFAIL.
• Comportamiento del cliente: Las apps hacen su propio cacheo, algunas ignoran TTL, algunas prefieren IPv6, otras compiten A y AAAA de forma distinta. Las fallas aparecen como incidentes de “me funciona en mi portátil”.

Supervisa al menos dos perspectivas: corrección autoritativa y experiencia recursiva del usuario. Si solo haces una,
tus alertas serán o bien tardías (solo autoritativa) o vagas (solo recursiva).

Una cita porque es operativamente cierta: “La esperanza no es una estrategia.” — Vince Lombardi.
Los ingenieros no la inventaron, pero seguro que la practicamos.

Broma #1: DNS es como un chat grupal—un participante equivocado (registro NS) y de repente nadie puede encontrarte, pero de algún modo sigue siendo tu culpa.

Datos interesantes sobre DNS que importan en incidentes

Algunas “trivialidades” se vuelven prácticas cuando diagnosticas una caída rara. Aquí hay hechos concretos que suelen aparecer en los postmortems.

1. DNS se especificó a principios de los años 80 para reemplazar el modelo centralizado HOSTS.TXT. Por eso es descentralizado y cacheado por diseño, y por eso depurar es inherentemente distribuido.
2. UDP sigue siendo el transporte por defecto para la mayoría de consultas DNS porque es barato y rápido. Eso también significa que la pérdida de paquetes, la fragmentación y las peculiaridades del MTU pueden parecer “DNS caído.”
3. EDNS(0) existe porque las cargas útiles clásicas eran demasiado pequeñas. Permite a los resolvers anunciar tamaños UDP mayores, lo que interactúa con firewalls que odian “DNS grande.”
4. El fallback a TCP no es opcional en la vida real. La truncación (TC=1) fuerza TCP; si tu red bloquea TCP/53, algunas respuestas fallarán de forma intermitente.
5. El caché negativo existe. Las respuestas NXDOMAIN pueden cachearse según el TTL negativo del SOA. Una mala configuración breve puede perseguirte más tiempo del que mereces.
6. TTL es orientativo, no una ley moral. Muchos resolvers y clientes recortan TTL (mín./máx.), y algunas aplicaciones cachean más tiempo del debido.
7. Los registros glue existen porque los nameservers también necesitan nombres. Si los nombres NS están dentro de la zona que sirven, el glue en la zona padre evita dependencias circulares.
8. DNSSEC trata de autenticidad, no de disponibilidad. Cuando falla (DS incorrecto, firmas expiradas), a menudo falla “duro” para resolvers que validan y parece una caída aleatoria.
9. La infraestructura root y TLD está diseñada para resiliencia (anycast, distribución masiva). La mayoría de las interrupciones de DNS son autoinfligidas en la capa de delegación o de zona.

SLI y diseño de alertas que no te arruinen la vida

El objetivo no es producir gráficas. El objetivo es detectar fallos de resolución que afecten a usuarios temprano, y enrutar la alerta a una persona que pueda actuar.
Eso significa que necesitas SLIs que representen fallo y latencia en lugares que coincidan con la realidad.

Elige SLIs que se mapeen al dolor del usuario

• Tasa de éxito recursiva: porcentaje de consultas que devuelven una cadena válida A/AAAA/CNAME dentro de un plazo desde múltiples puntos de observación.
• Latencia recursiva: p50/p95 del tiempo de consulta hacia resolvers recursivos (o los tuyos). Los picos suelen preceder a las fallas.
• Disponibilidad autoritativa: tasa de éxito y latencia al consultar cada NS autoritativo directamente.
• Corrección de la respuesta: los registros devueltos coinciden con los objetivos esperados (rangos IP, CNAMEs, hosts MX) y límites de TTL esperados.
• Distribución de RCODE: picos en SERVFAIL, NXDOMAIN, REFUSED son señales tempranas de humo.

Reglas de alerta que cuesta poco odiar

Un conjunto práctico:

• Pager por fallo que impacta usuarios: recursiva < 99.5% durante 5 minutos en al menos dos regiones, para nombres críticos.
• Ticket por subida de latencia: recursiva p95 > 250 ms durante 15 minutos, o aumento súbito 3× respecto a la línea base.
• Pager por errores autoritativos: cualquier NS autoritativo con timeouts > 20% durante 5 minutos, o detección de discrepancia SOA/NS.
• Ticket por deriva de corrección: cambios inesperados en IP/CNAME, TTL fuera de política, falta de AAAA donde se requiere, firma DNSSEC próxima a expirar.

Mantén una lista corta de “nombres que importan”: login, api, www, mail y lo que tu app móvil tenga codificado. Supervisa esos como si realmente importaran.
Luego supervisa la salud de la zona (SOA/NS/DNSKEY) como si fueras quien va a despertarse si se rompe. Porque lo serás.

Comprobaciones DNS simples y efectivas (con comandos reales)

No necesitas una plataforma elegante para empezar. Necesitas comandos repetibles, salidas esperadas y decisiones explícitas.
Abajo hay tareas prácticas que puedes ejecutar desde un host Linux con dig, delv y herramientas básicas.
Los comandos son deliberadamente directos. Deben funcionar cuando tu cerebro está funcionando a medias.

Task 1: Confirmar que la resolución recursiva funciona (línea base)

cr0x@server:~$ dig +time=2 +tries=1 www.example.com A

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 www.example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5312
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.                IN      A

;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:00:00 UTC 2025
;; MSG SIZE  rcvd: 59

Qué significa: Recibiste NOERROR, un registro A y un tiempo de consulta. Esta es la línea base de “la mayoría de cosas están bien”.
Decisión: Si esto falla, deja de adivinar. Tienes un problema en la ruta del resolver, no un problema de la aplicación.

Task 2: Forzar un resolver recursivo público conocido (comparar rutas)

cr0x@server:~$ dig @1.1.1.1 +time=2 +tries=1 www.example.com A

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4011
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10
;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

Qué significa: Si el local falla pero un resolver público funciona, tu stub resolver local, DNS corporativo o ruta de red está rota.
Decisión: Enruta al equipo que controla la infraestructura de resolvers/VPN/edge.

Task 3: Consultar cada nameserver autoritativo directamente (¿está vivo el DNS autoritativo?)

cr0x@server:~$ dig +norecurse @ns1.example.net example.com SOA

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1209
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
;; Query time: 14 msec

Qué significa: La bandera aa indica que el servidor es autoritativo y responde. Se ve el serial del SOA.
Decisión: Si un NS hace timeout o devuelve seriales SOA distintos a los de otros, probablemente tengas problemas de propagación/transferencia de zona o un nodo anycast muerto.

Task 4: Verificar que todos los NS coinciden en el serial SOA (comprobación de consistencia)

cr0x@server:~$ for ns in ns1.example.net ns2.example.net ns3.example.net; do echo "== $ns =="; dig +norecurse +time=2 +tries=1 @$ns example.com SOA +short; done
== ns1.example.net ==
ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
== ns2.example.net ==
ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300
== ns3.example.net ==
ns1.example.net. hostmaster.example.com. 2025123009 3600 600 1209600 300

Qué significa: ns3 está atrasado (serial más antiguo). Eso puede causar respuestas diferentes según qué NS sea consultado.
Decisión: Trátalo como un incidente de corrección. Arregla la distribución/transferencia de zona o tu pipeline de despliegue; no lo minimices con “se pondrá al día”.

Task 5: Validar la delegación desde la zona padre (capturar delegación lame y problemas de glue)

cr0x@server:~$ dig +trace example.com NS

; <<>> DiG 9.18.24 <<>> +trace example.com NS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21044
...
example.com. 172800 IN NS ns1.example.net.
example.com. 172800 IN NS ns2.example.net.
example.com. 172800 IN NS ns3.example.net.
;; Received 117 bytes from a.gtld-servers.net#53(a.gtld-servers.net) in 28 ms

Qué significa: Puedes ver la cadena de delegación. Si se detiene, hace bucles o apunta al conjunto NS equivocado, tu delegación/registrador está mal.
Decisión: Si el NS de la zona padre es incorrecto, cambiar tu archivo de zona no servirá. Arregla la delegación en el registrador/proveedor DNS.

Task 6: Comprobar cadenas CNAME y respuestas “parece bien pero no lo está”

cr0x@server:~$ dig www.example.com +noall +answer

www.example.com. 60 IN CNAME www.example.cdn-provider.net.
www.example.cdn-provider.net. 20 IN A 198.51.100.77

Qué significa: El nombre visible al usuario depende del DNS de otro dominio. Si ese proveedor tiene problemas, tú lo heredas.
Decisión: Supervisa tanto el nombre vanity como el objetivo del proveedor. Alerta si falla cualquiera, porque a los usuarios no les importa de quién es la culpa.

Task 7: Medir el tiempo de consulta explícitamente (SLI de latencia desde shell)

cr0x@server:~$ dig @1.1.1.1 www.example.com A +stats +time=2 +tries=1 | tail -n 5
;; ANSWER SECTION:
www.example.com.         60      IN      A       203.0.113.10

;; Query time: 312 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

Qué significa: 312 ms es alto para muchas regiones. Puede ser transitorio o pérdida de paquetes forzando reintentos en otra parte.
Decisión: Si p95 está subiendo, no esperes a SERVFAIL. Comienza a verificar path MTU, cambios de firewall, carga del resolver y comportamiento EDNS.

Task 8: Detectar truncamiento y problemas de fallback a TCP

cr0x@server:~$ dig @8.8.8.8 DNSKEY example.com +dnssec +time=2 +tries=1

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6512
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message truncated

Qué significa: La bandera tc indica truncamiento; el resolver reintentará por TCP. Si TCP/53 está bloqueado, los resolvers validadores pueden fallar gravemente.
Decisión: Prueba TCP explícitamente y abre TCP/53 donde sea necesario (especialmente para respuestas pesadas en DNSSEC).

Task 9: Probar DNS sobre TCP explícitamente (demostrar que el firewall no lo bloquea)

cr0x@server:~$ dig +tcp @8.8.8.8 DNSKEY example.com +dnssec +time=2 +tries=1 +stats | tail -n 6
;; ANSWER SECTION:
example.com.  1800 IN DNSKEY 257 3 13 rX9W...snip...
example.com.  1800 IN DNSKEY 256 3 13 dE2Q...snip...

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (TCP)

Qué significa: TCP funciona; el truncamiento es soportable. Si TCP falla, verás timeouts.
Decisión: Si UDP funciona pero TCP falla, arregla la red. Si ambos fallan, arregla DNS o el enrutamiento.

Task 10: Comprobar comportamiento de caché negativo (NXDOMAIN que persiste)

cr0x@server:~$ dig +noall +authority does-not-exist.example.com A

example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 3600 600 1209600 300

Qué significa: Las respuestas NXDOMAIN incluyen el SOA de la zona; el último campo (aquí 300) es el TTL de caché negativo.
Decisión: Si por error eliminaste un registro y lo restauraste, espera que algunos clientes sigan fallando hasta que expire el TTL negativo. Planea los cambios en consecuencia.

Task 11: Validar DNSSEC con una herramienta que valide (separa “DNS está arriba” de “DNS es válido”)

cr0x@server:~$ delv @1.1.1.1 example.com A

; fully validated
example.com. 300 IN A 203.0.113.20

Qué significa: “fully validated” indica que la cadena DNSSEC valida desde los trust anchors.
Decisión: Si la validación falla, trátalo como alta severidad para usuarios detrás de resolvers validadores (muchas empresas). Arregla DS/DNSKEY/RRSIG rápidamente.

Task 12: Detectar TTL demasiado bajos (carga autoinfligida y jitter)

cr0x@server:~$ dig +noall +answer api.example.com A

api.example.com. 5 IN A 203.0.113.44

Qué significa: Un TTL de 5 segundos es efectivamente “por favor DDoS a mis servidores autoritativos con tráfico legítimo.”
Decisión: Aumenta el TTL a algo sensato para endpoints estables (a menudo 60–300 segundos para frontales dinámicos, más largo para estáticos). Usa TTL bajos solo con un plan.

Task 13: Verificar comportamiento de registros múltiples (A y AAAA pueden fallar independientemente)

cr0x@server:~$ dig www.example.com A AAAA +noall +answer

www.example.com. 60 IN A 203.0.113.10
www.example.com. 60 IN AAAA 2001:db8:abcd::10

Qué significa: Hay doble pila en juego. Si AAAA está mal o apunta a una ruta rota, algunos clientes preferirán IPv6 y “fallarán aleatoriamente”.
Decisión: Supervisa tanto A como AAAA y su accesibilidad. Si no puedes operar IPv6, no publiques AAAA “para más adelante”.

Task 14: Comprobar sorpresas de split-horizon (respuestas internas vs externas)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer
www.example.com. 60 IN A 10.20.30.40

Qué significa: Un resolver interno devuelve una IP privada. Eso puede ser correcto (ruteo interno) o desastroso (filtrar respuestas privadas al público).
Decisión: Confirma que las vistas son intencionales. Añade supervisión desde dentro y fuera de la red para asegurar que cada audiencia obtiene la respuesta prevista.

Task 15: Confirmar identidad del servidor autoritativo (¿estás golpeando la máquina correcta?)

cr0x@server:~$ dig +norecurse @ns1.example.net version.bind TXT chaos +short
"ns1-anycast-pop3"

Qué significa: Si está habilitado, esto puede ayudar a identificar qué POP anycast te está atendiendo. No todos los proveedores lo permiten, y está bien.
Decisión: Úsalo para correlacionar errores a un POP o backend específico. Si está deshabilitado, no lo forces; confía en la latencia, traceroutes y la herramienta del proveedor.

Task 16: Capturar RCODEs y timeouts a escala (convierte comprobaciones ad-hoc en métricas)

cr0x@server:~$ for i in $(seq 1 20); do dig @1.1.1.1 +time=1 +tries=1 www.example.com A +noall +comments; done | egrep "status:|Query time:"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34325
;; Query time: 18 msec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2462
;; Query time: 21 msec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 991
;; Query time: 1001 msec

Qué significa: Un SERVFAIL en una pequeña muestra ya es sospechoso. Si ves SERVFAILs intermitentes con ~1s de tiempo, estás golpeando timeouts y reintentos.
Decisión: Trata los errores intermitentes como reales. Se convierten en interrupciones bajo carga o cuando expiran los cachés.

Broma #2: El cacheo DNS es el único lugar donde “funcionó hace cinco minutos” es una característica de diseño, no una confesión.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando el DNS está en llamas, la velocidad importa. No porque seas héroe, sino porque el caché hace que el radio de impacto dependa del tiempo. Aquí está el orden que encuentra los cuellos de botella rápido.

Primero: ¿es experiencia de usuario o autoritativo?

1. Consulta un resolver recursivo público desde al menos dos redes. Si falla de forma amplia, probablemente sea autoritativo/delegación o DNSSEC.
2. Consulta tus NS autoritativos directamente con +norecurse. Si la autoritativa directa está bien pero la recursión falla, es un problema del ecosistema de resolvers (o validación DNSSEC).
3. Revisa la distribución de RCODE: NXDOMAIN vs SERVFAIL vs timeout. Cada uno apunta a causas distintas.

Segundo: Identifica la clase de fallo

• Timeouts: ruta de red, firewall, mitigación DDoS que se disparó mal, problema de POP anycast, pérdida de paquetes upstream.
• SERVFAIL: fallo de validación DNSSEC, respuesta autoritativa rota, resolver incapaz de alcanzar NS, delegación lame, fallo de backend.
• NXDOMAIN: registro eliminado, zona equivocada desplegada, error tipográfico en el nombre, caché negativo extendiendo el impacto.
• Respuesta incorrecta: zona desactualizada en un NS, fuga de vistas, automatización errónea, objetivo CNAME cambiado, configuración comprometida.

Tercero: Localiza dónde en la cadena falla

1. Ejecuta +trace para ver la delegación y dónde se detiene.
2. Compara el serial SOA en todos los NS autoritativos. Los seriales inconsistentes explican “solo algunos usuarios”.
3. Prueba UDP y TCP (especialmente para DNSKEY/respuestas grandes). Truncamiento + TCP bloqueado es clásico.
4. Valida DNSSEC con delv. Si la validación falla, tu zona puede parecer “bien” para resolvers no validadores mientras que empresas no pueden resolverte en absoluto.

Si haces esos pasos en ese orden, evitas las dos pérdidas de tiempo más comunes: mirar logs de aplicaciones cuando la resolución de nombres falla, y discutir sobre “propagación”
cuando en realidad tienes estado autoritativo inconsistente.

Tres micro-historias corporativas desde las trincheras DNS

Micro-historia 1: La caída causada por una suposición errónea

Una empresa SaaS de tamaño medio migró su sitio de marketing a un nuevo CDN. La petición de cambio era simple: sustituir un A por un CNAME,
bajar el TTL para el corte, y listo. El ingeniero asumió que “si el CNAME resuelve para mí, resuelve para todo el mundo.”
Esa suposición ha terminado muchas noches tranquilas.

El corte se veía bien desde la red de la oficina. Se veía bien desde un resolver público. Pero clientes empresariales empezaron a reportar fallos:
los navegadores se quedaban colgados por un rato y luego tiraban la toalla. El canal de incidentes se llenó de capturas y conjeturas. La aplicación estaba sana; el origen estaba sano; TLS estaba sano.
El único factor común era “no pueden acceder al sitio.”

Resultó que el nombre objetivo del CDN devolvía un conjunto grande de registros con DNSSEC, provocando truncamiento. Algunas redes empresariales permitían UDP/53 pero bloqueaban TCP/53
(sí, aún sucede). Para esos usuarios, el resolver recursivo veía TC=1, intentó TCP, fue bloqueado y devolvió SERVFAIL. Los usuarios domésticos nunca notaron nada porque sus resolvers podían usar TCP.

La solución no estuvo en la pila web. Fue una solución de política y supervisión: probar DNS sobre TCP en comprobaciones sintéticas, monitorizar tasas de SERVFAIL desde puntos “corporativos”,
y añadir un paso previo para “¿este cambio aumenta el tamaño de la respuesta o la complejidad de DNSSEC?”. La suposición murió. Producción mejoró.

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

Otra compañía gestionaba su DNS autoritativo en un par de clusters anycast. Alguien notó una fracción de latencia en consultas en frío
y decidió “optimizar DNS” poniendo TTLs a 10 segundos en todo. La teoría: conmutación por error más rápida y despliegues más ágiles.
La realidad: DNS no es un sistema de flags. Es un multiplicador de carga.

No explotó de inmediato. Eso es lo peor. Durante unos días todo pareció más ágil durante despliegues y el cambio fue alabado como “más dinámico.”
Luego un aumento de tráfico rutinario golpeó: no un DDoS, solo crecimiento normal y una campaña de marketing. Las cachés de los resolvers expiraban constantemente, el volumen de consultas autoritativas subió,
y los clusters anycast empezaron a perder paquetes bajo carga pico. Los timeouts aumentaron, luego los reintentos aumentaron, y los reintentos crearon más carga. Bucle de retroalimentación clásico.

Los usuarios sufrieron fallos intermitentes difíciles de reproducir. Algunos tenían respuestas cacheadas; otros no. La monitorización que solo comprobaba un resolver
y un nombre perdió la advertencia temprana. Costó demasiado conectar los puntos: “la optimización” estaba haciendo que DNS dependiera de un rendimiento autoritativo perfecto.

La restauración fue simple: volver a TTLs sensatos (60–300 segundos para frontales; más largos donde fuera posible), y añadir alertas basadas en tasas QPS y errores en autoritativos.
También mantuvieron un pequeño conjunto de registros de TTL bajo para escenarios reales de failover, con control de cambios. La lección: optimiza para resiliencia, no para la gratificación de cambios rápidos.

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

Una empresa con varias unidades de negocio tenía una costumbre que sonaba aburrida: cada cambio DNS requería una “validación de dos vistas” y una “validación con dos recursivos.”
Eso significaba comprobar respuestas internas y externas, y comprobar al menos dos resolvers recursivos (uno corporativo, uno público).
Estaba documentado, se aplicaba en las revisiones de código y a veces se burlaban como burocracia.

Un viernes, un equipo añadió un nuevo nombre interno para un servicio. El cambio debía aterrizar solo en la vista interna,
pero una variable de plantilla se configuró mal. El registro se añadió también a la zona externa, apuntando a una dirección privada RFC1918.
Si eso se hubiera filtrado ampliamente, los usuarios externos intentarían conectarse a una IP no enrutable—mejor caso un timeout, peor caso golpear algo no previsto en su propia red.

Las comprobaciones previas lo captaron en minutos. La comprobación externa vio un registro A privado y falló en alto. El cambio se revirtió antes de que los cachés se propagaran.
El ticket de incidente nunca llegó a ser un incidente de cliente. El equipo pudo disfrutar su fin de semana, que es el verdadero KPI de SRE.

La práctica aburrida no era glamorosa. Era validación específica y repetible que coincidía con modos de fallo conocidos. No evitó los errores.
Evitó que los errores se convirtieran en caídas.

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

Los incidentes DNS se repiten. También los errores. Aquí los comunes con mapeo claro desde lo que ves hasta qué hacer.

1) Síntoma: “Funciona para mí, roto para usuarios”

• Causa raíz: respuestas cacheadas en tu red; algunos resolvers aún tienen datos antiguos; NS autoritativos inconsistentes; diferencias de split-horizon.
• Solución: compara el serial SOA en todos los NS autoritativos; consulta múltiples resolvers recursivos; baja el TTL antes de migraciones planeadas, no durante emergencias.

2) Síntoma: SERVFAIL intermitente, especialmente en empresas

• Causa raíz: validación DNSSEC fallando (RRSIG expirado, DS incorrecto), o truncamiento que requiere TCP y está bloqueado.
• Solución: ejecuta delv para validar; prueba dig +tcp; arregla el proceso de rollover DS/DNSKEY; asegura TCP/53 end-to-end.

3) Síntoma: picos de NXDOMAIN tras un despliegue

• Causa raíz: registro eliminado/renombrado; zona equivocada desplegada; error tipográfico en el nombre; caché negativo extiende el impacto.
• Solución: restaura el registro; confirma incremento serial SOA; entiende el TTL negativo en el SOA; monitoriza tasa de NXDOMAIN por nombre.

4) Síntoma: Resolución lenta pero no falla

• Causa raíz: pérdida de paquetes; resolvers sobrecargados; conectividad upstream; problemas de tamaño EDNS UDP que causan reintentos/fallback.
• Solución: mide latencia p95; prueba con distintos resolvers; verifica truncamiento; ajusta tamaño de buffer EDNS si controlas resolvers; arregla pérdida de red.

5) Síntoma: Solo usuarios IPv6 fallan (o solo algunas redes móviles)

• Causa raíz: registro AAAA roto o enrutamiento IPv6 defectuoso; clientes prefieren IPv6; accesibilidad asimétrica.
• Solución: monitoriza AAAA por separado; valida accesibilidad de endpoints IPv6; elimina AAAA si no lo puedes soportar (temporalmente, con plan).

6) Síntoma: Un registro específico falla, todo lo demás bien

• Causa raíz: problema en el dominio objetivo del CNAME; registro demasiado grande; tipo de registro incorrecto; interacciones con wildcard.
• Solución: monitoriza y prueba toda la cadena; mantén conjuntos de registros pequeños; evita wildcards complejos a menos que disfrutes el misterio.

7) Síntoma: Algunos resolvers reciben REFUSED

• Causa raíz: ACLs en servidores autoritativos; limitación de tasa demasiado agresiva; geo-bloqueo; vistas mal configuradas.
• Solución: revisa ACLs y políticas de respuesta; ajusta RRL; prueba desde múltiples regiones; no bloquees resolvers recursivos que no controlas salvo por requerimiento legal.

8) Síntoma: Cambios de zona “se revierten” o difieren entre NS

• Causa raíz: múltiples fuentes de verdad; despliegues parciales; NOTIFY/AXFR/IXFR rotos; ediciones manuales en un nodo.
• Solución: aplica una única fuente de verdad; automatiza despliegues; audita zonas entre NS; alerta inmediatamente por discrepancia SOA.

Listas de verificación / plan paso a paso

A. Construir un conjunto mínimo de supervisión DNS (una tarde, sin drama)

1. Elige 5–10 nombres críticos: www, api, login, mail, además de endpoints móviles.
2. Para cada nombre, define respuestas esperadas: rangos A/AAAA, objetivos CNAME, hosts MX, límites de TTL.
3. Ejecuta comprobaciones recursivas desde al menos dos redes (región cloud A y B; o cloud + on-prem).
4. Ejecuta comprobaciones autoritativas contra cada NS directamente con +norecurse.
5. Alerta ante fallos: timeouts, SERVFAIL, respuestas incorrectas y discrepancia serial SOA.
6. Paneliza RCODEs y latencia por nombre, no solo agregado para toda la zona.

B. Hacer los cambios DNS más seguros (el plan de “no ser ingenioso”)

1. Baja el TTL antes de migraciones planeadas (horas o un día antes), no en medio de una emergencia.
2. Usa despliegues por etapas: valida primero en un nombre canario (p. ej., canary-api).
3. Validación de dos vistas: las respuestas internas y externas deben ser intencionalmente distintas, nunca por accidente.
4. Validación con dos recursivos: prueba tanto la ruta de resolver corporativo como un resolver público.
5. Disciplina de serial SOA: aplica seriales monótonos y alerta por mismatch entre NS.
6. Higiene DNSSEC: monitoriza expiración de firmas y rollovers DS/DNSKEY con runbooks explícitos.

C. Enrutamiento de alertas listo para producción

1. Pagea al equipo que puede arreglarlo: equipo proveedor DNS, equipo de red o equipo de plataforma. Si la alerta no puede accionarse, es ruido.
2. Incluye comandos inmediatos en la alerta: “Ejecutar dig +trace”, “Consultar cada NS por SOA”, “Ejecutar delv”.
3. Incluye esperado vs real en el payload de la alerta: detalle de mismatch de registros, valores TTL y qué resolvers fallaron.
4. Correlaciona con ventanas de cambio: los incidentes DNS suelen correlacionarse con cambios; tu alerta debería mostrar pushes de DNS recientes.

Preguntas frecuentes

1) ¿Debo monitorizar DNS desde dentro de mi VPC, desde internet público o ambos?

Ambos. Internamente detectas errores de split-horizon y problemas de resolvers en tu entorno. Externamente ves lo que perciben los clientes. Una sola vista es como terminar sorprendido.

2) ¿Cuál es la comprobación DNS más valiosa?

Consultar cada nameserver autoritativo por el SOA y comparar seriales. Es la forma más rápida de detectar despliegues parciales, transfers rotos y problemas de “algunos usuarios”.

3) ¿No es suficiente con hacer dig desde una sola máquina?

No. Las fallas DNS suelen ser regionales, específicas de un resolver o dependientes del caché. Una sola máquina te da falsa confianza o pánico falso, según su caché y red.

4) ¿Cómo alerto sobre problemas de “propagación”?

Deja de llamarlo propagación y llámalo por lo que es: estado autoritativo inconsistente o mismatch de delegación. Alerta por discrepancia de serial SOA y por respuestas diferentes entre NS.

5) ¿Qué tan bajo debe ser el TTL para frontales de balanceo de carga?

Comúnmente 60–300 segundos. Más bajo solo si tienes un procedimiento de failover probado y capacidad autoritativa para manejar mayor QPS. “5 segundos en todas partes” es olor a mala fiabilidad.

6) ¿Por qué veo SERVFAIL cuando el servidor autoritativo parece bien?

A menudo la validación DNSSEC falla en el resolver, o el resolver no puede alcanzar uno de tus NS por problemas de red. Prueba con delv y consulta cada NS directamente.

7) ¿Realmente tengo que preocuparme por TCP/53?

Sí. Respuestas DNSKEY, TXT grandes y DNSSEC pueden provocar truncamiento. Si TCP está bloqueado, algunos resolvers fallarán. Monitoriza caminos UDP y TCP.

8) ¿Cómo detecto automáticamente problemas de “respuesta incorrecta”?

Define valores esperados: objetivos CNAME, rangos IP y límites de TTL. Luego ejecuta consultas sintéticas y compara la sección de respuesta. Alerta por deriva, no solo por caídas.

9) ¿Qué hay de DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT)?

Si tu base de usuarios incluye entornos que fuerzan DoH/DoT, incluye al menos una comprobación sintética a través de esas vías. De lo contrario declararás victoria mientras los navegadores siguen fallando.

10) ¿Cuántos nombres debo monitorizar sin ahogarme en alertas?

Empieza con 5–10 nombres críticos más comprobaciones de salud de la zona. Expande solo cuando puedas explicar qué acción dispara cada alerta. Monitorizar no es coleccionar objetos.

Conclusión: siguientes pasos que puedes hacer esta semana

La supervisión DNS no necesita ser compleja. Debe ser específica. Supervisa los nombres que importan, desde más de un punto de vista, y prueba tanto recursión como autoridad.
Alerta sobre los modos de fallo que predicen dolor real: discrepancia SOA, picos de SERVFAIL, timeouts, respuestas incorrectas y fallos de validación DNSSEC.

Próximos pasos prácticos:

1. Implementa comprobaciones de consistencia de serial SOA en todos los NS autoritativos y pagea por mismatch.
2. Añade comprobaciones recursivas desde dos redes y alerta por tasa de fallo sostenida y latencia p95.
3. Añade comprobaciones UDP+TCP para al menos una consulta pesada en DNSSEC (DNSKEY) para detectar truncamiento/bloqueo TCP.
4. Define respuestas esperadas y política de TTL para tus nombres críticos, y alerta por deriva.
5. Escribe un runbook de diagnóstico rápido de una página usando la sección de la guía y adjúntalo a las alertas.

Si haces solo eso, detectarás la mayoría de los fallos DNS antes que tus clientes. Y si tienes suerte, antes que tu CEO lo sepa.