Actualizaste un registro DNS. Esperaste “unos minutos”. Tu panel aún muestra la IP antigua. Alguien en Slack dice,
“el DNS se rompió otra vez”, y otra persona sugiere reiniciar cosas al azar hasta que el gráfico se ponga verde.
Aquí está la realidad: normalmente el DNS no está roto. Tu cambio simplemente está atascado detrás de un caché específico, en algún punto
entre tu servidor autoritativo y los ojos del usuario. El truco es encontrar qué caché te está mintiendo,
vaciar solo lo que ayuda y dejar el resto en paz—porque el vaciado equivocado puede convertir un retraso menor en un incidente grave.
Modelo mental: de dónde vienen realmente las respuestas DNS
Cuando la gente dice “propagación DNS”, imaginan un único sistema global sincronizándose lentamente. Eso no es lo que sucede.
El DNS es una cadena de delegaciones y cachés, y cada eslabón puede decidir de forma independiente qué devolver y por cuánto tiempo.
Publicas registros en un servidor autoritativo (o proveedor). Pero la mayoría de los clientes nunca hablan con él.
Preguntan a un resolutor recursivo (a menudo tu ISP, la red corporativa o un resolutor público), y ese resolutor
guarda respuestas en caché. Luego tu sistema operativo puede almacenar en caché. Tu navegador puede almacenar en caché. Tu aplicación puede almacenar en caché. Tu service mesh puede hacer un “cacheo útil”.
Tu balanceador de carga podría mantener una asignación upstream obsoleta. Y luego Kubernetes CoreDNS podría tener su propia opinión.
Un “cambio DNS no visible” casi siempre es uno de estos:
- No cambiaste lo que crees que cambiaste (zona equivocada, registro equivocado, nombre equivocado, vista equivocada).
- Lo cambiaste, pero los TTL dicen “aún no” (incluyendo el cacheo negativo, que es más sigiloso).
- Lo cambiaste, pero estás probando a través de un caché (resolutor local, reenvío corporativo, navegador, etc.).
- Lo cambiaste, pero distintos usuarios reciben respuestas diferentes (DNS geo, EDNS Client Subnet, split-horizon).
La meta no es “vaciar todo”. La meta es: identificar el caché cuello de botella y luego elegir la acción segura más pequeña.
Los sistemas de producción premian la precisión.
Guía de diagnóstico rápido (comprueba 1/2/3)
Si estás de guardia, quieres un camino de 60–180 segundos hacia la claridad. Aquí está el orden que suele minimizar el daño autoinfligido.
1) Comprueba la verdad autoritativa (elude cachés)
Interroga directamente a los servidores de nombres autoritativos por el registro que cambiaste. Si lo autoritativo no lo muestra, para.
Tu problema no es “propagación”. Tu problema es publicación.
- Encuentra los registros NS de la zona.
- Consulta cada NS directamente con
dig @nsX. - Verifica el registro, el TTL y cualquier cadena CNAME.
2) Comprueba el resolutor que realmente usa la ruta que falla
Si lo autoritativo es correcto, prueba el resolutor recursivo que usa el cliente afectado. Eso puede ser:
reenvío corporativo, resolutor VPC, caché local en el nodo o un resolutor público.
Compara:
- Sección ANSWER (A/AAAA/CNAME)
- TTL restante (si es alto, estás esperando, no está roto)
- NXDOMAIN vs NOERROR (el cacheo negativo también significa “estás esperando”)
3) Revisa los cachés del cliente al final (SO, navegador, app)
Solo después de que lo autoritativo y lo recursivo sean sensatos, atacas la máquina local. Porque vaciar local es barato,
pero también una distracción: puedes “arreglarlo en tu portátil” mientras los usuarios de producción siguen viendo datos obsoletos.
Idea parafraseada de Richard Cook (ingeniería de resiliencia): “El éxito y el fallo provienen de los mismos procesos cotidianos.”
El cacheo DNS es uno de esos procesos. Está haciendo su trabajo—hasta que necesitas que deje de hacerlo.
Qué cachés existen (y de qué suelen ser culpables)
1) Comportamiento del servidor autoritativo (no es un caché, pero a menudo se le culpa)
Tus servidores autoritativos sirven lo que esté en el archivo/base de datos de zona ahora mismo. Si están equivocados:
registro equivocado, zona equivocada, no sincronizados, secundario obsoleto, vista equivocada, o editaste una interfaz que escribe en otro lugar
diferente al que crees.
Un modo de fallo clásico: actualizas www.example.com pero el tráfico en realidad está usando api.example.com
vía una cadena CNAME que olvidaste que existía.
2) Cachés de resolutores recursivos (el gran culpable)
Los resolutores recursivos cachean por TTL. Ese es el punto. Si pusiste TTL a 3600 ayer y cambias el registro ahora,
algunos resolutores mantendrán la respuesta antigua hasta una hora desde la última vez que la consultaron.
Peor: los resolutores también cachean respuestas negativas (NXDOMAIN, NODATA). Si un resolutor preguntó recientemente por
un registro que no existía, puede cachear esa respuesta de “no existe” según el SOA mínimo/TTL negativo de la zona.
La gente olvida esto y luego jura que Internet los está volviendo locos.
3) Reenvíos y capas DNS corporativas (donde la verdad va a “optimizarse”)
Muchas redes usan una cadena: cliente → stub local → reenvío corporativo → recursivo upstream. Cada salto puede cachear.
Cada salto también puede reescribir comportamientos: filtrado DNS, split-horizon, reenvío condicional o aparatos “de seguridad”
que hacen MITM de DNS.
4) Caché del resolver stub del SO (systemd-resolved, mDNSResponder, Windows DNS Client)
Los SO modernos a menudo guardan respuestas DNS localmente por rendimiento. Esto suele ser una caché pequeña, pero suficiente para hacer
que tu portátil esté en desacuerdo con tu servidor, lo cual basta para desperdiciar una tarde.
5) Cachés a nivel de aplicación (Java, Go, comportamientos de glibc y afines)
Algunos runtimes cachean resultados DNS de forma agresiva o impredecible. Java históricamente cacheaba para siempre a menos que se configure.
Algunos clientes HTTP agrupan conexiones y siguen usando una IP antigua sin resolver de nuevo. Eso no es cacheo DNS. Es
reutilización de conexión. Otro error distinto, mismo síntoma: “Cambié DNS y no pasó nada.”
6) Cachés del navegador
Los navegadores mantienen sus propias cachés y pre-resuelven nombres. También pueden mantener conexiones establecidas y seguir hablando con el
endpoint antiguo incluso después de los cambios DNS.
7) CDN / resolutores de borde y funciones geo
Si usas DNS geo, enrutamiento por latencia o EDNS Client Subnet, distintos resolutores recursivos obtienen respuestas diferentes.
Puedes estar “bien” en un lugar y “mal” en otro sin ningún error—solo por política.
8) DNS de Kubernetes (CoreDNS) y cachés node-local
En clústeres, el DNS es una dependencia como cualquier otra. CoreDNS cachea. Cachés node-local también.
Y luego tu app puede cachear otra vez. Si depuras un servicio que no ve un endpoint nuevo, debes decidir
desde qué capa estás probando: pod, nodo o fuera del clúster.
Tareas prácticas: comandos, salidas y decisiones (12+)
Estas son tareas reales que puedes ejecutar. Cada una incluye: el comando, qué significa una salida típica y qué decisión tomar.
Usa dig cuando puedas. nslookup está bien, pero oculta detalles que a menudo necesitas (TTL, flags, autoridad).
Tarea 1: Encontrar los servidores de nombres autoritativos para una zona
cr0x@server:~$ dig +noall +answer example.com NS
example.com. 3600 IN NS ns1.dns-provider.net.
example.com. 3600 IN NS ns2.dns-provider.net.
Qué significa: Estos son los registros NS autoritativos que el mundo debería usar.
Decisión: Consulta estos directamente a continuación. Si no ves al proveedor que esperas, estás editando la zona equivocada o la delegación es errónea.
Tarea 2: Consultar autoritativos directamente (eludir cachés recursivos)
cr0x@server:~$ dig @ns1.dns-provider.net www.example.com A +noall +answer +authority
www.example.com. 300 IN A 203.0.113.42
example.com. 3600 IN SOA ns1.dns-provider.net. hostmaster.example.com. 2025123101 7200 900 1209600 300
Qué significa: Autoritativo dice que el registro A es 203.0.113.42 con TTL 300 segundos.
Decisión: Si esto está mal, corrige la publicación (registro/valor/zona). Si está bien, tu problema es cacheo aguas abajo o comportamiento del cliente.
Tarea 3: Comparar todos los servidores autoritativos (capturar secundarios obsoletos)
cr0x@server:~$ for ns in ns1.dns-provider.net ns2.dns-provider.net; do echo "== $ns =="; dig @$ns www.example.com A +noall +answer; done
== ns1.dns-provider.net ==
www.example.com. 300 IN A 203.0.113.42
== ns2.dns-provider.net ==
www.example.com. 300 IN A 198.51.100.77
Qué significa: División en la autoritatividad. Diferentes NS sirven respuestas distintas.
Decisión: Deja de depurar cachés. Corrige la distribución de la zona/AXFR/IXFR/primario oculto, o la sincronización del proveedor. Hasta que los autoritativos no estén de acuerdo, todo lo demás es ruido.
Tarea 4: Comprobar qué ve un resolutor recursivo público
cr0x@server:~$ dig @1.1.1.1 www.example.com A +noall +answer
www.example.com. 245 IN A 203.0.113.42
Qué significa: El resolutor público tiene el valor nuevo; TTL restante es 245 segundos.
Decisión: Si los usuarios aún ven datos antiguos, pueden estar usando un resolutor diferente (corporativo/VPC), o el problema es cacheo local/de la app.
Tarea 5: Comprobar explícitamente un resolutor corporativo/VPC
cr0x@server:~$ dig @10.20.30.40 www.example.com A +noall +answer
www.example.com. 3240 IN A 198.51.100.77
Qué significa: Este resolutor aún tiene la respuesta antigua en caché, con casi una hora restante.
Decisión: Esperar (mejor), o vaciar la caché de ese resolutor si lo posees y el vaciado es seguro. No reinicies media flota.
Tarea 6: Detectar cacheo negativo (NXDOMAIN) en el resolutor
cr0x@server:~$ dig @10.20.30.40 newhost.example.com A +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41433
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
example.com. 300 IN SOA ns1.dns-provider.net. hostmaster.example.com. 2025123101 7200 900 1209600 300
Qué significa: Se está devolviendo NXDOMAIN y el SOA en autoridad sugiere el comportamiento del TTL negativo.
Decisión: Si acabas de crear newhost, este resolutor puede estar cacheando “no existe” por hasta el TTL negativo del SOA. Puedes vaciar la caché del resolutor o esperar; no sigas “intentando de nuevo” esperando resultados distintos.
Tarea 7: Seguir cadenas CNAME hasta el objetivo real
cr0x@server:~$ dig www.example.com A +noall +answer
www.example.com. 300 IN CNAME www.example.com.cdn.vendor.net.
www.example.com.cdn.vendor.net. 60 IN A 203.0.113.42
Qué significa: Tu “cambio de registro” podría estar en el hostname del CDN, no en el nombre de fachada.
Decisión: Depura la zona correcta. Si solo controlas www.example.com pero el proveedor controla el destino, vaciar tus cachés no cambiará los TTL del proveedor.
Tarea 8: Verificar qué resolutor está usando realmente tu host Linux (systemd-resolved)
cr0x@server:~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.40
DNS Servers: 10.20.30.40 10.20.30.41
Qué significa: Tu máquina está usando 10.20.30.40 como su resolutor, no el que probaste antes.
Decisión: Consulta ese resolutor directamente. Si está obsoleto, vaciar tu navegador no ayudará.
Tarea 9: Vaciar la caché de systemd-resolved (lado cliente)
cr0x@server:~$ sudo resolvectl flush-caches
Qué significa: Caché stub local borrada.
Decisión: Vuelve a probar con dig desde el mismo host. Si los resultados no cambian, el problema está aguas arriba o no es DNS.
Tarea 10: Inspeccionar la ruta NSS de glibc (¿realmente estás usando DNS?)
cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
Qué significa: Las búsquedas consultan /etc/hosts primero, luego el comportamiento mDNS y luego DNS.
Decisión: Si alguien fijó una IP antigua en /etc/hosts, ningún vaciado de DNS lo arreglará. Revisa /etc/hosts a continuación.
Tarea 11: Comprobar si /etc/hosts está sobreescribiendo tu cambio
cr0x@server:~$ grep -n 'www.example.com' /etc/hosts
12:198.51.100.77 www.example.com
Qué significa: El host está codificado con la IP antigua.
Decisión: Elimina o actualiza la entrada. Esto no es un problema DNS; es una sobrescritura local.
Tarea 12: Observar la resolución real via getent (lo que suelen usar tus apps)
cr0x@server:~$ getent ahostsv4 www.example.com
203.0.113.42 STREAM www.example.com
203.0.113.42 DGRAM
203.0.113.42 RAW
Qué significa: La pila resolutora del sistema (NSS + stub) está devolviendo la IP nueva.
Decisión: Si tu app aún se conecta al endpoint antiguo, sospecha de pooling de conexiones, upstreams fijados o una capa interna de descubrimiento de servicios.
Tarea 13: Comprobar TTLs y cacheo en BIND (resolutor que controlas)
cr0x@server:~$ sudo rndc status
version: BIND 9.18.24
running on dns-cache-01: Linux x86_64 6.8.0
number of zones: 102
recursive clients: 17/1000/1000
Qué significa: Estás ejecutando un resolutor recursivo (o al menos BIND está presente).
Decisión: Si esta es la capa de caché que devuelve respuestas obsoletas, planifica un vaciado de caché controlado (tarea siguiente) en lugar de reiniciar el daemon a ciegas.
Tarea 14: Vaciar la caché de BIND de forma segura (enfoque dirigido)
cr0x@server:~$ sudo rndc flushname www.example.com
Qué significa: BIND elimina las entradas de caché para ese nombre (y datos relacionados).
Decisión: Prefiere flushname sobre un vaciado global durante horas hábiles. El vaciado global puede provocar estampidas a upstream y hacer que la latencia parezca un outage.
Tarea 15: Comprobar el comportamiento de CoreDNS dentro de Kubernetes
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
ttl 30
}
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
Qué significa: CoreDNS está explícitamente cacheando por 30 segundos, además el plugin de Kubernetes tiene TTL 30.
Decisión: Si “los cambios DNS no son visibles” dura minutos, es poco probable que la caché de CoreDNS sea la culpable. Busca aguas arriba o en el cacheo de la app.
Tarea 16: Probar desde dentro de un pod (saca tu portátil de la historia)
cr0x@server:~$ kubectl run -it --rm dns-debug --image=alpine:3.20 -- sh -lc "apk add --no-cache bind-tools >/dev/null && dig www.example.com A +noall +answer"
www.example.com. 300 IN A 203.0.113.42
Qué significa: El clúster ve la respuesta nueva.
Decisión: Si una carga en-clúster aún golpea la IP antigua, sospecha de la aplicación (reutilización de conexión) o un sidecar/service mesh.
Tarea 17: Demostrar que no es DNS—ver a dónde van las conexiones
cr0x@server:~$ curl -sS -o /dev/null -w "remote_ip=%{remote_ip}\n" https://www.example.com/
remote_ip=198.51.100.77
Qué significa: Aún te conectas a la IP antigua aunque el DNS diga lo contrario (o TLS/SNI te enrute allí).
Decisión: Revisa proxies, balanceadores de carga, configuración del CDN y si tu cliente está reutilizando una conexión existente. El DNS puede ya estar correcto.
Tarea 18: Comprobar si hay un demonio de caché local en juego (nscd)
cr0x@server:~$ systemctl is-active nscd
inactive
Qué significa: nscd no está corriendo, así que no es tu capa de caché.
Decisión: No pierdas tiempo vaciando lo que no existe. Encuentra el componente de caché real.
Cachés que no debes vaciar (a menos que disfrutes los incidentes)
Vaciar cachés es como apagar y encender un router: se siente productivo, a veces es necesario y es peligrosamente adictivo.
Algunos cachés son seguros de limpiar localmente. Otros son infraestructura compartida y vaciarlos puede causar una estampida.
No vacíes globalmente grandes resolutores recursivos durante horas punta
Si administras una flota de resolutores corporativos o una capa de resolutores VPC compartida, un vaciado global puede desencadenar:
- Picos de QPS hacia upstream
- Aumento de latencia y timeouts
- Dependencia amplificada en resolutores externos
- Fallos en cascada en apps que tratan los timeouts DNS como fatales
Prefiere vaciados dirigidos (flushname / por zona / por view) o, mejor, espera el TTL cuando sea seguro.
No reinicies CoreDNS como primera medida
Reiniciar CoreDNS puede romper la resolución de nombres en todo el clúster. Esa es una gran radio de impacto para un problema que a menudo es solo TTL.
Si sospechas cacheo en CoreDNS, confirma con dig dentro de un pod e inspecciona el Corefile primero.
No “arregles” bajando TTLs en pánico
Bajar TTLs es una herramienta de planificación, no una palanca de emergencia. Bajar el TTL ahora no ayuda a clientes que ya cachearon la respuesta antigua.
Solo afecta la siguiente vez que se rellene la caché.
Chiste #1: El cacheo DNS es como el chisme de oficina: una vez que se difunde, corregirlo lleva más tiempo que empezarlo.
Hechos interesantes y un poco de historia del DNS
- DNS reemplazó el dolor de escalado de HOSTS.TXT. Los hosts de ARPANET usaban un archivo hosts compartido; al crecer la red, la distribución se volvió el cuello de botella.
- TTL no fue diseñado para tu ritmo de despliegues. Fue pensado para hacer un sistema de nombres global escalable y resiliente, no para que los redireccionamientos de marketing sean instantáneos.
- El cacheo negativo está estandarizado. Cachear “no existe” es intencional; de otro modo los resolutores bombardearían a los autoritativos por nombres inexistentes.
- El registro SOA influye en el cacheo negativo. El campo “minimum”/TTL negativo del SOA tiene una larga historia de confusión; distintas herramientas lo etiquetan de formas distintas.
- Los resolutores cachean más que A/AAAA. También cachean delegaciones NS y comportamiento glue, lo que puede hacer que cambios de delegación se sientan “pegajosos” aun cuando una actualización de registro sea rápida.
- DNS suele usar UDP. Eso es bueno para la velocidad, pero significa que la pérdida de paquetes y problemas de MTU pueden fingir un “DNS obsoleto.” Existe la caída a TCP, pero no siempre es fiable.
- EDNS Client Subnet cambió la dinámica de cacheo. Algunos resolutores varían respuestas según la subred del cliente, lo que reduce las tasas de acierto en caché y aumenta los momentos de “pero a mí me funciona”.
- Los navegadores se convirtieron en participantes DNS. Los navegadores modernos prerresuelven, cachean independientemente y a veces abren múltiples conexiones en competencia, así que el DNS ya no es solo una preocupación del SO.
Tres microhistorias corporativas desde las trincheras
Microhistoria 1: El incidente causado por una suposición equivocada
Una empresa mediana migró una API orientada al cliente a un nuevo balanceador de carga. El plan era claro: actualizar el registro A de
api.example.com del VIP antiguo al nuevo VIP. Pusieron TTL a 300 una semana antes. Bien.
El día del corte, la mitad del tráfico se movió. La otra mitad siguió golpeando la infraestructura antigua y empezó a presentar timeouts porque
el pool del balanceador antiguo estaba drenándose. El canal de incidentes se llenó de “el DNS no propagó.”
La suposición equivocada: todos consultaban api.example.com. No era así. Un cliente móvil legado tenía codificado
api-v2.example.com, que era un CNAME a un nombre del proveedor con TTL de 3600. El equipo había cambiado el nombre de fachada
que conocían los humanos, no la cadena de dependencias que usaban los dispositivos.
La solución no fue vaciar cachés. La solución fue actualizar el objetivo CNAME real (a través del flujo del proveedor) y mantener temporalmente
vivo el VIP antiguo. También documentaron la cadena CNAME completa en su runbook, porque el conocimiento tribal no es una estrategia de gestión de cambios.
Microhistoria 2: La optimización que salió mal
Otra organización se cansó de los picos de latencia DNS y decidió “optimizar” añadiendo cacheo agresivo por todos lados:
cacheo node-local en nodos Kubernetes, más una capa interna de reenvío, más una librería de cacheo dentro de la app.
El argumento sonaba bien: menos consultas, respuestas más rápidas, menor coste.
Luego introdujeron despliegues blue/green detrás de DNS. Durante un rollout, algunos pods resolvieron el endpoint nuevo y tuvieron éxito.
Otros siguieron usando el endpoint antiguo y fallaron. Sus dashboards parecían un código de barras: éxito/fallo alternando cada pocos segundos.
El problema vino de la composición de cachés y semánticas de TTL desajustadas. La caché de la app mantenía entradas más tiempo que el TTL del SO.
La caché node-local respetaba TTL pero tenía un bug que fijaba respuestas negativas más tiempo bajo carga. La capa de reenvío tenía
delegaciones obsoletas tras un cambio de nameserver. Cada capa “funcionaba”, pero la composición fue caos.
La recuperación fue tediosa: eliminar el cacheo DNS a nivel de aplicación, estandarizar en una sola capa de cacheo (node-local o central,
no ambas) y alertar sobre tasas de SERVFAIL en resolutores. También dejaron de usar DNS como herramienta de cambio fino de tráfico
y pasaron a pesos de balanceador para cortes rápidos.
Microhistoria 3: La práctica aburrida pero correcta que salvó la noche
Una compañía financiera tenía un proceso de cambios impulsado por cumplimiento que todos se burlaban hasta que pagó dividendos. Necesitaban mover
un endpoint de integración externo. La integración usaba un hostname, no una IP fija, lo cual ya era una buena señal.
Dos semanas antes del movimiento, bajaron el TTL de 3600 a 300. No en pánico—según el calendario. Validaron el TTL nuevo consultando autoritativos y varios recursores. También capturaron respuestas base en un ticket, incluida la cadena CNAME y el SOA.
En la noche del corte, cambiaron el registro, verificaron autoritativos y luego verificaron a través de sus resolutores corporativos.
No vaciaron cachés. Miraron los TTLs bajar. Para el pequeño número de clientes detrás de un resolutor terco,
aplicaron un vaciado dirigido en la capa de resolutores que poseían.
La migración aterrizó sin impacto a clientes. Nadie mandó un email de victoria porque la corrección aburrida no se vuelve viral.
Pero el ingeniero de guardia durmió, que es el único KPI que importa a las 2 a.m.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: “Autoritativo muestra IP nueva, pero algunos usuarios siguen golpeando la IP antigua por horas”
Causa raíz: Los resolutores recursivos cachearon la respuesta antigua con un TTL alto, o bajaste TTL demasiado tarde.
Solución: Espera a que caduque el TTL; la próxima vez baja TTL al menos una ventana TTL completa antes del cambio. Si controlas el resolutor, realiza un vaciado dirigido por nombre.
2) Síntoma: “El hostname nuevo devuelve NXDOMAIN aunque lo creamos”
Causa raíz: Cacheo negativo en resolutores recursivos por consultas anteriores cuando el registro no existía.
Solución: Comprueba el TTL negativo en el SOA; vacía la caché del resolutor si lo controlas, o espera. Evita crear registros “justo a tiempo” si puedes preaprovisionarlos.
3) Síntoma: “Funciona en mi portátil, falla en producción”
Causa raíz: Resolutores diferentes. Tu portátil usa un resolutor público o VPN; producción usa resolutor VPC o reenvío interno con caché obsoleta.
Solución: Consulta directamente el resolutor de producción. No uses tu propia máquina como dispositivo de medición para producción.
4) Síntoma: “dig muestra la IP nueva, pero el servicio aún se conecta a la IP antigua”
Causa raíz: Pooling de conexiones / keep-alives / clientes de larga duración (no DNS). O enrutamiento de proxy basado en SNI/Host.
Solución: Verifica la IP remota con curl -w %{remote_ip}; reinicia o recarga el pool de clientes, no la capa DNS. Considera reducir keep-alive o refresco DNS proactivo en el cliente.
5) Síntoma: “Algunas regiones ven la respuesta nueva, otras no”
Causa raíz: DNS geo / enrutamiento por latencia / EDNS Client Subnet, o vistas split-horizon.
Solución: Prueba con resolutores en esas regiones o en puntos de egress corporativos. Confirma las políticas de enrutamiento del proveedor. Asegúrate de haber cambiado la vista correcta.
6) Síntoma: “Después de vaciar el resolutor, todo se volvió más lento”
Causa raíz: Estampida de caché. Forzaste una caché fría en muchos nombres, aumentando QPS upstream y latencia.
Solución: Evita vaciados globales. Usa vaciados dirigidos. Si debes vaciar globalmente, hazlo fuera de pico y vigila saturación upstream y tasas de SERVFAIL.
7) Síntoma: “Solo un servidor ve el registro antiguo”
Causa raíz: Sobrescritura local en /etc/hosts, demonio de caché local o resolv.conf/resolved distinto.
Solución: Revisa /etc/hosts, resolvectl status y getent. Vacía el stub cache local solo después de confirmar la ruta resolutora local.
8) Síntoma: “Cambiamos registros NS y ahora algunos clientes no resuelven el dominio”
Causa raíz: Cacheo de delegación y TTLs de glue/parent; algunos resolutores aún usan el conjunto NS antiguo.
Solución: Planifica cambios de NS con mayor antelación. Mantén los nameservers antiguos sirviendo la zona durante al menos la ventana TTL relevante. Espera comportamiento mixto durante la transición; no lo interpretes como “aleatorio”.
Chiste #2: Vaciar cachés DNS es la única vez que “¿has probado apagar y encender?” puede DDoS tu propia infraestructura.
Listas de verificación / plan paso a paso
Checklist A: Cambiaste un registro A/AAAA y los usuarios no lo ven
- Verifica la verdad autoritativa: consulta cada NS autoritativo directamente. Confirma valor y TTL.
- Comprueba la cadena CNAME: asegúrate de no haber cambiado un nombre que nadie realmente consulta.
- Identifica el resolutor en la ruta que falla: resolutor del cliente, DNS corporativo, resolutor VPC.
- Mide el TTL restante en ese resolutor: si el TTL es alto, esperar es correcto.
- Elige acción:
- Si controlas el resolutor: vaciado dirigido para ese nombre.
- Si no controlas: espera; considera mitigaciones temporales (mantén vivo el endpoint antiguo).
- Sólo entonces: vacía el stub del SO en clientes de prueba para reducir confusión.
- Valida la realidad: confirma a dónde van las conexiones (IP remota), no solo lo que devuelve DNS.
Checklist B: Creaste un hostname nuevo y devuelve NXDOMAIN
- Consulta autoritativos directamente: ¿existe el registro allí ya?
- Si lo autoritativo es correcto, consulta el resolutor que falla y busca NXDOMAIN + SOA en autoridad.
- Decide: espera a que expire el TTL negativo, o vacía el resolutor si lo controlas.
- Prevención: crea registros antes del go-live para evitar cacheo negativo el día del lanzamiento.
Checklist C: Cambiaste registros NS (zona peligrosa)
- Confirma que la delegación de la zona padre es correcta (lo que sirve el registro/parent).
- Confirma que los nuevos nameservers sirven la zona correctamente y de manera consistente.
- Mantén los nameservers antiguos activos y sirviendo la zona durante al menos la ventana TTL máxima relevante.
- Espera comportamiento mixto durante la transición; no lo interpretes como “aleatorio”. Es delegación cacheada.
Checklist D: Decide qué vaciar (mínima radio de impacto)
- Vacía el stub local si solo tu estación de trabajo está equivocada:
resolvectl flush-caches. - Vacía un único nombre en un resolutor que posees si el impacto de negocio es real:
rndc flushname. - No vacíes caches de resolutores globales a menos que tengas un plan de capacidad y un comandante de incidente que disfrute el dolor.
- No reinicies servicios DNS como sustituto de la comprensión del problema.
Preguntas frecuentes
1) ¿Por qué la interfaz de mi proveedor DNS muestra el valor nuevo pero los usuarios siguen obteniendo el antiguo?
La UI del proveedor muestra datos autoritativos. Los usuarios suelen consultar resolutores recursivos que cachearon el valor antiguo hasta que expire el TTL.
Confirma consultando autoritativos directamente y luego el resolutor del usuario.
2) Si bajo el TTL ahora, ¿acelerará el cambio actual?
Mayormente no. Los resolutores que ya tienen la respuesta antigua la mantendrán hasta que su TTL en caché caduque.
Bajar el TTL ayuda la siguiente vez que se rellene la caché.
3) ¿Qué significa realmente “propagación DNS”?
No es una ola sincronizada única. Son cachés independientes que expiran en distintos tiempos a través de resolutores recursivos,
reenvíos, stubs del SO, navegadores y aplicaciones.
4) ¿Qué caché debo vaciar primero?
Ninguna. Primero, confirma que lo autoritativo es correcto. Segundo, identifica el resolutor en la ruta que falla. Vacía solo la capa
que esté probada como obsoleta—y solo si la controlas y el radio de impacto es aceptable.
5) ¿Por qué veo NXDOMAIN por un registro que ahora existe?
Cacheo negativo. Un resolutor puede haber cacheado “no existe” cuando el registro aún no estaba presente. Esa caché puede persistir
según el TTL negativo del SOA. Vacía el resolutor si puedes; de lo contrario espera.
6) ¿Por qué dig muestra la IP nueva pero mi app aún usa la antigua?
Porque tu app puede que no esté volviendo a resolver. Podría reutilizar una conexión en pool, cachear DNS en proceso
o enrutar vía un proxy que tiene su propio mapeo upstream.
7) ¿Deberíamos ejecutar caché DNS node-local en Kubernetes?
Puede ser excelente para rendimiento y resiliencia, pero añade otra capa a depurar. Si lo haces, estandariza y documenta:
dónde ocurre el cacheo, TTLs esperados y cómo probar desde pod/nodo. Evita apilar múltiples cachés sin razón.
8) ¿Es útil vaciar la caché DNS del navegador?
A veces, para un caso de un solo usuario “mi portátil está raro”. No solucionará usuarios en producción. Úsalo como limpieza de último tramo,
no como estrategia de propagación.
9) ¿Cuál es la forma más segura de manejar cortes DNS planificados?
Preaprovisiona, baja TTL con antelación, valida respuestas autoritativas, mantén viejos endpoints activos durante la ventana TTL,
y monitoriza destinos reales de conexión. Usa vaciado dirigido en resolutores solo cuando sea necesario.
10) ¿Por qué distintos resolutores públicos muestran respuestas diferentes?
Pueden haber cacheado en distintos momentos, estar en distintas regiones, aplicar políticas distintas o recibir respuestas distintas
por EDNS Client Subnet o enrutamiento geo. Esa diversidad es normal.
Siguientes pasos que puedes hacer hoy
- Añade “autoritativo primero” a tu runbook: siempre verifica respuestas directas de NS antes de tocar cachés.
- Documenta tu ruta real de resolutores: qué resolutores usa producción, dónde existen cachés y quién los posee.
- Estandariza tus herramientas: prefiere
dig+getent+ “comprobar IP remota” sobre conjeturas. - Planifica cambios de TTL: baja TTLs antes de migraciones planificadas; no esperes que ediciones de última hora te salven.
- Adopta vaciados dirigidos: si operas resolutores, soporta flush por nombre. Haz del vaciado global una acción explícitamente aprobada.
Los cambios DNS “no visibles” rara vez son misteriosos. Normalmente son cachés haciendo exactamente lo que fueron diseñados para hacer,
en el peor momento posible para tu cronograma. Tu trabajo es encontrar el único caché que importa y dejar en paz al resto del planeta.