Resolutores DNS: por qué la caché empeora las interrupciones (y cómo dominarla)

Qué realmente cachea DNS (spoiler: todos)

“Caché DNS” no es una sola caché. Es una pila de cachés, cada una con sus propias reglas, bugs y opiniones. Cuando tu servicio cambia de dirección o
tus servidores autoritativos fallan, estas capas no fallan a la vez. Fallan en un desorden escalonado, específico por usuario y por geografía
que hace que las líneas de tiempo de un incidente parezcan arte moderno.

Las capas que cachean respuestas DNS

• Cachés a nivel de aplicación: navegadores, resolutores de JVM, runtimes de lenguaje y librerías que “amablemente” recuerdan respuestas.
• Resolutor stub del SO: aquello a lo que llama tu app. Puede cachear (según plataforma y configuración).
• Demonio de caché local: systemd-resolved, dnsmasq, nscd, Unbound en modo “local”, etc.
• Cachés node-local / sidecar: comunes en Kubernetes y service meshes para reducir latencia y carga.
• Resolutores recursivos: resolutores de ISP, resolutores empresariales, resolutores públicos. Son cachés grandes y compartidos.
• Reenviadores: las redes corporativas a menudo encadenan resolutores (sucursal → HQ → upstream).
• Servidores autoritativos: no son “cachés”, pero influyen en la caché vía TTL, valores SOA y comportamiento de respuesta.
• Middleboxes: sí, algunos dispositivos de “seguridad” manipulan y cachean DNS. Los paquetes nunca testificarán.

Cuando alguien dice “el TTL es 60 segundos”, deberías responder: “¿En qué capa, bajo qué modo de fallo y con qué software de resolutor?”
La respuesta correcta suele ser un suspiro largo.

Por qué la caché amplifica las interrupciones

La caché DNS es un multiplicador de fuerzas. Multiplica la fiabilidad cuando las respuestas son correctas y estables. Multiplica el dolor cuando una respuesta es incorrecta,
inexistente o temporalmente inalcanzable. La clave es que las cachés hacen que tu sistema sea con estado en Internet. Puedes revertir código en minutos;
no puedes revertir un NXDOMAIN cacheado en resolutores recursivos que no controlas.

Modo de fallo #1: las respuestas incorrectas persisten

Publicas un registro A malo (IP tecleada mal, endpoint obsoleto, región equivocada), y has acuñado un token de interrupción distribuida. Cada resolutor recursivo
que lo ve puede retenerlo hasta que expire el TTL. Tu arreglo puede ser instantáneo en la capa autoritativa, pero el mundo ahora funciona con estado cacheado.

Modo de fallo #2: timeouts y SERVFAIL se vuelven “pegajosos”

Algunos resolutores cachean fallos, o al menos se comportan como si lo hicieran al limitar reintentos, marcar servidores como “lentos” o preferir un NS por
latencias pasadas. Durante un incidente autoritativo, los recursors pueden decidir que uno de tus servidores de nombres es “malo” y evitarlo mucho después de que vuelva a estar sano.

Modo de fallo #3: la caché negativa hace que la recuperación sea más lenta que la interrupción

Elimina un registro (o este desaparece por un despliegue malo), y los resolutores pueden cachear “no existe” (NXDOMAIN) según el SOA de la zona.
Ese TTL negativo puede ser de minutos a horas. Así que incluso después de restaurar el registro, los clientes siguen creyendo en el vacío.

Broma #1: DNS es como un rumor: una vez cacheado, la corrección nunca viaja tan rápido como el escándalo.

Modo de fallo #4: picos de carga por estampidas de caché

Cuando el TTL de un registro popular expira en muchos resolutores al mismo tiempo, obtienes una avalancha de fallos de caché. Si tus autoritativos
ya están bajo estrés, este pico puede empujarlos de “lentos” a “caídos”, creando más fallos y más picos. Es un bucle de retroalimentación.
Algunos softs de resolutor tienen prefetch y servir-estable (serve-stale) para mitigar esto, pero son perillas con aristas cortantes.

El TTL no es una promesa: las realidades sucias

TTL es el campo “cachear por tantos segundos” en un registro DNS. Los operadores lo tratan como un contrato. No lo es. Es una sugerencia, y diferentes capas
lo interpretan según política.

Maneras comunes en que el TTL se “ajusta” en la práctica

• Aplicación de TTL mínimo: algunos resolutores empresariales y públicos imponen un suelo (por rendimiento y resistencia al abuso).
• Aplicación de TTL máximo: otros imponen un techo (para que no se cachee por días).
• Cachés locales ignorando TTL bajos: ciertos resolutores stub y apps mantienen respuestas más tiempo que el TTL.
• Reutilización de conexiones y pooling de apps: las apps pueden resolver sólo al inicio, creando efectivamente un TTL infinito hasta reinicio.
• Happy Eyeballs y lógica de fallback: los clientes pueden elegir una familia de direcciones (A vs AAAA) y mantenerse con ella incluso tras cambios DNS.
• Memoria en la selección de servidores autoritativos: los recursivos rastrean qué servidores autoritativos respondieron y los prefieren.

Si quieres conmutación por error basada en DNS, trátalo como un problema de sistemas distribuidos, no como un interruptor mágico. DNS puede enrutar alrededor del daño,
pero no proporciona convergencia sincronizada. Diseña para “un porcentaje de clientes estará equivocado por un tiempo”.

Una línea guía que vale la pena mantener en una nota adhesiva es una idea parafraseada atribuida a Werner Vogels: Todo falla, todo el tiempo; diseña en consecuencia.
No es una cita de DNS, pero DNS es donde esa filosofía se audita contra la realidad.

Caché negativa: cuando “no existe” perdura

El cacheo de NXDOMAIN es el alargador de interrupciones menos apreciado. Piensas “arreglamos el registro.” Tus clientes siguen obteniendo “host no encontrado.”
¿Por qué? Porque “no encontrado” es cacheable.

Cómo funciona la caché negativa

Cuando un resolutor recibe NXDOMAIN (nombre no existe) o NODATA (el nombre existe pero no de ese tipo), puede cachear la respuesta negativa.
El TTL para esa caché se deriva del registro SOA de la zona, específicamente del campo SOA MINIMUM (históricamente) y/o del comportamiento del SOA
según estándares e implementaciones modernas. En términos operativos: tus ajustes de SOA importan incluso cuando no tocas SOA.

Dos consecuencias prácticas

• Un registro ausente brevemente puede quedarse. Si tu despliegue elimina accidentalmente un registro A durante 30 segundos, los resolutores pueden recordar esa
  ausencia durante minutos o más.
• Los registros nuevos “propagan” lento si los clientes consultaron demasiado pronto. Lanzar un subdominio nuevo y anunciarlo antes de que exista es un clásico
  pie en la trampa: las primeras consultas siembran cachés negativas.

La solución no es “poner todo con TTL 0”. La solución es controlar los TTL negativos, planificar los cortes y usar técnicas para romper cachés cuando sea necesario.

Pilas de resolutores en el mundo real (Linux, macOS, Windows, contenedores)

La frase “check /etc/resolv.conf” es el equivalente SRE de “¿has probado apagarlo y encenderlo otra vez?”. No está mal; solo está incompleta.
Los sistemas modernos pueden encaminar DNS a través de un stub local (127.0.0.53), un plugin VPN, un agente corporativo o el runtime del contenedor.

Linux: systemd-resolved y compañía

Muchas distribuciones usan systemd-resolved, que puede cachear y también implementar DNS dividido para VPNs. /etc/resolv.conf puede apuntar a 127.0.0.53, que no es
tu resolutor real; es un stub local que reenvía upstream. Al depurar, necesitas inspeccionar tanto el stub como la configuración upstream.

macOS: mDNSResponder y DNS por interfaz

macOS mantiene ajustes DNS por interfaz. Puedes estar “en la misma Wi‑Fi” y aún así tener comportamiento de resolutor distinto porque una máquina también tiene un perfil VPN
instalado. Vaciar cachés ayuda, pero el paso más importante es confirmar qué resolutores están siendo consultados.

Windows: servicio DNS Client y NRPT

Windows cachea DNS en el servicio DNS Client. Las empresas también usan Name Resolution Policy Table (NRPT), especialmente con DirectAccess/VPN,
que puede dirigir ciertos dominios a resolutores específicos. Depurar requiere mirar la política, no solo la caché.

Contenedores y Kubernetes: CoreDNS y algo más

Kubernetes añade al menos una capa: CoreDNS (o kube-dns), más el resolutor del nodo, más lo que haga la imagen del contenedor. Algunos clústeres añaden NodeLocal
DNSCache para reducir la carga y latencia de CoreDNS. Esto mejora el rendimiento en estado estable y empeora algunas interrupciones al extender respuestas obsoletas más cerca de las cargas.
Estás intercambiando carga por obsolescencia. Ese intercambio puede valer la pena, pero debes medirlo.

Datos interesantes y contexto histórico (lo que muerde después)

1. DNS reemplazó HOSTS.TXT porque un archivo central no escalaba; el cacheo fue una característica desde el primer día, no una ocurrencia tardía.
2. El TTL se diseñó para controlar la carga de consultas en los servidores autoritativos; no se diseñó para soportar conmutaciones por error rápidas.
3. La caché negativa no siempre fue consistente; la estandarización evolucionó porque los resolutores tempranos se comportaban de formas muy dispares con NXDOMAIN.
4. Los resolutores rastrean servidores de nombres “lentos” y los evitan; esto es bueno… hasta que una pérdida de paquete transitoria marca tu mejor NS como “malo”.
5. Algunos resolutores limitan TTLs (tanto mínimos como máximos) por razones de política, lo que hace que las matemáticas de “propagación” sean poco fiables.
6. Los glue records pueden dejarte atascado: una delegación cacheada más glue puede mantener a los clientes yendo a IPs antiguas de NS incluso después de arreglar la zona.
7. DNSSEC aumenta los modos de fallo: una cadena de confianza rota puede convertir “me funciona” en SERVFAIL global, con caché encima.
8. EDNS0 y mayores tamaños UDP mejoraron la funcionalidad, pero también aumentaron la sensibilidad a middleboxes que descartan fragmentos o bloquean EDNS.
9. El fallback a TCP para DNS existe por una razón; si tu ruta bloquea DNS sobre TCP, respuestas grandes pueden fallar de forma intermitente.

Tres micro-historias corporativas desde las trincheras

Micro-historia #1: La interrupción causada por una suposición equivocada

Una empresa SaaS mediana planeó una migración “simple” de una API de un balanceador a otro. El plan era: bajar TTL a 60 segundos, cambiar el registro A,
monitorizar y luego subir el TTL. Hicieron la primera parte con cuidado. Esperaron un día. Cambiaron durante una ventana tranquila. Y llegaron los tickets de soporte de todos modos.

Algunos clientes seguían conectándose a la IP antigua durante horas. El equipo on-call culpó a “la propagación DNS del ISP”. El equipo de red culpó al cliente.
El equipo de aplicaciones culpó al equipo de red, porque eso es lo que hacen las aplicaciones cuando se asustan.

El problema real fue dolorosamente mundano: una integración de cliente popular estaba escrita en Java, y el comportamiento de caché DNS del runtime en esa flota era efectivamente
“cachear para siempre” a menos que se configurara de otro modo. Esos clientes resolvían una vez al inicio y luego anclaban la IP. Cambiar el TTL no hizo nada porque la app no
volvía a resolver.

La solución no fue un cambio DNS. La solución fue comunicarse con los clientes: reiniciar el servicio de integración, o configurar los parámetros TTL de la JVM.
Internamente, la empresa cambió el playbook de corte para incluir “los clientes pueden anclar DNS; proveer un endpoint alternativo durante la transición.”
DNS hizo exactamente lo que decía. La suposición no.

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

Otra empresa tenía CoreDNS bajo carga. Picos de latencia, timeouts ocasionales y una corriente constante de quejas de desarrolladores que asumían que DNS debía ser invisible.
El equipo de plataforma añadió una caché DNS node-local para reducir QPS hacia CoreDNS. Funcionó. Las gráficas mejoraron. El equipo celebró en voz baja, como hacen los ingenieros cuando no quieren que el destino lo note.

Semanas después, un proveedor autoritativo upstream tuvo una interrupción parcial. El comportamiento correcto habría sido “algunas búsquedas fallan rápido, los reintentos recuperan, y una vez que upstream sana, todo vuelve a la normalidad.”
Lo que sucedió en cambio fue un incidente a cámara lenta: las cachés node-local retuvieron fallos y respuestas intermitentes lo suficiente como para que los pods del clúster vieran resolución inconsistente mucho más tiempo que el downtime upstream.

La caché node-local también cambió la superficie de fallo del clúster. Antes, los problemas de CoreDNS estaban centralizados y eran obvios. Después, los fallos se volvieron específicos por nodo.
Algunos nodos estaban “bien”, otros “malditos”, y el scheduler felizmente colocaba cargas en nodos malditos porque había CPU disponible.

La conclusión del postmortem no fue “nunca cachear”. Fue “cachear con política explícita de serve-stale, monitorización clara y una forma de vaciar o evitar rápidamente.”
Añadieron health checks, métricas por instancia node-local y un DaemonSet de emergencia que podía reiniciar caches en todo el clúster. La optimización es genial hasta que se vuelve
lo que no puedes deshacer durante un incidente.

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

Una compañía de pagos operaba DNS autoritativo en dos proveedores. Suena sofisticado, pero lo interesante fue su disciplina aburrida: ejecutaban pruebas continuas desde
múltiples redes que consultaban ambos proveedores directamente, validaban respuestas DNSSEC y comparaban respuestas contra un conjunto esperado.

Una tarde, la monitorización alertó: las consultas a un proveedor empezaron a devolver SERVFAIL de forma intermitente para una zona firmada. Desde la mayoría de las redes cliente, todo aún parecía OK porque las cachés ocultaban el problema. La compañía no recibió informes de clientes porque la falla era joven y estaba enmascarada.

El on-call de DNS no comenzó por vaciar cachés o cambiar TTLs. Aisló qué conjunto autoritativo se comportaba mal, ajustó temporalmente la delegación para favorecer al proveedor sano y mantuvo los TTL estables.
También pausaron un despliegue planificado que iba a introducir registros nuevos, porque la caché negativa durante un bamboleo de DNSSEC es un tipo especial de miseria.

El incidente nunca se convirtió en una interrupción completa. Los clientes no se enteraron. La “práctica aburrida” no fue heroica; fue tener pruebas que evitan cachés y validan la fuente de la verdad continuamente.
El mejor incidente DNS es el que resuelves mientras todos los demás siguen convencidos de que todo está bien.

Guía rápida de diagnóstico

Cuando culpan al DNS, tu trabajo es averiguar dónde entró la mentira en el sistema: datos autoritativos, caché recursiva, caché local o la aplicación.
No tienes tiempo para filosofía. Aquí está el orden que te lleva a la causa raíz rápido.

Primero: determina si el nombre está mal en todas partes o solo para algunos clientes

• Consulta autoritativos directamente (consultar los servidores autoritativos por nombre/IP, evitando recursors).
• Consulta uno o dos recursors públicos conocidos para ver si la vista cacheada difiere.
• Revisa la ruta del resolutor del cliente afectado (¿a qué servidor está preguntando realmente?).

Segundo: clasifica el tipo de fallo

• IP incorrecta: registro obsoleto cacheado o publicación errónea.
• NXDOMAIN: registro ausente y caché negativa.
• SERVFAIL: DNSSEC, delegación rota, autoritativos inalcanzables o política del resolutor.
• Timeout: ruta de red, MTU/fragmentación, firewall o componente DNS sobrecargado.
• Intermitente: comportamiento autoritativo mixto, problemas de anycast, pérdida de paquetes o un NS marcado como lame.

Tercero: encuentra la capa de caché que es “pegajosa”

• Caché stub local (systemd-resolved, nscd, dnsmasq).
• Node-local / CoreDNS (Kubernetes).
• Reenviadores empresariales (los encadenamientos añaden estado).
• Resolutores recursivos (ISP/públicos).
• Runtime de aplicación (JVM, Go, caching personalizado).

Cuarto: decide si esperar, vaciar o rodear

• Esperar si el valor cacheado es correcto pero necesitas convergencia; comunica el tiempo de recuperación esperado basado en TTL y comportamiento de caché.
• Vaciar si controlas el resolutor y puedes hacerlo con seguridad (y si no vas a causar una estampida).
• Rodear añadiendo registros alternativos temporalmente, ajustando delegación o usando un hostname distinto durante el incidente.

Tareas prácticas: comandos, salidas y decisiones

Estos no son comandos “de juguete”. Son los que ejecutas mientras alguien pide ETA. Cada tarea incluye qué te dice la salida y qué decisión tomar después.
Asume Linux salvo que se indique lo contrario.

Tarea 1: Identificar qué resolutor está usando realmente el host

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
search corp.example
options edns0 trust-ad

Lo que significa: Este host apunta a un stub local (127.0.0.53), probablemente systemd-resolved.
Decisión: No asumas los resolutores upstream todavía; inspecciona la configuración de systemd-resolved y el comportamiento de su caché a continuación.

Tarea 2: Inspeccionar servidores upstream de systemd-resolved y DNS por enlace

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

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54

Lo que significa: systemd-resolved reenvía a 10.10.0.53/54.
Decisión: Si solo algunos hosts fallan, compara esta salida entre máquinas “buenas” y “malas”. Las diferencias suelen explicar todo.

Tarea 3: Consultar un nombre vía el resolutor por defecto y observar TTL

cr0x@server:~$ dig api.example.com A +noall +answer +ttlid
api.example.com.  42  IN  A  203.0.113.20

Lo que significa: Obtienes una respuesta con 42 segundos restantes en caché.
Decisión: Si la IP es incorrecta, estás viendo estado cacheado. Siguiente paso: compara con autoritativos y otros recursors.

Tarea 4: Evitar lo local y consultar un resolutor recursivo específico

cr0x@server:~$ dig @1.1.1.1 api.example.com A +noall +answer +ttlid
api.example.com.  60  IN  A  198.51.100.77

Lo que significa: Un resolutor diferente devuelve una IP distinta (y un TTL nuevo). Eso es clásico “contenidos de caché diferentes.”
Decisión: Determina cuál respuesta es correcta consultando autoritativos. Si el autoritativo coincide con una, el otro resolutor está obsoleto o envenenado.

Tarea 5: Consultar servidores autoritativos directamente (evitando recurrencia)

cr0x@server:~$ dig api.example.com A +noall +answer +authority +additional +trace
api.example.com. 300 IN A 198.51.100.77

Lo que significa: El autoritativo dice 198.51.100.77 con TTL 300.
Decisión: El resolutor que devuelve 203.0.113.20 está obsoleto o siguiendo otra vista (split-horizon, zona antigua o reenvío malo).

Tarea 6: Comprobar NXDOMAIN y si se está cacheando negativamente

cr0x@server:~$ dig new.api.example.com A +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1443
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

example.com.  900  IN  SOA  ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 900

Lo que significa: NXDOMAIN, y el SOA muestra una ventana de caché negativa de 900 segundos (comúnmente derivada del MINIMUM del SOA).
Decisión: Si acabas de crear este registro, puede que necesites esperar a que caduquen las cachés negativas o cambiar de estrategia (nombre alternativo temporal, o pre‑crear antes del anuncio).

Tarea 7: Confirmar si DNSSEC está convirtiendo cosas en SERVFAIL

cr0x@server:~$ dig api.example.com A +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39012
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Lo que significa: El resolutor devolvió SERVFAIL. Fallos de validación DNSSEC a menudo se presentan así, pero también lo hacen los timeouts upstream.
Decisión: Compara resultados usando un resolutor con validación DNSSEC desactivada (en un entorno controlado) y consulta autoritativos directamente para revisar DNSKEY/DS.

Tarea 8: Medir la alcanzabilidad y latencia autoritativa desde tu red

cr0x@server:~$ dig @ns1.example.com api.example.com A +tries=1 +time=1 +stats
api.example.com. 300 IN A 198.51.100.77
;; Query time: 18 msec
;; SERVER: 192.0.2.53#53(ns1.example.com) (UDP)
;; WHEN: Tue Feb 04 12:02:51 UTC 2026
;; MSG SIZE  rcvd: 56

Lo que significa: El autoritativo responde rápido desde aquí.
Decisión: Si clientes en otros lugares hacen timeouts, puede haber problemas de enrutamiento geográfico/anycast, firewall o selección de resolutor upstream.

Tarea 9: Detectar problemas MTU/fragmentación que afecten DNS (tamaño EDNS0)

cr0x@server:~$ dig dnskey example.com +dnssec +bufsize=4096 +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58807
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Lo que significa: Respuestas UDP grandes funcionan desde este host. Si esto falla en otro lugar pero funciona con bufsize menor o TCP, tienes un problema de path o middlebox.
Decisión: Prueba con TCP y/o bufsize menor; si TCP funciona pero UDP grande falla, involucra equipos de red con capturas de paquetes y chequeos de MTU.

Tarea 10: Forzar DNS sobre TCP para confirmar que UDP es el problema

cr0x@server:~$ dig dnskey example.com +dnssec +tcp +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4926
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Lo que significa: TCP tiene éxito. Si UDP falla intermitentemente, probablemente tengas caídas por fragmentación UDP, límites de tasa o firewalls stateful raros.
Decisión: Ajusta tamaños EDNS, valida reglas de firewall y considera la orientación del proveedor autoritativo; no “arregles” esto subiendo TTLs.

Tarea 11: Inspeccionar estadísticas de caché de Unbound (resolutor local)

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'total.num.queries|total.num.cachehits|total.num.cachemiss|unwanted'
total.num.queries=184392
total.num.cachehits=151004
total.num.cachemiss=33388
unwanted.queries=219

Lo que significa: La tasa de aciertos de caché es alta; Unbound está haciendo trabajo. “unwanted” puede indicar consultas descartadas (política, límites o problemas).
Decisión: Si los misses de caché se disparan durante el incidente, podrías estar viendo una estampida; considera prefetch/serve-stale y la capacidad autoritativa.

Tarea 12: Vaciar un único nombre de Unbound (cuando controlas el resolutor)

cr0x@server:~$ sudo unbound-control flush api.example.com
ok

Lo que significa: Ese nombre se elimina de la caché en este resolutor.
Decisión: Vuelve a consultar para confirmar que ahora se usa dato autoritativo. Ten cuidado: vaciar a gran escala puede provocar una oleada de misses.

Tarea 13: Verificar recursión y comportamiento de caché en BIND

cr0x@server:~$ sudo rndc status
version: BIND 9.18.18 (Stable Release)
running on server: Linux x86_64
boot time: Tue Feb 04 09:11:03 UTC 2026
last configured: Tue Feb 04 09:12:01 UTC 2026
current serial: 2026020401
number of zones: 104 (104 automatic)
recursive clients: 12/1000/1000
tcp clients: 3/100
server is up and running

Lo que significa: El resolutor está activo, no saturado de clientes.
Decisión: Si los clientes aún fallan, revisa logs de consultas por SERVFAIL/timeouts y confirma alcanzabilidad upstream y estado de validación DNSSEC.

Tarea 14: Comprobar si CoreDNS de Kubernetes está devolviendo errores o va lento

cr0x@server:~$ kubectl -n kube-system logs -l k8s-app=kube-dns --tail=20
[INFO] 10.244.1.18:39976 - 56512 "A IN api.example.com. udp 44 false 512" SERVFAIL qr,rd,ra 44 0.002153s
[INFO] 10.244.2.21:34771 - 22341 "A IN api.example.com. udp 44 false 512" NOERROR qr,rd,ra 60 0.001122s

Lo que significa: SERVFAIL/NOERROR mixtos sugieren problemas upstream o de validación/alcanzabilidad intermitente, no un simple “registro ausente.”
Decisión: Identifica a qué upstream reenvía CoreDNS e prueba ese resolutor directamente desde el namespace de la red del nodo.

Tarea 15: Confirmar si una aplicación vuelve a resolver o ancla DNS

cr0x@server:~$ sudo strace -f -e trace=network -p 24817 2>&1 | head
connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("203.0.113.20")}, 16) = 0

Lo que significa: El proceso se está conectando directamente a una IP; no hay signo de consultas DNS en este fragmento. Puede haber resuelto antes y está reusando.
Decisión: Si la IP está obsoleta, reiniciar el proceso puede “arreglarlo”, lo cual también es evidencia de caché/anclaje a nivel de aplicación. La solución a largo plazo es configuración o código.

Tarea 16: Inspeccionar destinos de sockets en vivo para detectar uso de IPs obsoletas

cr0x@server:~$ ss -ntp | egrep ':443' | head
ESTAB 0 0 10.0.5.12:53014 203.0.113.20:443 users:(("myclient",pid=24817,fd=12))

Lo que significa: Conexiones activas van a 203.0.113.20.
Decisión: Si el autoritativo ahora apunta a otro lado, tienes conexiones ancladas o DNS obsoleto en alguna capa. Decide si drenar, reiniciar o añadir ruteo temporal.

Broma #2: Vaciar cachés DNS durante un incidente es como reorganizar sillas en un ferry—a veces ayuda, pero más vale que sepas qué está filtrando primero.

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

1) “El autoritativo es correcto, pero los usuarios aún golpean la IP antigua”

Síntoma: Algunos clientes siguen conectándose a endpoints antiguos mucho después de un cambio DNS.

Causa raíz: Los resolutores recursivos cachearon respuestas antiguas; existen cachés locales; las apps anclan DNS al inicio o mantienen conexiones por mucho tiempo.

Solución: Planifica cortes con solapamiento (mantén el endpoint antiguo vivo), acorta TTL con bastante antelación y verifica el comportamiento DNS de los runtimes cliente. Provee hostnames alternativos para la transición.

2) “NXDOMAIN persiste después de añadir el registro”

Síntoma: Un subdominio nuevo falla por minutos/horas; algunas redes resuelven, otras no.

Causa raíz: Caché negativa basada en SOA; consultas tempranas sembraron caches NXDOMAIN.

Solución: Precrea registros antes del anuncio. Ajusta valores SOA de TTL negativo a algo razonable. Para reparaciones urgentes, usa un hostname nuevo (rompe caché) en vez de esperar la expiración de NXDOMAIN.

3) “SERVFAIL intermitente en un resolutor, bien en otro”

Síntoma: Algunos resolutores devuelven SERVFAIL; otros NOERROR.

Causa raíz: Fallo de validación DNSSEC, cadena DS/DNSKEY rota, o alcanzabilidad autoritativa intermitente (un NS inalcanzable).

Solución: Valida la cadena DNSSEC de extremo a extremo y confirma que todos los servidores autoritativos respondan de forma consistente. Si un NS está mal, quítalo o arréglalo; autoridad parcial es peor que menos servidores buenos.

4) “Timeouts sólo para respuestas grandes”

Síntoma: Búsquedas A/AAAA mayormente bien, pero DNSKEY/TXT u otras respuestas fallan por timeout.

Causa raíz: Problemas EDNS0/fragmentación, desajuste de MTU, middleboxes que descartan fragmentos UDP o bloquean fallback a TCP.

Solución: Prueba con +tcp y ajusta tamaños EDNS. Arregla la ruta de red. No lo parchees reduciendo respuestas sin entender el trade-off.

5) “Sorpresas de split-horizon después de añadir una VPN”

Síntoma: Nombres internos resuelven mal externamente o viceversa; sólo usuarios con VPN fallan.

Causa raíz: Reenvío por dominio / políticas de DNS dividido; los resolutores difieren por interfaz; agentes corporativos sobrescriben resolutores.

Solución: Documenta los dominios de split-horizon, aplica configuraciones de resolutor consistentes y prueba desde VPN y desde fuera. Asegura que zonas internas no filtren y zonas externas sean accesibles.

6) “Bajar el TTL no ayudó en nuestro failover”

Síntoma: Bajaste TTL a 30–60 segundos, pero el failover aún tardó una eternidad.

Causa raíz: Algunos resolutores aplican TTL mínimo; algunos clientes anclan DNS; las cachés ya contenían respuestas antiguas antes del cambio de TTL.

Solución: Baja TTL con días de antelación a los cambios planificados. Prueba con poblaciones reales de clientes. Usa reintentos a nivel de aplicación y lógica multi-endpoint; DNS por sí solo no es un sistema de failover.

7) “Vaciamos la caché y lo empeoramos”

Síntoma: Tras vaciar resolutores, el QPS autoritativo se dispara y más consultas hacen timeout.

Causa raíz: Estampida de caché: convertiste tu flota de resolutores en un generador sincronizado de misses.

Solución: Vacía quirúrgicamente (un nombre, un nivel de resolutor), escalona reinicios y asegura la capacidad autoritativa. Prefiere estrategias de serve-stale/prefetch cuando proceda.

Listas de verificación / plan paso a paso

Lista A: Antes de un corte DNS planificado

1. Baja el TTL con antelación (al menos una ventana completa del TTL previo; a menudo 24–48 horas) para que las cachés existentes envejezcan.
2. Confirma valores SOA de caché negativa para que un error breve no perdure una hora.
3. Mantén los endpoints antiguos vivos el tiempo suficiente para aguantar clientes que anclan DNS o mantienen conexiones largas.
4. Prueba desde múltiples resolutores (empresarial, público, móvil) y desde varias regiones.
5. Verifica salud autoritativa y consistencia entre todos los NS (incluyendo DNSSEC si está habilitado).
6. Ten un plan de rollback que no dependa del TTL: hostname alternativo, override de ruteo o endpoints duales.

Lista B: Durante un incidente atribuido al DNS

1. Establece la verdad base: consulta autoritativos directamente; anota respuestas esperadas.
2. Compara cachés: consulta al menos dos recursors distintos; anota diferencias.
3. Identifica la capa que falla: stub local, caché node-local, reenviador empresarial, resolutor público o app.
4. Clasifica el fallo: respuesta errónea, NXDOMAIN, SERVFAIL, timeout, intermitente.
5. Elige una mitigación: esperar, vaciar (quirúrgico), evitar (hostname alternativo) o rodear (preferencia de delegación).
6. Comunica plazos realistas: incluye ventanas de caché negativa y “algunos clientes anclan DNS” en tu ETA.

Lista C: Después del incidente (la parte que la gente salta y luego repite)

1. Añade monitorización que evite cachés: consulta autoritativos directamente desde múltiples redes.
2. Rastrea tasas de error de resolutores: SERVFAIL, timeouts, picos de NXDOMAIN y distribuciones de latencia.
3. Documenta la topología de resolutores: qué redes usan qué resolutores; incluye VPN y reenviadores de sucursales.
4. Estandariza controles de caché: política de serve-stale, prefetch, procedimientos de flush y patrones seguros de reinicio.
5. Audita comportamiento DNS de aplicaciones: en especial ajustes de JVM, pooling de conexiones y librerías que cachean.

Preguntas frecuentes

1) ¿Por qué mi cambio DNS “no se propagó” aunque el TTL era bajo?

Porque el TTL que pusiste sólo controla la caché para resolutores que lo respetan y para clientes que vuelven a consultar DNS. Algunos resolutores aplican TTL mínimos,
y algunas apps resuelven una vez al inicio y nunca más. Además, bajar TTL sólo ayuda después de que las cachés existentes hayan envejecido; no reescribe el pasado.

2) ¿Cuál es la diferencia entre DNS autoritativo y resolutores recursivos?

Los servidores autoritativos albergan los datos de la zona (fuente de la verdad). Los resolutores recursivos obtienen esos datos en nombre de los clientes y los cachean.
Durante incidentes, debes consultar autoritativos directamente para saber qué “debería” ser cierto, y consultar recursors recursivos para saber qué “creen” los clientes.

3) ¿Puedo poner TTL a 0 para evitar caché?

Puedes poner TTL muy bajo, pero muchos resolutores no honran 0, y aumentarás la carga de consultas significativamente. Los TTL bajos tampoco arreglan el anclaje a nivel de aplicación y pueden producir estampidas.
Usa TTL bajos tácticamente para cortes planificados, no como muleta permanente.

4) ¿Qué es la caché negativa y por qué me importa?

La caché negativa almacena “este nombre no existe” (NXDOMAIN) o “sin datos” (NODATA). Importa porque un error breve—como un registro faltante—puede
persistir en cachés mucho después de que lo restaures, ralentizando la recuperación más que la ventana del error original.

5) ¿Cuándo debo vaciar cachés DNS?

Vacía cuando controlas el resolutor y estás seguro de que los datos autoritativos son correctos y necesitas convergencia más rápida que la que permite el TTL.
Hazlo de forma quirúrgica (un nombre, un nivel) y ten en cuenta las estampidas. Vaciar todo suele ser un incidente de rendimiento disfrazado de solución.

6) ¿Cómo sé si SERVFAIL está relacionado con DNSSEC?

Compara comportamiento entre resolutores con validación DNSSEC conocida, consulta con +dnssec e inspecciona consistencia DS/DNSKEY.
SERVFAIL también puede venir de timeouts, así que mide alcanzabilidad y prueba con TCP para descartar problemas UDP.

7) ¿Por qué algunos clientes funcionan y otros fallan al mismo tiempo?

Porque usan resolutores diferentes (ISP vs empresarial vs público), tienen contenidos de caché distintos o están detrás de políticas de red diferentes (split DNS de VPN).
Además, algunos clientes mantienen conexiones de larga duración y no necesitan resolver de nuevo hasta reconectar.

8) ¿Kubernetes empeora los problemas DNS?

Puede. Kubernetes añade capas DNS (CoreDNS, caché node-local opcional), aumenta el volumen de consultas y crea nuevos modos de fallo donde la caché de un único nodo
se vuelve una interrupción localizada. Bien hecho, funciona. Hecho sin cuidado, es una caja misteriosa distribuida.

9) ¿Debería confiar en DNS para failover entre regiones?

Usa DNS como una herramienta, no la única. El failover por DNS es eventualmente consistente y dependiente del cliente. Combínalo con reintentos de aplicación, soporte multi-endpoint
y balanceo con chequeos de salud cuando sea posible. Asume que algunos clientes estarán equivocados por un tiempo y diseña para que lo “equivocado” siga siendo tolerable.

Conclusión: próximos pasos para evitar reincidencias

La caché DNS no “causa” interrupciones. Las preserva, las distribuye y las hace parecer aleatorias. Si tratas el DNS como un simple archivo de configuración,
seguirás teniendo incidentes donde la solución es correcta y el impacto en clientes continúa de forma obstinada.

Haz tres cosas este trimestre:

1. Mapea tu ruta de resolutores para cada entorno mayor (nodos prod, oficina, VPN, CI, Kubernetes). Escríbelo. Mantenlo actual.
2. Construye monitores que eviten cachés que consulten servidores autoritativos directamente y validen respuestas esperadas (incluyendo DNSSEC si se usa).
3. Operativiza cambios DNS: baja TTL con antelación, controla TTLs negativos, planifica solapamientos y trata el flush de caché como un bisturí, no como una alarma de incendio.

El objetivo no es eliminar la caché. El objetivo es hacer la caché predecible, observable y aburrida. Aburrido es un cumplido en producción.