Ubuntu 24.04: las cachés DNS mienten — vacía la caché correcta (y deja de vaciar la incorrecta) (caso #26)

diciembre 25, 2025 • febrero 3, 2026 • Lectura: 23 min • Views: 8

¿Te fue útil?

Las fallas DNS rara vez se anuncian como “fallas DNS”. Aparecen como un error TLS, un tiempo de espera en un cliente de API, un nodo de Kubernetes que “no puede descargar imágenes”, o un portátil que solo falla en la red Wi‑Fi de la oficina. Entonces alguien invoca la antigua letanía: “vaciar DNS”. Diez minutos después sigue fallando. Has perdido tiempo y reforzado la confianza en un ritual equivocado.

Ubuntu 24.04 es un lugar especialmente bueno para aprender esta lección, porque puede implicar múltiples capas de caché y más de una ruta de resolución. El resultado: tus cachés DNS pueden mentir —no de forma maliciosa, sino por funcionamiento mecánico. Tu tarea es vaciar la caché que realmente está sirviendo la respuesta y probarlo con herramientas que no mientan.

El modelo mental: DNS es una tubería, no una sola consulta

Cuando alguien dice “caché DNS”, normalmente imagina un único depósito de respuestas. En realidad, DNS en una máquina moderna con Ubuntu es una tubería:

El comportamiento del resolutor de la aplicación (glibc NSS, el resolutor puro de Go, Java, curl con c-ares, la propia caché de Chromium).
Resolutor stub local (a menudo systemd-resolved escuchando en 127.0.0.53).
Un reenviador con caché local (a veces dnsmasq, a veces ninguno).
Resolutores recursivos ascendentes (DNS corporativo, ISP, resolutor cloud, Unbound, BIND).
DNS autoritativo (Route 53, Cloud DNS, BIND on‑prem, etc.).
Anycast y bordes CDN (porque “respuesta DNS” puede variar según dónde estés).

Cualquiera de esas capas puede hacer caché. Cualquiera de ellas puede tener reglas distintas sobre TTL, caché negativa (caché de “NXDOMAIN”), comportamiento DNSSEC, o qué servidor DNS es “preferido”. Así que sí, tu máquina puede seguir insistiendo en que api.internal.example apunta a una IP antigua incluso después de que “vaciaste DNS”. Probablemente vaciaste una caché que no se estaba usando.

Regla práctica: Empieza siempre probando qué componente está respondiendo. Vaciar antes de saber qué vaciar es como reiniciar antes de mirar los registros. A veces funciona. Eso no lo convierte en una estrategia.

Una idea parafraseada de Gene Kim (operaciones y confiabilidad): Mejora los resultados acortando los bucles de retroalimentación; haz los problemas visibles rápidamente y arregla el sistema en vez de confiar en heroísmos.

Hechos interesantes y contexto histórico (por qué esto es tan enmarañado)

Hecho 1: DNS es anterior a la web por años; se diseñó para una internet más pequeña y de cambios lentos. El caché fue una característica, no un accidente.
Hecho 2: El concepto de “stub resolver” existe porque la mayoría de las aplicaciones no deberían implementar un DNS recursivo completo. Preguntan a un agente local, que a su vez pregunta a la red.
Hecho 3: El clásico archivo /etc/resolv.conf se diseñó para servidores estáticos. Los sistemas modernos a menudo lo generan dinámicamente, a veces como enlace simbólico.
Hecho 4: El caché negativo (caché de “no existe”) está estandarizado. Por eso un registro brevemente ausente puede perseguirte más tiempo del que esperas.
Hecho 5: El “split-horizon DNS” (respuestas distintas según desde dónde consultes) es común en redes corporativas. También hace que depurar se sienta como si te estuvieran volviendo loco.
Hecho 6: systemd-resolved existe en parte para unificar un mundo caótico de DNS por interfaz, DNS de VPN y decisiones DNSSEC. Puede que no te guste, pero intenta detener el sangrado.
Hecho 7: Algunos lenguajes evitan glibc e implementan su propio DNS. Go es el ejemplo famoso, pero no el único. Tu aplicación puede no usar la misma ruta que dig.
Hecho 8: Los navegadores también hacen caché DNS. Incluso si la caché del SO está perfecta, un navegador puede mantener una respuesta obsoleta y hacer que culpes a la red.

Depurar DNS es molesto porque es estado distribuido. Cuando el estado está distribuido, la confianza es un lujo. La evidencia es más barata.

Pila de resolutores en Ubuntu 24.04: ¿quién responde a tu pregunta?

En Ubuntu 24.04, lo más común por defecto es:

systemd-resolved ejecutándose como servicio.
Un stub resolver en 127.0.0.53, expuesto mediante un /etc/resolv.conf generado.
Servidores DNS ascendentes proporcionados por NetworkManager, netplan/systemd-networkd, DHCP o clientes VPN.

Pero las máquinas en producción nunca permanecen “por defecto” mucho tiempo. Podrías tener:

dnsmasq instalado para caché local o DNS dividido para contenedores.
nscd (Name Service Cache Daemon) aún merodeando por guías de afinamiento antiguas.
Componentes de Kubernetes, Docker o systemd-networkd manipulando DNS por interfaz.
Una VPN que impone sus propios servidores DNS y reglas de enrutamiento.
Aplicaciones que usan DoH (DNS sobre HTTPS) o sus propias librerías de resolución.

El punto: “Vaciar DNS” no es un único comando. Es un árbol de decisiones.

Broma #1: DNS es como el chisme de oficina: se propaga rápido, está en caché en todas partes, y la retractación tiene un TTL mucho más bajo.

Qué significa “vaciar”

Vaciar solo ayuda si:

La capa en cuestión realmente hace caché.
La capa está realmente en uso para la consulta que falla.
La falla se debe a estado en caché obsoleto (no a enrutamiento, firewall, desajuste TLS SNI, configuración de proxy o selección de IPv6).

Si un registro está mal en el DNS autoritativo, vaciar clientes no lo arreglará. Si los resolutores recursivos ascendentes están sirviendo datos obsoletos por su propia caché, vaciar un portátil no lo solucionará. Y si la aplicación nunca pregunta al SO por DNS, vaciar systemd-resolved es arte performativo.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Este es el orden que uso en on-call. Está optimizado para “qué cambió, qué está roto y cuál es la prueba más rápida”.

1) Confirma que el síntoma es DNS, no “no alcanza la IP”

Si tienes una dirección IP esperada, intenta conectarte directamente por IP (HTTP con Host header, TLS con consideraciones SNI).
Si la IP directa funciona pero el nombre falla, probablemente estás en terreno DNS.

2) Identifica qué ruta de resolutor usa la app que falla

¿Usa glibc NSS? (La mayoría de las herramientas nativas de Linux sí).
¿Es Go con resolutor puro? ¿Es Java? ¿Un navegador con su propia caché/DoH?
¿Se ejecuta en un contenedor con un /etc/resolv.conf diferente?

3) Pregunta al stub del SO qué cree

Usa resolvectl query y comprueba el estado de la caché, la selección de servidores y los registros.

4) Interroga directamente a los resolutores ascendentes

Usa dig @server name contra el resolutor corporativo y luego contra un resolutor conocido bueno en la misma red.
Compara respuestas y TTLs.

5) Vacía la capa específica que está equivocada

Vacía la caché de systemd-resolved si está equivocada.
Reinicia dnsmasq si está en la ruta y hace caché.
Elimina caches del navegador/aplicación si el SO está bien pero la app está mal.

6) Si las cachés parecen consistentes: sospecha de split DNS, enrutamiento VPN o selección de IPv6

Comprueba DNS por interfaz y reglas de enrutamiento.
Revisa si la app prefiere registros AAAA que no enrutan a ninguna parte.

Tareas prácticas (con comandos, salidas y decisiones)

Estas son tareas reales que puedes ejecutar en Ubuntu 24.04. Cada una incluye: comando, ejemplo de salida, qué significa y qué decisión tomar.

Task 1: See what `/etc/resolv.conf` really is

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jun 21 08:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Significado: Estás usando el stub de systemd-resolved (probablemente 127.0.0.53). Muchas guías de “vaciar DNS” para otras distribuciones no aplicarán.

Decisión: Usa resolvectl y systemctl para inspeccionar y vaciar. No edites /etc/resolv.conf a mano a menos que estés sobreescribiendo intencionadamente el sistema.

Task 2: Confirm `systemd-resolved` is running

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:10:14 UTC; 2h 11min ago
       Docs: man:systemd-resolved.service(8)
             man:resolvectl(1)
   Main PID: 812 (systemd-resolve)
     Status: "Processing requests..."

Significado: La caché local y el stub están activos.

Decisión: Vaciar nscd o reiniciar servicios aleatorios de red probablemente sea el movimiento equivocado. Empieza con resolvectl.

Task 3: Inspect resolver configuration (servers, interfaces, DNSSEC)

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

Link 2 (ens3)
Current Scopes: DNS
     Protocols: +DefaultRoute
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.example

Significado: Tu sistema usa resolutores corporativos, y el servidor activo es 10.20.0.53. Esto te indica a quién interrogar a continuación.

Decisión: Si el servidor upstream está equivocado o es inconsistente, vaciar cachés locales no lo arreglará. Necesitarás consultar los resolutores ascendentes directamente y posiblemente escalar con quien los administre.

Task 4: Ask the OS resolver for a name and see what it returns

cr0x@server:~$ resolvectl query api.internal.example
api.internal.example: 10.70.8.19                           -- link: ens3

-- Information acquired via protocol DNS in 11.2ms.
-- Data is authenticated: no

Significado: Esto es lo que el resolutor del SO cree ahora mismo. También te dice qué enlace (interfaz) y por tanto qué configuración DNS por interfaz se usó.

Decisión: Si la respuesta del SO es incorrecta, vacía la caché de systemd-resolved. Si está correcta pero tu app está mal, sospecha caché a nivel de aplicación o una ruta de resolutor distinta.

Task 5: Check if the result is coming from cache

cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no

Transactions
        Current Transactions: 0
              Total Requests: 14382
            Cache Hits: 9112
          Cache Misses: 5270

Cache
          Current Cache Size: 216
                  Cache Hits: 9112
                Cache Misses: 5270

Significado: Esto confirma que la caché está activa y se usa. Muchos aciertos en caché durante un incidente pueden significar que sirves respuestas obsoletas repetidamente.

Decisión: Si sospechas caché obsoleta, vacíala y vuelve a consultar; luego verifica si las respuestas ascendentes cambiaron.

Task 6: Flush `systemd-resolved` cache (the right “flush” most of the time)

cr0x@server:~$ sudo resolvectl flush-caches

Significado: No hay salida es normal. Esto limpia cachés de systemd-resolved (positivas y negativas).

Decisión: Ejecuta inmediatamente resolvectl query de nuevo. Si la respuesta sigue siendo incorrecta, el resolutor upstream probablemente esté sirviendo la misma información errónea.

Task 7: Prove what the upstream resolver says (bypass local cache)

cr0x@server:~$ dig @10.20.0.53 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.internal.example.  300 IN A 10.70.8.19

Significado: El resolutor upstream devuelve el mismo registro A con TTL 300 segundos. Si está mal, el upstream está mal (o el autoritativo está mal).

Decisión: Si controlas el upstream, vacía allí o corrige el autoritativo. Si no controlas el upstream, usa un resolutor alternativo solo si la política lo permite y el DNS dividido no te romperá.

Task 8: Compare with another resolver to detect split DNS or resolver inconsistency

cr0x@server:~$ dig @10.20.0.54 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28490
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

Significado: Dos resolutores corporativos discrepan. Eso no es “DNS siendo DNS”; es una replicación/reenvío/caché roto o una mala configuración de split-horizon.

Decisión: Deja de vaciar clientes. Elige el resolutor que esté correcto (temporalmente) o haz failover mediante el orden de resolutores, y abre un incidente para el equipo DNS.

Task 9: See if you’re dealing with negative caching (NXDOMAIN)

cr0x@server:~$ resolvectl query new-service.internal.example
new-service.internal.example: resolve call failed: 'new-service.internal.example' not found

Significado: NXDOMAIN (o equivalente) puede estar en caché. Si el registro se creó hace poco, tu ruta de resolutor puede seguir negando su existencia por un tiempo.

Decisión: Vacía las cachés en la capa que produce NXDOMAIN. Luego consulta autoritativos/ascendentes directamente. Si el autoritativo sigue diciendo NXDOMAIN, deja de culpar a las cachés y corrige los datos DNS.

Task 10: Inspect NSS order (is DNS even consulted?)

cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns

Significado: Este sistema consulta /etc/hosts primero, luego mDNS, luego DNS. Una entrada obsoleta en /etc/hosts anulará todo.

Decisión: Si la resolución de nombres está “mal pero consistente”, comprueba /etc/hosts. Vaciar cachés no sobrescribirá un archivo.

Task 11: Check for an override in `/etc/hosts`

cr0x@server:~$ grep -n 'api.internal.example' /etc/hosts
12:10.70.8.19 api.internal.example

Significado: Ese hostname está fijado localmente. Tus cambios DNS no importarán hasta que elimines o actualices esa línea.

Decisión: Corrige la entrada (o elimínala). Luego vuelve a probar. Este es el caso raro donde editar un archivo vence a vaciar una caché.

Task 12: Confirm what glibc-based tools see (getent is your friend)

cr0x@server:~$ getent ahosts api.internal.example
10.70.8.19      STREAM api.internal.example
10.70.8.19      DGRAM
10.70.8.19      RAW

Significado: getent utiliza la configuración NSS del sistema. Si getent coincide con resolvectl, la ruta del SO es consistente.

Decisión: Si la aplicación aún se comporta diferente, puede estar usando su propio resolutor o caché. Sube la depuración por la pila.

Task 13: Identify whether a local caching forwarder like dnsmasq is in play

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

Significado: dnsmasq no está ejecutándose como servicio del sistema. Bien: una capa de caché menos.

Decisión: No reinicies dnsmasq “por si acaso”. Si está inactivo, no es tu caché. Enfócate en otra parte.

Task 14: Check if `nscd` is caching host lookups

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

Significado: No hay NSCD. Muchos posts sobre “vaciar caché DNS en Linux” son fósiles de la era NSCD.

Decisión: Si está inactivo, deja de intentar vaciarlo. Si está activo en tu entorno, tienes que gestionarlo deliberadamente (y considerar eliminarlo si entorpece tu pila de resolución).

Task 15: Confirm which nameserver your tools actually query (127.0.0.53 vs direct)

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

Significado: La mayoría de la resolución basada en libc pasa por el stub. Pero dig puede evitarlo a menos que lo señales a 127.0.0.53 o a un resolutor upstream explícitamente.

Decisión: Al comparar herramientas, asegúrate de que consulten lo mismo. Si no, estás depurando dos sistemas distintos y lo llamas “inconsistente”.

Task 16: Query the stub resolver directly with dig

cr0x@server:~$ dig @127.0.0.53 api.internal.example +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.internal.example.  287 IN A 10.70.8.19

Significado: Esta es la vista en caché actual del stub. El decremento del TTL sugiere que estás viendo datos en caché (lo cual es normal).

Decisión: Si vacías y el TTL se reinicia (o la respuesta cambia), has probado que la caché del stub importaba. Si nada cambia, la mentira está en upstream.

Task 17: Look for per-interface DNS that might be different under VPN

cr0x@server:~$ resolvectl dns
Global: 10.20.0.53 10.20.0.54
Link 2 (ens3): 10.20.0.53 10.20.0.54
Link 3 (tun0): 172.16.100.1

Significado: La interfaz VPN tun0 tiene su propio servidor DNS. Dependiendo de dominios de enrutamiento, las consultas pueden ir allí.

Decisión: Si nombres internos solo resuelven en la VPN, eso es esperado. Si nombres públicos fallan en la VPN, puede que estés filtrando/sobrescribiendo DNS de una forma que la app no espera.

Task 18: Check if you have a routing/domain search rule that changes resolution

cr0x@server:~$ resolvectl domain
Global: corp.example
Link 2 (ens3): corp.example
Link 3 (tun0): ~internal.example

Significado: El prefijo ~ indica un dominio de solo enrutamiento (split DNS). Las consultas para internal.example van al resolutor de la VPN, otras no.

Decisión: Si responde el resolutor equivocado, corrige la configuración de split DNS en lugar de vaciar cachés. Vaciar no cambia reglas de enrutamiento.

Broma #2: Vaciar la caché equivocada es el equivalente en operaciones a desenchufar el monitor para arreglar un deadlock de base de datos.

Tres micro-historias corporativas desde las trincheras DNS

Mini-historia 1: El incidente causado por una suposición equivocada (la trampa de “dig es la verdad”)

Una compañía SaaS de tamaño medio hacía una migración por etapas de una API interna de una VPC a otra. El plan era limpio: bajar TTLs con antelación, actualizar registros A durante una ventana de mantenimiento, monitorizar tasas de error y volver atrás si hacía falta. El equipo probó resolución con dig desde un bastión, vio la IP nueva y declaró el DNS “hecho”.

Treinta minutos después, las flotas de workers empezaron a fallar en los health checks. El error no era “NXDOMAIN” ni “no se pudo resolver el host”. Eran timeouts de conexión. On-call persiguió grupos de seguridad, gateways NAT y balanceadores. Todo parecía bien. Mientras tanto, dig seguía mostrando la IP nueva. La confianza seguía mal ubicada.

La trampa: sus workers estaban escritos en Go, usando una configuración de resolutor que evitaba el stub local y mantenía su propia política de caché. En los nodos afectados con Ubuntu 24.04, systemd-resolved estaba correcto, pero los procesos Go se quedaron anclados a respuestas antiguas más tiempo del esperado, debido al comportamiento de caché del runtime y a la reutilización de conexiones. Algunos procesos ni siquiera hacían consultas nuevas porque las conexiones keepalive se mantenían hacia endpoints muertos.

La resolución vino de cambiar el procedimiento de despliegue, no de “vaciar más fuerte”. Añadieron un reinicio controlado de procesos tras los cambios DNS para esa clase de servicio y validaron la resolución a través de la misma ruta que usan los workers (un binario diagnóstico pequeño vinculado de forma similar). También dejaron de usar “dig en el bastión” como su definición de la realidad.

La lección quedó clara: el resolutor con el que pruebas debe coincidir con el que usa tu carga de trabajo. Si no, estás midiendo otra cosa y la llamas validación.

Mini-historia 2: La optimización que salió mal (edición reenviador con caché local)

Un equipo de plataforma empresarial decidió “mejorar el rendimiento DNS” en agentes de build. Instaló dnsmasq como reenviador local con caché, pensando que los scripts de build hacen muchas consultas contra repositorios internos de artefactos. También activaron configuraciones de caché agresivas para reducir latencia y carga sobre los resolutores corporativos.

Funcionó—hasta que dejó de hacerlo. Una rotación de certificados coincidió con mover un servicio interno detrás de un VIP nuevo. El nombre de servicio siguió igual, pero la IP cambió. El DNS autoritativo y los resolutores corporativos se comportaron correctamente. Pero los agentes de build siguieron intentando la IP antigua más allá del TTL. Algunos se recuperaron con el tiempo, otros no, y las fallas eran extrañamente “pegajosas” por máquina.

La causa raíz no fue un simple “bug de dnsmasq”. Fue deriva de configuración: algunos agentes tenían distinto tamaño de caché y reglas de TTL, y unos pocos tenían dos capas locales de resolutor (dnsmasq delante de systemd-resolved) porque las imágenes evolucionaron. El resultado fue semántica de caché inconsistente y variación difícil de depurar. Los ingenieros empezaron a reiniciar la red al azar, lo que a veces ayudaba y mayormente era pérdida de tiempo.

La solución fue aburrida y efectiva: eliminar dnsmasq de la mayoría de los agentes, conservarlo solo donde el split DNS fuera realmente necesario, y apoyarse en resolutores upstream estables diseñados para caché a escala. Para los pocos casos que necesitaban reenvío local, estandarizaron configuraciones y añadieron una comprobación sencilla “qué resolutor estoy usando” al pipeline de aprovisionamiento.

Lección de optimización: añadir capas de caché incrementa el número de formas en que puedes fallar. Las ganancias de rendimiento son reales, pero debes pagar en operabilidad.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día (disciplina TTL y verificación escalonada)

Una compañía de servicios financieros ejecutaba un sistema interno de descubrimiento de servicios donde los registros DNS se actualizaban por automatización durante failovers. El equipo ya había sufrido antes por cachés obsoletos, así que hicieron algo poco emocionante: escribieron un runbook y lo siguieron como adultos.

Antes de cualquier movimiento planificado, redujeron TTLs 24 horas antes. No a “5 segundos”, sino a un valor que sus resolutores y clientes respetarían sin causar avalanchas de consultas. También tenían una secuencia de verificación estándar: consultar autoritativos, consultar cada resolutor recursivo corporativo, luego consultar un cliente representativo a través del stub. Solo después de que todo coincidiera, cambiaban el tráfico.

Durante un incidente, un failover ocurrió limpiamente pero un subconjunto de clientes todavía golpeaba el objetivo antiguo. El runbook hizo rápida la investigación: el autoritativo estaba correcto, un resolutor recursivo corporativo estaba sirviendo datos obsoletos. Porque ya tenían la lista de recursores y un conjunto estándar de consultas, aislaron el resolutor malo, lo quitaron temporalmente del ámbito DHCP y restauraron el servicio mientras el equipo DNS arreglaba el resolutor.

No pasó nada heroico. Nadie “encontró el comando mágico de vaciado”. Simplemente tuvieron evidencia, en orden, y un plan preacordado. Eso fue lo que los salvó.

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

1) Síntoma: “`dig` muestra la IP nueva, pero la app sigue alcanzando la antigua”

Causa raíz: Rutas de resolutor diferentes o caché/reutilización de conexiones a nivel de app. dig no es tu aplicación.

Solución: Valida con getent ahosts (ruta glibc) y con el comportamiento DNS del runtime de la aplicación. Considera reiniciar el servicio tras cambios DNS si el runtime cachea o mantiene conexiones abiertas.

2) Síntoma: “Vaciar DNS local no hace nada”

Causa raíz: La caché equivocada. El resolutor recursivo upstream está sirviendo datos obsoletos, o el nombre está fijado en /etc/hosts.

Solución: Consulta resolutores ascendentes directamente con dig @server. Revisa /etc/hosts. Escala al dueño del DNS si el upstream está equivocado.

3) Síntoma: “Funciona por Ethernet, falla por VPN (o al revés)”

Causa raíz: Split DNS y reglas de resolutor por interfaz. Diferentes dominios se enrutan a resolutores distintos, a veces inesperadamente.

Solución: Inspecciona resolvectl dns y resolvectl domain. Arregla dominios de solo enrutamiento y ajustes DNS que impone la VPN en lugar de vaciar cachés.

4) Síntoma: “Nuevo hostname devuelve NXDOMAIN minutos después de su creación”

Causa raíz: Caché negativa en alguna capa de resolución.

Solución: Vacía las cachés donde se produce NXDOMAIN (systemd-resolved, dnsmasq, recursivos upstream). Confirma que el autoritativo tiene el registro.

5) Síntoma: “Clientes aleatorios fallan, otros están bien”

Causa raíz: Inconsistencia en el pool de resolutores (dos recursivos discrepan) o deriva de imágenes/configuración que causa comportamiento de caché mixto.

Solución: Consulta cada resolutor configurado directamente y compara. Estandariza la configuración de resolutores y elimina capas de caché adicionales salvo que resuelvan un problema real.

6) Síntoma: “El hostname resuelve a IPv6 y las conexiones fallan; IPv4 funciona”

Causa raíz: Hay registros AAAA pero la ruta de red para IPv6 está rota o filtrada; el comportamiento de Happy Eyeballs varía por aplicación.

Solución: Consulta AAAA y A por separado, valida enrutamiento IPv6, o ajusta temporalmente registros/política. No lo trates como un problema de caché hasta probarlo.

7) Síntoma: “Tras cambiar servidores DNS, la máquina sigue consultando los antiguos”

Causa raíz: Configuración por interfaz obsoleta, VPN imponiendo ajustes, o un /etc/resolv.conf estático que sobrescribe.

Solución: Usa resolvectl status para ver servidores actuales. Corrige netplan/NetworkManager/perfiles VPN; evita editar a mano archivos generados.

Listas de comprobación / plan paso a paso (haz esto, no intuiciones)

Checklist A: “Se acaba de hacer un cambio DNS y algunos clientes están mal”

En un cliente afectado: captura la vista del SO con resolvectl query name.
Captura la vista upstream: dig @current_upstream name +noall +answer +comments.
Compara con un segundo resolutor upstream si existe.
Si el upstream difiere: trátalo como inconsistencia de resolutor. Escala y/o saca el resolutor malo de la rotación.
Si el upstream coincide pero está mal: consulta autoritativos (desde un lugar que pueda alcanzarlos) y corrige datos DNS.
Si el SO está bien pero la app está mal: revisa el resolutor del runtime y caches de la app; reinicia/recarga el servicio si procede.

Checklist B: “Deja de vaciar la caché equivocada”

Comprueba ls -l /etc/resolv.conf. Si apunta al stub de systemd, estás en el mundo de systemd-resolved.
Comprueba systemctl is-active systemd-resolved. Si está inactivo, vaciarlo es un placebo.
Busca capas extra: systemctl is-active dnsmasq, systemctl is-active nscd.
Usa getent ahosts como tu referencia para “lo que ven las apps basadas en libc”.

Checklist C: “Migración planificada con flips de DNS”

Baja TTLs con antelación (horas a un día, según el comportamiento de caché de tu entorno).
Documenta qué resolutores están en uso (ámbitos DHCP, perfiles VPN, recursivos del datacenter).
Durante la ventana, verifica en este orden:
1. La respuesta autoritativa es correcta.
2. Cada resolutor recursivo responde correctamente y el TTL es razonable.
3. Clientes representativos a través del stub devuelven la respuesta correcta.
4. Las aplicaciones resuelven correctamente mediante su ruta real de resolutor.
Tener un plan de rollback que no dependa de “vaciar las cachés de todos”. Si tu rollback depende de invalidación manual, no es un plan.

Preguntas frecuentes

1) ¿Cuál es la caché “correcta” para vaciar en Ubuntu 24.04?

La mayoría de las veces: systemd-resolved. Usa sudo resolvectl flush-caches y luego comprueba con resolvectl query.

2) ¿Por qué “reiniciar la red” a veces arregla DNS?

Porque puede reiniciar o reconfigurar la pila de resolución (interfaces, servidores DNS, dominios de búsqueda). También es un instrumento contundente que puede causar nuevas interrupciones. Prefiere comprobaciones dirigidas con resolvectl status.

3) ¿Por qué `dig` muestra una respuesta y `getent` otra?

dig interroga al servidor DNS que le indiques (o al predeterminado, dependiendo de cómo lo ejecutes). getent sigue NSS y a menudo usa el stub local. No son equivalentes a menos que hagas que consulten el mismo resolutor.

4) ¿Ubuntu 24.04 hace caché DNS en glibc?

glibc en sí no proporciona una caché DNS de propósito general como un daemon. El caché suele ocurrir en systemd-resolved, dnsmasq, nscd o dentro de aplicaciones.

5) ¿Cómo sé si `/etc/hosts` está anulando DNS?

Revisa /etc/nsswitch.conf para el orden de hosts:, luego busca el hostname en /etc/hosts. Si está presente, DNS es irrelevante hasta arreglar el archivo.

6) ¿Y la caché DNS del navegador en Ubuntu?

Los navegadores suelen cachear DNS y pueden usar su propio resolutor o DoH. Si las herramientas del SO muestran la respuesta correcta pero el navegador no, limpia la caché de host del navegador o desactiva/ajusta DoH en ese entorno.

7) ¿Qué pasa si vacié `systemd-resolved` y la respuesta sigue siendo incorrecta?

Entonces la respuesta incorrecta viene del upstream o del DNS autoritativo, o no estás usando systemd-resolved para esa ruta de consulta. Prueba el comportamiento upstream con dig @upstream e inspecciona DNS por interfaz con resolvectl status.

8) ¿Puede el split DNS de la VPN causar síntomas de “caché DNS”?

Sí. Puede parecer una caché porque las respuestas varían según la interfaz y dominios de enrutamiento. Usa resolvectl domain y resolvectl dns para ver a dónde van los nombres.

9) ¿Debería desactivar `systemd-resolved` para hacer DNS “simple”?

Usualmente no. Desactivarlo puede empeorar VPN y DNS por interfaz, no mejorarlos. Si necesitas una arquitectura diferente (por ejemplo, Unbound local), hazlo intencionalmente y documéntalo. “Simple” no es simple si nadie sabe qué está ejecutándose.

10) ¿Cuál es la forma más segura de validar un cambio DNS?

Consulta autoritativos, luego cada resolutor recursivo, y luego clientes representativos mediante su ruta real de resolución. Si alguna capa discrepa, trátala como incidente hasta probar lo contrario.

Conclusión: siguientes pasos que puedes hacer hoy

Deja de tratar los vaciados de caché DNS como purificación espiritual. En Ubuntu 24.04, la caché que más importa suele ser systemd-resolved, y el modo de fallo más común es vaciarla cuando la mentira viene de upstream—o cuando la app ni siquiera le preguntó.

Haz lo siguiente:

En tus imágenes de flota, estandariza una pila de resolución (y elimina capas de caché extra a menos que puedas justificarlas).
Enseña a tu equipo a usar resolvectl status, resolvectl query y getent ahosts como evidencia base.
Para cada incidente relacionado con DNS, registra: la respuesta del stub del cliente, la respuesta del resolutor upstream y si la aplicación usa la ruta de resolutor del SO.
Para migraciones planificadas, crea un runbook que verifique autoritativo → recursivo → cliente e incluya un rollback que no dependa de vaciar cachés manualmente.