Resolutores DNS: Caché negativa — la configuración que hace que las interrupciones duren más

febrero 17, 2026 • febrero 17, 2026 • Lectura: 24 min • Views: 0

¿Te fue útil?

Aquí tienes una línea de tiempo clásica de una caída: tecleas mal un registro DNS, lo corriges en un minuto… y los usuarios siguen fallando durante otros 30–60 minutos. El ticket dice “DNS todavía está roto”, tus paneles muestran “autoritativo está correcto” y la empresa pregunta “¿estás seguro?”

Bienvenido a la caché negativa: la función del resolver que almacena fracasos (como NXDOMAIN) y hace que errores cortos parezcan incompetencias largas. No es maliciosa. Simplemente hace su trabajo—a menudo con valores por defecto elegidos para la internet de ayer y el presupuesto de latencia de hoy.

Caché negativa en términos sencillos

DNS es una base de datos distribuida que mayormente devuelve “aquí está la IP” (o “aquí está el CNAME”). La caché negativa ocurre cuando devuelve “no existe ese nombre” (NXDOMAIN) o “sin datos” (NODATA: el nombre existe, pero no ese tipo de registro), y el resolver decide recordar ese fallo por un tiempo.

Ese “por un tiempo” es toda la historia. La caché negativa convierte búsquedas transitorias en menos consultas ascendentes, reduce la carga en servidores autoritativos y hace que los usuarios vayan más rápido cuando un nombre realmente no existe. Pero cuando un nombre comienza a existir—porque lo creaste, lo arreglaste o cambiaste la delegación—la caché negativa puede mantener a los clientes anclados en el pasado.

Pueden coexistir dos verdades distintas:

Tu servidor autoritativo responde correctamente ahora mismo.
Los resolvers de tus clientes aún están convencidos de que el nombre no existe.

Si alguna vez viste a un equipo SRE “esperar a que el DNS caduque” con los dientes apretados, esta es la razón.

Broma seca #1: La “propagación” de DNS no existe—la expiración de caché de DNS sí. Desgraciadamente, el marketing prefiere la primera.

Cómo funciona realmente la caché negativa (y por qué SOA importa)

NXDOMAIN vs NODATA: mismo dolor, semánticas distintas

NXDOMAIN significa que el nombre consultado no existe en esa zona. Ejemplo: preguntas por api.example.com, y el servidor autoritativo dice “nunca lo oí.”

NODATA (a menudo visto como NOERROR con la sección de respuesta vacía) significa que el nombre existe, pero no el tipo solicitado. Ejemplo: www.example.com existe con un registro A, pero preguntas por AAAA y la zona no tiene ninguno. Muchos resolvers también almacenan esto como negativo.

Operativamente: ambos pueden bloquear despliegues, en especial despliegues dual-stack (AAAA) y patrones de descubrimiento de servicio que asumen “ausente significa deshabilitado”.

El TTL de la caché negativa suele venir del SOA

El comportamiento de caché negativa está estandarizado (RFC 2308), y el TTL usado para almacenar respuestas negativas se deriva del registro SOA de la zona.

Aquí la versión práctica:

Las respuestas autoritativas a menudo incluyen el SOA de la zona en la sección de autoridad para respuestas negativas.
El resolver usa el TTL del SOA y/o el campo “minimum” (dependiendo del servidor y del comportamiento del resolver) para decidir cuánto tiempo almacenar la respuesta negativa.
Los resolvers también pueden imponer límites al TTL negativo mediante políticas locales (por coherencia y seguridad).

Si tu SOA de zona está configurado con un TTL negativo de una hora, acabas de dar permiso a todos los resolvers para recordar tu error durante una hora. Eso puede estar bien para protección contra typosquatting y carga de consultas. No está bien para despliegues rápidos que crean nombres bajo demanda.

¿Quién es “el resolver” en realidad?

La resolución DNS a menudo atraviesa múltiples cachés:

Resolver stub en el host (o systemd-resolved)
Caché local del nodo (común en Kubernetes, por ejemplo NodeLocal DNSCache)
Resolver recursivo (Unbound, BIND, PowerDNS Recursor, resolutores corporativos, resolutores de ISP)
Cachés en la aplicación (caché DNS de la JVM, comportamiento del resolver de Go, cachés en proceso)
CDN / appliances de seguridad que hacen proxy de DNS

La caché negativa puede ocurrir en varias capas. Por eso “vaciar el DNS del portátil” a veces no cambia nada: la caché rencorosa no está en tu portátil.

Cita que vale la pena pegar en el monitor

La esperanza no es una estrategia. — Gene Kranz

Los incidentes DNS adoran la “esperanza.” Esperar a que las cachés expiren pronto. Esperar a que los clientes reintenten. Esperar a que el otro equipo no haya puesto TTLs de tiempos geológicos. No esperes. Mide, acota y verifica.

Hechos y contexto histórico que conviene conocer

La caché negativa se formalizó para proteger el DNS de consultas repetidas e innecesarias cuando los nombres no existen (RFC 2308). Es una característica de escalado, no un bug.
“SOA minimum” solía significar TTL por defecto en prácticas DNS antiguas; las zonas modernas usan TTL explícitos, pero ese nombre heredado todavía causa confusión durante la respuesta a incidentes.
Los resolvers casi siempre almacenan NXDOMAIN a menos que estén configurados para no hacerlo, porque fallar rápido repetidamente puede DoSear la infraestructura autoritativa tan efectivamente como el tráfico exitoso.
La caché negativa se aplica a más que NXDOMAIN: “no hay registro AAAA” a menudo se cachea como respuesta negativa. Eso importa para despliegues de IPv6.
Algunos resolvers limitan los TTL negativos (por ejemplo a unos pocos minutos) para reducir la radio de impacto de errores, pero las empresas frecuentemente anulan esos límites “por rendimiento”.
DNSSEC cambió las reglas para las respuestas negativas: la negación autenticada de existencia (NSEC/NSEC3) hace las respuestas negativas demostrables criptográficamente, lo que también las hace más confiablemente cacheables.
Los navegadores y runtimes se han vuelto más agresivos con el caching con el tiempo para reducir latencia. Eso ayuda a la carga de páginas; también prolonga los momentos de “lo arreglamos”.
Kubernetes volvió al DNS más central para la salud de aplicaciones de lo que muchas empresas estaban preparadas; la caché negativa es especialmente dolorosa cuando servicios y endpoints son efímeros.

Dónde viven las cachés negativas: stub, recursiva, aplicación y “cajas intermedias útiles”

1) Resolvers stub a nivel de host

En Linux, puedes estar tratando con systemd-resolved, nscd, dnsmasq, o nada en absoluto (glibc enviando consultas directamente a los recursores configurados). Cada uno tiene su propio comportamiento de caché.

La caché negativa en esta capa puede hacer que una sola máquina parezca “poseída” mientras otras están bien. Es una excelente manera de perder 45 minutos culpando al enrutamiento.

2) Resolvers recursivos (la caché real)

Aquí es donde la caché negativa suele doler más, porque un resolver recursivo sirve a poblaciones enteras: redes de oficina, VPCs, clústeres y usuarios VPN.

Los resolvers recursivos típicamente:

Almacenan respuestas negativas con un TTL
Pueden “servir expirados” bajo algunas condiciones (usualmente para respuestas positivas, pero el comportamiento varía)
Tienen perillas de política para TTLs máximos/mínimos, incluyendo límites de TTL negativos

3) Cachés a nivel de aplicación y comportamiento del runtime

Aun cuando DNS está “arreglado,” la aplicación puede seguir fallando porque cacheó el resultado negativo.

Responsables comunes:

Java puede cachear búsquedas negativas; los valores por defecto dependen de la configuración de seguridad y la versión de la JVM.
Go puede usar el resolver cgo o el resolver puro de Go según la compilación/ejecución; el caching suele ser mínimo en el runtime, pero tu aplicación o sidecars pueden cachear.
Envoy / mallas de servicio pueden cachear resultados DNS para descubrimiento de clúster.

4) Cajas intermedias y DNS “de seguridad”

Algunos appliances corporativos de filtrado DNS devuelven NXDOMAIN (o IPs sinkhole) para dominios bloqueados y almacenan esos resultados agresivamente. Eso puede chocar con patrones de dominios internos y causar… incidentes creativos.

Broma seca #2: Lo bueno de la caché negativa es que es la única parte del DNS que nunca miente—si dice “no”, significa “no, durante los próximos 3600 segundos”.

Tres mini-historias del mundo corporativo (las que reconoces)

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

La compañía tenía un playbook DNS ordenado: establecer TTLs bajos para servicios, automatizar la creación de registros y usar health checks para mover tráfico. Un equipo nuevo desplegó un gateway de API interno y decidió crear nombres DNS por inquilino bajo demanda: tenant-id.api.internal.

La suposición equivocada era simple: “Si el registro no existe, los clientes reintentaran después y funcionará una vez que lo creemos.” En su cabeza, el DNS se comportaba como una base de datos eventualmente consistente con convergencia rápida.

En realidad, la primera consulta ocurrió antes de que la automatización terminara. El resolver recursivo devolvió NXDOMAIN. Esa respuesta llevaba un SOA con un TTL negativo grande. Ahora el resolver tenía permiso para seguir diciendo a todos “no existe” durante mucho tiempo, incluso después de que el registro se creó correctamente.

Los síntomas del incidente fueron extraños: solo los inquilinos nuevos fallaban, y solo para un subconjunto de usuarios. Los inquilinos existentes estaban bien. El gateway estaba bien. La zona autoritativa parecía correcta. El equipo rotó pods y reinició servicios, porque eso es lo que se hace cuando estás perdiendo y es tarde.

La solución no fue heroica: reducir el TTL de caché negativa de la zona, añadir un paso de “calentamiento” que cree el registro antes de que cualquier cliente intente resolverlo, y a corto plazo vaciar las cachés en los recursores corporativos. La lección quedó: la falla DNS es estado cacheable, no un error transitorio.

Mini-historia #2: La optimización que se volvió en contra

Otra organización gestionaba recursores muy ocupados y veía altas tasas de consultas por nombres inexistentes—typos, telemetría, clientes rotos, el ruido de fondo habitual. Un ingeniero decidió “optimizar” elevando significativamente los límites de TTL negativos y cacheando NXDOMAIN por más tiempo. Funcionó: el volumen de consultas ascendentes bajó, la CPU se vio genial y todos chocaron las manos discretamente porque los ingenieros DNS no suelen chocar las manos.

Luego hicieron un rebranding. Nuevos hostnames, nuevos subdominios, mucho cambio impulsado por marketing. La zona autoritativa estaba lista. Los recursores estaban listos. Pero una gran parte de la empresa ya había intentado resolver algunos de esos nombres nuevos durante pruebas previas al lanzamiento, cuando los registros aún no existían.

Esos NXDOMAIN ahora estaban cacheados por mucho tiempo debido a la “optimización.” Llegó el día del lanzamiento. Algunos usuarios estaban bien, otros recibían fallos duros. El helpdesk lo vio como un despliegue inestable. Los SREs lo vieron como “DNS está correcto.” Ambos tenían razón técnicamente. El incidente duró lo que duraron las cachés negativas.

Revirtieron el límite de TTL negativo, pero eso no deshizo los fallos ya cacheados. Tuvieron que vaciar cachés y esperar. La represalia no fue solo la configuración—fue la falta de una política: la caché negativa es una decisión de fiabilidad, no un ajuste de rendimiento.

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

Una fintech tenía una regla que molestaba a los equipos de producto: “Ningún nombre DNS puede ser referenciado por código en producción hasta que resuelva correctamente desde al menos dos resolvers recursivos independientes.” Sonaba burocrático. Lo era. También evitó una clase muy específica de caída.

Estaban migrando un endpoint de callback de pagos a una nueva región. El plan de migración incluía crear callback.payments.example como CNAME a un nombre regional, y luego cambiarlo durante mantenimiento. Precrearon el registro días antes y lo verificaron desde (1) sus propios recursores y (2) una pila de resolvers separada usada para monitorización.

Durante la ventana de cambio, un ingeniero aplicó accidentalmente una actualización de archivo de zona que faltaba ese registro. Autoritativos empezaron a devolver NXDOMAIN. La monitorización lo detectó en minutos porque comprobaba desde múltiples resolvers y comparaba con respuestas esperadas. Revirtieron la zona rápidamente.

Esto es lo que importó: como el registro había existido y sido estable durante días, las cachés tenían entradas positivas, no negativas. La ventana en la que los clientes observaron NXDOMAIN fue pequeña, y muchos clientes ni siquiera lo vieron. La práctica aburrida—precrear, verificar, monitorizar desde múltiples puntos—convirtió un posible incidente de una hora en un pequeño pico.

Guía rápida de diagnóstico

Cuando sospeches de caché negativa, compites contra dos relojes: el que está en la caché y el de la paciencia del negocio. No dispares limpiezas aleatorias. Prueba de dónde viene la respuesta errónea.

Primero: identifica qué fallo estás viendo realmente

¿Es NXDOMAIN? El nombre no existe (cacheado duro).
¿Es NODATA? El nombre existe, pero falta el tipo (común para AAAA).
¿Es SERVFAIL/timeouts? No es caché negativa; suele ser DNSSEC, alcance o problemas ascendentes.

Segundo: compara respuestas desde tres lugares

Servidor autoritativo directamente (evitar cachés).
Tu resolver recursivo habitual (el que usan realmente los clientes).
Un resolver “limpio” conocido (otra pila recursiva bajo tu control, o un resolver de prueba en otra red).

Tercero: extrae el TTL negativo y decide

Si el TTL negativo es pequeño (segundos a unos minutos): espera, pero sigue demostrando la mejora.
Si el TTL negativo es grande (decenas de minutos a horas): arregla la configuración de SOA a largo plazo y vacía cachés recursivas a corto plazo si las controlas.
Si solo algunos clientes fallan: sospecha una capa de caché local (caché node-local DNS, systemd-resolved, JVM), no la zona autoritativa.

Cuarto: comprueba split-horizon y reenvío condicional

“Funciona en VPN, falla fuera de VPN” o “funciona en una VPC, falla en otra” suele significar que distintos resolvers están recibiendo verdades distintas. La caché negativa entonces fija esas verdades distintas por más tiempo del esperado.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas asumen herramientas Linux. Si ejecutas resolvers en contenedores o appliances, la misma lógica aplica: consulta, compara, extrae TTL, actúa.

Task 1: Confirmar el síntoma con `dig` contra el resolver por defecto

cr0x@server:~$ dig api.example.internal A

; <<>> DiG 9.18.24 <<>> api.example.internal A
;; global options: +cmd
;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34219
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  1800  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

;; Query time: 12 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Feb  4 10:01:22 UTC 2026
;; MSG SIZE  rcvd: 132

Qué significa: El estado es NXDOMAIN. El SOA se muestra con TTL 1800 segundos. Eso es una pista fuerte de que la caché negativa es de 30 minutos.

Decisión: No redeployes la aplicación aún. Primero verifica la verdad autoritativa y confirma que la política de TTL negativo es la causa.

Task 2: Consultar el servidor autoritativo directamente (evitar recursion)

cr0x@server:~$ dig @192.0.2.53 api.example.internal A +norecurse

; <<>> DiG 9.18.24 <<>> @192.0.2.53 api.example.internal A +norecurse
;; global options: +cmd
;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NOERROR, id: 1201
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.internal. 60 IN A 198.51.100.20

;; Query time: 3 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Tue Feb  4 10:01:31 UTC 2026
;; MSG SIZE  rcvd: 62

Qué significa: El autoritativo dice que el registro existe y es correcto (NOERROR, bandera aa, respuesta presente).

Decisión: Esto es casi con certeza un NXDOMAIN cacheado en capas de recursión. Tu zona está bien ahora; tus cachés no lo están.

Task 3: Preguntar al resolver recursivo e inspeccionar el TTL del SOA en autoridad

cr0x@server:~$ dig @10.10.0.53 api.example.internal A +noall +answer +authority +comments

;; Got answer:
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54530
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  1742  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Qué significa: El TTL ahora es 1742 segundos, en cuenta regresiva. Eso es estado negativo cacheado decayendo en tiempo real.

Decisión: Si no puedes vaciar, al menos puedes predecir cuándo se auto-recuperará (en ~29 minutos desde el llenado original de la caché).

Task 4: Confirmar si el problema es específico de tipo (NODATA para AAAA)

cr0x@server:~$ dig @10.10.0.53 www.example.internal AAAA

; <<>> DiG 9.18.24 <<>> @10.10.0.53 www.example.internal AAAA
;; ->HEADER<<- opcode: QUERY, status: NOERROR, id: 7711
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.internal.  900  IN  SOA  ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Qué significa: NOERROR con respuesta vacía puede cachearse como “no AAAA.” Esto puede romper clientes que prefieren IPv6 primero (Happy Eyeballs ayuda, pero no siempre).

Decisión: Decide si necesitas publicar AAAA o ajustar el comportamiento del cliente. No lo trates como “DNS está bien.” Es una negativa real y cacheable.

Task 5: Usar `dig +trace` para ver dónde ocurre la negación

cr0x@server:~$ dig +trace api.example.internal A

; <<>> DiG 9.18.24 <<>> +trace api.example.internal A
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

example.internal. 172800 IN NS ns1.example.internal.
example.internal. 172800 IN NS ns2.example.internal.
;; Received 151 bytes from 198.41.0.4#53(a.root-servers.net) in 17 ms

api.example.internal. 60 IN A 198.51.100.20
;; Received 62 bytes from 192.0.2.53#53(ns1.example.internal) in 4 ms

Qué significa: La ruta autoritativa devuelve el registro correcto. Así que si los clientes ven NXDOMAIN, es cacheo o split-horizon, no una delegación faltante.

Decisión: Enfócate en recursores e intermedios. Deja de editar archivos de zona “por si acaso”.

Task 6: Comprobar qué resolver usa tu host

cr0x@server:~$ resolvectl status

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: example.internal

Qué significa: El host usa systemd-resolved en modo stub. Hay una caché local además de recursores ascendentes.

Decisión: Si solo este host falla, vacía la caché local. Si muchos hosts fallan, vaciar un host no servirá.

Task 7: Vaciar la caché de `systemd-resolved` (nivel host)

cr0x@server:~$ sudo resolvectl flush-caches

Qué significa: No mostrar salida es normal. No garantiza que las cachés ascendentes se limpien.

Decisión: Vuelve a probar con dig. Si NXDOMAIN persiste, la caché está en la recursión superior, no en el host.

Task 8: Comprobar si `nscd` cachea búsquedas de hosts

cr0x@server:~$ systemctl is-active nscd
inactive

Qué significa: nscd no es el culpable en este host.

Decisión: No pierdas tiempo reiniciándolo. Sigue adelante.

Task 9: Inspeccionar ajustes relacionados con caché negativa en Unbound

cr0x@server:~$ sudo unbound-control get_option neg-cache-size
neg-cache-size: 4m

Qué significa: Unbound asigna espacio para la caché negativa. El tamaño no es el TTL, pero confirma que la caché negativa está en juego.

Decisión: Si tienes presión de memoria y ocurren expulsiones, podrías ver comportamiento inconsistente. De lo contrario, procede a vaciar o ajustar límites.

Task 10: Vaciar un solo nombre en Unbound (quirúrgico, no napalm)

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

Qué significa: La entrada cacheada para ese nombre se elimina de Unbound.

Decisión: Reconsulta. Si ahora devuelve NOERROR, has probado que el NXDOMAIN cacheado era el bloqueo. Considera vaciar todo el subtree relevante si muchos nombres se vieron afectados.

Task 11: Vaciar un nombre en BIND (si ejecutas named)

cr0x@server:~$ sudo rndc flushname api.example.internal

Qué significa: No mostrar salida típicamente significa éxito. Algunas compilaciones lo registran en vez de imprimirlo.

Decisión: Verifica inmediatamente con dig vía ese resolver. Si aún NXDOMAIN, la caché puede estar en otro sitio (forwarder, node-local, runtime del cliente).

Task 12: Encontrar la política de TTL negativo en un SOA de zona BIND

cr0x@server:~$ dig @192.0.2.53 example.internal SOA +noall +answer

example.internal. 300 IN SOA ns1.example.internal. hostmaster.example.internal. 2026020401 3600 900 1209600 1800

Qué significa: El último campo (1800) es comúnmente usado como TTL de caché negativa (según las semánticas de RFC 2308, dependiendo de la implementación). El propio TTL del registro SOA es 300 aquí, pero el campo “minimum” es 1800.

Decisión: Si necesitas recuperación más rápida de errores y creación rápida de nombres, reduce ese mínimo/TTL negativo. No lo pongas a 0 a menos que disfrutes tormentas de consultas auto-infligidas.

Task 13: Validar qué ve realmente tu cliente con `getent`

cr0x@server:~$ getent ahostsv4 api.example.internal
198.51.100.20   STREAM api.example.internal
198.51.100.20   DGRAM
198.51.100.20   RAW

Qué significa: La ruta libc resolver resuelve correctamente. Si dig falla pero getent funciona (o viceversa), puedes tener comportamiento DNS dividido o rutas de resolver diferentes (stub vs directo).

Decisión: Depura la ruta que usa tu aplicación, no la que prefieres. Muchos incidentes son “funciona con dig” mientras la app usa otra cosa.

Task 14: Comprobar si CoreDNS en Kubernetes cachea negativos demasiado tiempo

cr0x@server:~$ kubectl -n kube-system get configmap coredns -o yaml | sed -n '1,120p'
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . 10.10.0.53 10.10.0.54
        cache 30
        loop
        reload
        loadbalance
    }

Qué significa: El plugin cache 30 almacena respuestas por 30 segundos por comportamiento por defecto. Dependiendo de la configuración, los negativos también pueden cachearse. Tu recursor ascendente aún puede cachear NXDOMAIN mucho más tiempo.

Decisión: Si el clúster es la población afectada, ajusta deliberadamente el caching de CoreDNS y asegúrate de que los límites negativos ascendentes se alineen con las necesidades de descubrimiento de servicio.

Task 15: Observar si un forwarder está devolviendo NXDOMAIN cacheado

cr0x@server:~$ dig @10.10.0.53 api.example.internal A +stats

; <<>> DiG 9.18.24 <<>> @10.10.0.53 api.example.internal A +stats
;; ->HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32602
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; Query time: 1 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Tue Feb  4 10:02:01 UTC 2026
;; MSG SIZE  rcvd: 132

Qué significa: Un tiempo de respuesta de 1 ms sugiere fuertemente que esto se sirvió desde caché, no que se obtuvo de servidores autoritativos.

Decisión: Necesitas gestión de caché (vaciar/limitar TTL) más que “intentar de nuevo”.

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

1) “Creamos el registro pero los usuarios aún reciben NXDOMAIN”

Síntomas: El autoritativo muestra el registro; los clientes siguen fallando con NXDOMAIN; los fallos desaparecen lentamente durante decenas de minutos.

Causa raíz: Los resolvers recursivos cachearon NXDOMAIN antes; el TTL negativo derivado del SOA es largo.

Solución: Reducir el TTL negativo en la zona (SOA minimum/política de TTL negativo), vaciar cachés donde las controlas y precrear registros antes de que cualquier cliente pueda consultarlos.

2) “Solo los clientes IPv6 fallan” (o solo algunas librerías)

Síntomas: Las búsquedas A funcionan; las búsquedas AAAA devuelven vacías; algunos clientes hacen timeout o se comportan de forma extraña.

Causa raíz: NODATA para AAAA está siendo cacheado; el cliente prefiere IPv6; la app no cae de forma elegante.

Solución: Publicar AAAA donde corresponda, o ajustar el comportamiento del cliente; considera reducir la caché negativa para NODATA relacionado con AAAA en la política del resolver si perjudica los despliegues.

3) “Funciona en mi portátil, falla en el centro de datos”

Síntomas: La misma consulta da respuestas diferentes según la red.

Causa raíz: DNS split-horizon, reenvío condicional o pilas de resolvers recursivos distintas con estados negativos cacheados diferentes.

Solución: Identifica qué resolver usa cada entorno; compara directamente; unifica política; vacía la población de resolvers específica que está equivocada.

4) “Reiniciar pods lo arregló… brevemente”

Síntomas: La app funciona tras reiniciar, luego falla otra vez; o distintos pods muestran comportamiento distinto.

Causa raíz: Las cachés locales de nodo difieren; algunos nodos golpean NXDOMAIN cacheado; otros no. Los reinicios cambian en qué nodo caes.

Solución: Arregla en la capa del resolver (caché node-local DNS / CoreDNS / recursor ascendente). No uses reinicios como invalidación de caché.

5) “Pusimos TTLs bajos, ¿por qué sigue roto?”

Síntomas: Los TTLs positivos son bajos (como 60s), pero NXDOMAIN persiste mucho más tiempo.

Causa raíz: El TTL negativo no es tu TTL de registro. Se deriva de los ajustes negativos del SOA y de los límites de política del resolver.

Solución: Audita campos SOA y límites de TTL negativos en resolvers. Trata el TTL negativo como un control SLO de primera clase.

6) “DNSSEC lo empeoró”

Síntomas: Tras habilitar DNSSEC, las respuestas negativas perduran o aparece SERVFAIL, y vaciar parece ineficaz.

Causa raíz: Los resolvers validadores DNSSEC cachean la negación autenticada de existencia con confianza; además, una mala configuración puede generar SERVFAIL (no NXDOMAIN).

Solución: Separa NXDOMAIN de SERVFAIL. Para SERVFAIL, valida la cadena DNSSEC y las firmas. Para NXDOMAIN, ajusta la política de TTL negativo y la estrategia de vaciado de caché.

Listas de verificación / plan paso a paso

Checklist: antes de crear hostnames totalmente nuevos en producción

Fija un TTL de caché negativa sensato para la zona (a menudo 30–300 segundos para zonas internas de movimiento rápido; más largo para zonas públicas estables).
Precrea nombres (o usa wildcard con cuidado) antes de que cualquier cliente pueda intentar resolverlos.
Verifica desde al menos dos resolvers recursivos (pilas o segmentos de red distintos).
Verifica explícitamente el comportamiento A y AAAA (incluso si “no usas IPv6”).
Documenta cómo vaciar cachés en tu flota de resolvers y prueba que funciona.

Checklist: durante un incidente donde “DNS está arreglado pero sigue roto”

Confirma el tipo de fallo: NXDOMAIN vs NODATA vs SERVFAIL.
Consulta autoritativos directamente con +norecurse.
Consulta el resolver recursivo que usan tus clientes; extrae el TTL restante de la línea SOA.
Comprueba si el tiempo de respuesta sugiere caché (1–2 ms) vs ascendente (10 ms+).
Vacía el nombre específico en el resolver recursivo si lo controlas; vuelve a probar.
Si no lo controlas, mueve clientes a otro resolver temporalmente (último recurso, pero a veces es la única palanca).
Tras la restauración, reduce el TTL negativo si este extendió la duración de la caída.

Plan paso a paso: ajustar la caché negativa sin derretir tus servidores autoritativos

Inventaria zonas y clasifícalas: públicas estables, internas estables, internas dinámicas (service discovery, nombres efímeros).
Mide tasas de NXDOMAIN en recursores y servidores autoritativos. Un alto volumen de NXDOMAIN sugiere typos, escaneo o clientes rotos.
Fija objetivos de TTL negativo por categoría:
- Zonas públicas estables: TTL más largo puede estar bien.
- Zonas internas dinámicas: TTL negativo corto suele valer la pena.
Aplica límites en resolvers para que un SOA malo no imponga una hora de caída a todos.
Prueba la capacidad de los autoritativos si reduces mucho el TTL negativo. Menos NXDOMAIN cacheados significa más consultas ascendentes.
Despliega gradualmente en la flota de resolvers; monitoriza volumen de consultas, latencia y SERVFAIL.

Preguntas frecuentes

1) ¿La caché negativa es lo mismo que la “propagación” de DNS?

No. “Propagación” es un término popular. Lo que realmente ocurre es que las cachés obedecen TTLs—positivos y negativos—a través de múltiples capas de resolver.

2) ¿Qué controla cuánto tiempo se cachea NXDOMAIN?

Típicamente el SOA de la zona (semántica de TTL negativo) más cualquier límite u override en los resolvers recursivos. Algunos resolvers también aplican políticas de mínimo/máximo.

3) Si pongo el TTL de mi registro a 60 segundos, ¿NXDOMAIN también se cacheará 60 segundos?

No. El TTL de registro afecta respuestas positivas. El cacheo de NXDOMAIN está gobernado por la política de TTL negativo, usualmente derivada del SOA.

4) ¿Puedo simplemente poner TTL negativo a 0 en todas partes?

Puedes, pero lo pagarás con mayor carga de consultas y potencialmente DoS auto-infligido a tus servidores autoritativos. Para zonas internas dinámicas, un valor pequeño (no cero) suele ser el punto óptimo.

5) ¿Cómo sé si veo NXDOMAIN cacheado versus NXDOMAIN autoritativo?

Consulta autoritativos directamente con dig @auth +norecurse. Si el autoritativo dice NOERROR pero el recursivo dice NXDOMAIN, es cacheado o split-horizon. También observa el decremento del TTL en la línea SOA en consultas repetidas.

6) ¿Por qué solo algunos usuarios ven el fallo?

Porque distintos usuarios golpean distintos resolvers, o distintas cachés en diversas capas. Algunos pueden haber cacheado el fallo antiguo; otros nunca consultaron durante la ventana problemática.

7) ¿Vaciar cachés siempre lo arregla inmediatamente?

Solo si vacías la caché que contiene la entrada mala y los clientes realmente usan ese resolver. Vaciar un portátil no arreglará una caché recursiva empresarial situada río arriba.

8) ¿Qué pasa con las cachés DNS de los navegadores?

Los navegadores pueden cachear resultados DNS indirectamente mediante reutilización de conexiones y caches internas, pero el problema operativo más grande suele ser la caché de resolvers recursivos y el caching en runtimes de aplicaciones.

9) ¿Cómo afecta DNSSEC a la caché negativa?

DNSSEC puede hacer las respuestas negativas verificables (negación autenticada de existencia), lo que puede aumentar la confianza en el cacheo. También introduce modos de fallo (SERVFAIL) cuando la validación falla—diferente de NXDOMAIN.

10) ¿Cuál es la forma más segura de desplegar un hostname nuevo para un servicio crítico?

Precrea el registro con suficiente antelación, verifica desde múltiples resolvers recursivos, mantén el TTL negativo corto en esa zona y monitoriza la resolución continuamente.

Próximos pasos que puedes hacer esta semana

La caché negativa no es una villana. Es una palanca. Si no la configuras intencionalmente, la configurarán por ti—por defecto, por legado y por la última persona que “optimizó DNS”.

Haz estas tres cosas

Audita tus TTLs negativos en SOA para zonas usadas por servicios dinámicos. Si el número está en horas, estás escogiendo caídas largas.
Añade un panel al dashboard: tasa de NXDOMAIN y top nombres NXDOMAIN en tus recursores. No puedes gestionar lo que no ves, y los picos de NXDOMAIN son a menudo el primer humo.
Escribe un runbook de vaciado de caché para cada capa de resolver que operes (systemd-resolved, node-local, CoreDNS, Unbound/BIND). Incluye comandos de verificación y resultados esperados.

Si quieres una regla operativa simple: mantén la caché negativa corta donde los nombres nacen y mueren rápido, y más larga donde el espacio de nombres es estable. No es ideología. Es alinear el comportamiento de la caché con la forma en que tu negocio realmente entrega cambios.