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

El modelo real: dónde se almacenan respuestas DNS en caché en Ubuntu 24.04

El DNS en un host Ubuntu moderno es una carrera de relevos, y cada corredor puede llevar su propia libreta. Cuando consultas “¿qué es api.example.internal hoy?”, la respuesta puede venir de:

1) Tu aplicación (sí, tu app)

Muchos runtimes almacenan DNS en caché de forma agresiva o extraña:

• Java: el caché DNS depende de propiedades de seguridad; en algunas configuraciones puede cachear indefinidamente.
• Go: puede usar el resolvedor del sistema o un resolvedor puro-Go según flags de compilación y entorno; el comportamiento difiere.
• Python: las librerías pueden cachear, los clientes HTTP pueden reutilizar conexiones, y los “problemas DNS” a veces son sockets keep-alive obsoletos.
• glibc: tradicionalmente no ofrece una caché DNS completa, pero tiene comportamientos como options attempts, timeout, y puede verse influida por módulos NSS.

Si tu app cachea DNS, vaciar systemd-resolved no ayudará. Reiniciar la app podría.

2) NSS (Name Service Switch) y su orden de operaciones

El archivo /etc/nsswitch.conf decide si el host comprueba /etc/hosts antes que DNS, si usa mDNS, y más. Una línea como esta:

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

…significa que /etc/hosts puede anular DNS, y que mDNS puede interrumpir las búsquedas. Cuando alguien dice “DNS miente”, a veces no es DNS: es NSS obedeciendo tus archivos locales.

3) systemd-resolved (el sospechoso habitual en Ubuntu 24.04)

Ubuntu 24.04 comúnmente ejecuta systemd-resolved y apunta /etc/resolv.conf a un resolvedor stub (a menudo 127.0.0.53). Ese stub cachea respuestas, realiza validación DNSSEC según la configuración, puede usar DNS sobre TLS y puede enrutar consultas por enlace (por interfaz) según la configuración de red.

4) Un resolvedor local de caché que instalaste a propósito

Algunos entornos despliegan dnsmasq, unbound o bind9 en hosts o nodos. Esa es una caché separada. Vaciar systemd-resolved no vaciará unbound. Impactante, lo sé.

5) Resolutores upstream: DNS corporativo, resolutores VPC, kube-dns/CoreDNS, resolutores ISP

Aun si tu host está limpio, los resolutores upstream también cachean—a menudo con sus propios TTL mínimos, comportamiento de prefetch o configuraciones de caché negativa. Si tu resolutor upstream está sirviendo datos obsoletos, tu host no puede “vaciarlo”. Solo puedes evitarlo o forzar su actualización (y puede que no tengas permiso).

6) Middleboxes de red y productos de seguridad “útiles”

Algunas redes corporativas interceptan DNS. Algunas reescriben respuestas. Otras bloquean dominios específicos. Si tus paquetes nunca llegan al resolutor que crees estar usando, la caché que vacías es irrelevante.

Una idea parafraseada, porque sigue siendo el mejor consejo operativo: no puedes arreglar lo que no puedes observar (atrib. a temas de fiabilidad/DevOps de Gene Kim).

Regla operativa: Antes de vaciar cualquier cosa, demuestra qué capa respondió la pregunta y qué resolutor fue realmente contactado. De lo contrario estarás “arreglando” DNS como quien “arregla” impresoras: con force.

Broma #1: DNS es el único sistema donde “está cacheado” es a la vez una explicación y una confesión.

Hechos interesantes y contexto histórico (lo que hace que el lío actual tenga sentido)

1. La caché negativa de DNS existe desde hace décadas. Las respuestas NXDOMAIN pueden cachearse usando el valor mínimo del SOA, así que “no existía hace cinco minutos” puede permanecer.
2. La historia de los resolvedores en Ubuntu ha cambiado varias veces. Entre resolvconf, systemd-resolved, NetworkManager y netplan, el “lugar correcto” para configurar DNS depende de la era.
3. /etc/resolv.conf suele ser un enlace simbólico ahora. En sistemas con systemd puede apuntar a un archivo stub gestionado por resolved; editarlo directamente puede revertirse en reboot o al cambiar enlaces.
4. glibc históricamente evitó una caché DNS completa. Esa decisión empujó el caching a demonios dedicados (como nscd) y más tarde a systemd-resolved y a aplicaciones.
5. Los navegadores se volvieron sus propios resolvedores. Los navegadores modernos hacen cacheo agresivo, prefetching y a veces DNS-over-HTTPS; “funciona con dig” no garantiza “funciona en Chrome”.
6. TTL no es una promesa; es una sugerencia. Algunos resolutores limitan TTLs (mínimos/máximos), y algunos clientes extienden el cacheo por políticas internas.
7. Split-horizon DNS es una característica, no un bug. El mismo nombre puede resolverse de forma diferente según la red de origen; la respuesta “incorrecta” puede ser la correcta para otra interfaz.
8. IPv6 puede “ganar” aunque no lo quieras. Muchos clientes prueban AAAA primero; si tu camino IPv6 está roto, parece que hay inestabilidad en DNS.
9. systemd-resolved puede enrutar DNS por enlace. ¿VPN arriba? Ahora la mitad de tus nombres van al resolutor de la VPN y la otra mitad al resolutor LAN, según los dominios de enrutamiento.

Guía rápida de diagnóstico (revisa esto primero, en orden)

Este es el camino más corto hacia la verdad cuando “DNS está mal” en Ubuntu 24.04. No improvises. Sigue la cadena.

Paso 1: Identifica qué está haciendo realmente la aplicación

• ¿Usa el resolvedor del sistema (glibc/NSS) o un resolvedor interno (navegador, JVM, Go netgo)?
• ¿El “problema DNS” es realmente un pool de conexiones TCP obsoleto?
• ¿Se ejecuta en un contenedor con su propio /etc/resolv.conf?

Paso 2: Prueba cuál es la pila de resolvedores del host

• ¿Es /etc/resolv.conf un stub a 127.0.0.53?
• ¿Está activo systemd-resolved?
• ¿Está involucrado dnsmasq, unbound, nscd?

Paso 3: Compara respuestas a través de rutas

• Compara getent hosts (ruta NSS) vs dig @server (resolvedor directo) vs comportamiento de la app.
• Revisa tanto A como AAAA, y confirma cuál se usa.

Paso 4: Si hay caché, encuentra qué caché

• Vacía systemd-resolved solo si es la capa de caché en uso.
• Si el resolutor upstream está obsoleto, evítalo o consulta resolutores autorizados/alternativos para confirmar.
• Si la app cachea, reinicia o reconfigura la app—no sigas golpeando el SO.

Paso 5: Valida en la red

• Usa tcpdump en el puerto 53 (o 853 para DoT) para ver si las consultas salen del equipo.
• Si no salen paquetes, no estás tratando con “problemas de servidor DNS”; estás tratando con resolución local.

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

Estas están diseñadas para ejecutarse en servidores y escritorios Ubuntu 24.04. Cada tarea incluye (1) un comando, (2) qué significa la salida y (3) qué decisión tomar a continuación.

Tarea 1: Ver qué es realmente /etc/resolv.conf

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

Significado: Estás usando el stub de systemd-resolved. La mayoría de las aplicaciones consultarán a 127.0.0.53, no a tus servidores DNS upstream directamente.

Decisión: Deja de editar /etc/resolv.conf a mano. Inspecciona la configuración de resolved y el DNS por enlace.

Tarea 2: Confirma que systemd-resolved está activo

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 Fri 2025-12-26 10:12:01 UTC; 2h 41min ago
       Docs: man:systemd-resolved.service(8)

Significado: Hay un stub de caché local en juego.

Decisión: Usa resolvectl como herramienta principal de diagnóstico; vaciar resolved puede ser relevante.

Tarea 3: Encuentra los servidores DNS upstream que usa resolved

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
        DNS Domain: corp.internal

Link 2 (ens160)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.internal

Significado: Los servidores upstream son 10.20.0.53/54, y hay un dominio de enrutamiento (corp.internal).

Decisión: Si las respuestas están obsoletas, debes determinar si la obsolescencia está en la caché de resolved o en 10.20.0.53.

Tarea 4: Compara la ruta NSS frente a la consulta DNS directa

cr0x@server:~$ getent hosts api.corp.internal
10.50.12.19     api.corp.internal

cr0x@server:~$ dig +short api.corp.internal
10.50.12.19

Significado: Por ahora, NSS y el stub resolver coinciden.

Decisión: Si la aplicación sigue golpeando una IP antigua, sospecha caché a nivel de app o reutilización de conexiones.

Tarea 5: Evita el stub y consulta el servidor upstream directamente

cr0x@server:~$ dig @10.20.0.53 api.corp.internal +noall +answer +ttlid
api.corp.internal.  30  IN  A  10.50.12.19

Significado: El resolutor upstream devuelve 10.50.12.19 con TTL 30 segundos.

Decisión: Si tu host devuelve otra cosa, el problema es caching/rutado local. Si el upstream está equivocado, vaciar localmente es pura teatralidad.

Tarea 6: Comprueba si /etc/hosts está sobreescribiendo DNS

cr0x@server:~$ grep -n 'api.corp.internal' /etc/hosts || true
12:10.10.10.10 api.corp.internal

Significado: Tienes una anulación codificada. NSS probablemente devolverá esto antes que DNS.

Decisión: Elimina o corrige la entrada, luego vuelve a probar con getent hosts. Vaciar cachés no arreglará un archivo.

Tarea 7: Inspecciona el orden de NSS para búsquedas de hosts

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

Significado: files (es decir, /etc/hosts) va primero. mDNS puede interceptar algunos nombres.

Decisión: Si persigues un nombre que podría manejar mDNS (.local), pruébalo con y sin él. Si la política corporativa prohíbe sorpresas mDNS, ajusta el orden.

Tarea 8: Vacía la caché de systemd-resolved (solo cuando sea la capa correcta)

cr0x@server:~$ sudo resolvectl flush-caches

Significado: Resolved descarta respuestas positivas y negativas en caché.

Decisión: Ejecuta inmediatamente resolvectl query name o getent hosts. Si las respuestas no cambian, la “mentira” no está en la caché de resolved.

Tarea 9: Muestra estadísticas de caché (¿se está usando la caché?)

cr0x@server:~$ resolvectl statistics
DNSSEC Verdicts:                 Secure=0 Insecure=0 Bogus=0 Indeterminate=0
Cache:                           Current Cache Size=42 Max Cache Size=4096
Cache Hits:                      118
Cache Misses:                    67
Cache Evictions:                 0
DNS Transactions:                79

Significado: Resolved está cacheando y sirviendo hits. Si los hits de caché son altos y las respuestas erróneas persisten, vaciar puede ayudar—a menos que la respuesta incorrecta se recupere de upstream.

Decisión: Si los hits de caché están cerca de cero, probablemente tu problema no sea el cacheo de resolved; busca caché a nivel de app o un resolvedor distinto.

Tarea 10: Consulta vía resolved con detalles

cr0x@server:~$ resolvectl query api.corp.internal
api.corp.internal: 10.50.12.19                       -- link: ens160

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

Significado: Muestra qué enlace/interfaz se usó. Eso es crítico cuando existen VPNs o múltiples NICs.

Decisión: Si la consulta sale por el enlace “equivocado”, corrige la configuración DNS por enlace (netplan/NetworkManager/systemd-networkd), no las cachés.

Tarea 11: Captura DNS en la red (demuestra si las consultas salen del host)

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:41:15.219233 ens160 Out IP 10.20.1.44.53344 > 10.20.0.53.53: 12345+ A? api.corp.internal. (35)
10:41:15.245090 ens160 In  IP 10.20.0.53.53 > 10.20.1.44.53344: 12345 1/0/0 A 10.50.12.19 (51)

Significado: Las consultas salen hacia 10.20.0.53 y las respuestas regresan. Si tu app todavía ve otra IP, el problema está por encima de la ruta de resolución del SO (caché en la app o reutilización de conexiones) o en una diferencia de split-horizon en el entorno de la app.

Decisión: Si no ves consultas salientes mientras ejecutas búsquedas, estás golpeando una caché local o un mecanismo totalmente distinto (como DoH en un navegador).

Tarea 12: Comprueba si se usa DoT (puerto 853)

cr0x@server:~$ sudo tcpdump -ni any 'tcp port 853'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:43:50.102991 ens160 Out IP 10.20.1.44.42132 > 10.20.0.53.853: Flags [S], seq 205383221, win 64240, options [mss 1460,sackOK,TS val 151512 ecr 0,nop,wscale 7], length 0

Significado: Estás usando DNS-over-TLS. Algunos middleboxes y herramientas asumen UDP/53 solamente; te confundirá.

Decisión: Al diagnosticar “DNS bloqueado”, comprueba reglas de firewall para 853 y confirma soporte en el resolutor.

Tarea 13: Valida lo que ve un contenedor (ejemplo Docker)

cr0x@server:~$ sudo docker run --rm alpine:3.20 cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0

Significado: Los contenedores pueden usar el DNS embebido de Docker (127.0.0.11), que es su propia capa de cacheo/forwarding.

Decisión: Si solo los contenedores fallan, deja de vaciar cachés del host e inspecciona la configuración DNS del contenedor y del motor.

Tarea 14: Ve a qué IPs se conecta realmente tu app

cr0x@server:~$ sudo ss -tnp | grep ':443' | head
ESTAB 0 0 10.20.1.44:50412 10.10.10.10:443 users:(("myapp",pid=23144,fd=27))

Significado: La app está conectada a 10.10.10.10. Si DNS dice 10.50.12.19, puede que tengas pool de conexiones obsoleto, un resultado antiguo en el proceso o una anulación en /etc/hosts.

Decisión: Reinicia la app o recicla su pool de conexiones; no sigas echándole la culpa a DNS hasta que hayas demostrado una búsqueda nueva.

Tarea 15: Comprueba nscd (otra capa de caché)

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

Significado: nscd no está activo. Bien: una caché menos con la que discutir.

Decisión: Si está activo en tu entorno, aprende cómo cachea y vacíalo intencionalmente; de lo contrario perseguirás fantasmas.

Tarea 16: Identifica quién posee el puerto 53 localmente (conflictos)

cr0x@server:~$ sudo ss -lunp | grep ':53 ' || true
UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=862,fd=13))

Significado: El stub resolver está escuchando. Si esperabas dnsmasq en 127.0.0.1:53, eso es una incongruencia.

Decisión: No ejecutes múltiples demonios DNS locales sin un plan; decide qué proceso posee el stub y cómo deben alcanzarlo los clientes.

Tarea 17: Comprueba la caché negativa (NXDOMAIN) que podría quedarse atascada

cr0x@server:~$ resolvectl query doesnotexist.corp.internal
doesnotexist.corp.internal: resolve call failed: 'does not exist'

Significado: NXDOMAIN está en juego. Si ese nombre se creó hace poco, puedes estar combatiendo caché negativa upstream o local.

Decisión: Vacía cachés locales, luego consulta upstream directamente. Si upstream aún devuelve NXDOMAIN, el cambio DNS no se ha propagado allí.

Vaciar la caché correcta (y por qué el consejo habitual está equivocado)

El clásico mal consejo dice: “En Linux, ejecuta sudo systemctl restart networking” o “reinicia NetworkManager” o “edita /etc/resolv.conf y pon 8.8.8.8.” Ese consejo pertenece a un museo junto a los módems dial-up.

Qué puede significar “vaciar DNS” en Ubuntu 24.04

• Vaciar systemd-resolved: sudo resolvectl flush-caches
• Reiniciar resolved (más drástico): sudo systemctl restart systemd-resolved
• Vaciar caché del navegador: no es un comando del SO; es una acción/ajuste del navegador
• Vaciar DNS embebido de Docker: a menudo requiere reiniciar contenedores o el demonio; no es el stub del host
• Vaciar el resolutor upstream: requiere acceso a ese resolutor; no puedes hacerlo desde una máquina cliente

Cómo elegir el vaciado correcto

Usa este árbol de decisiones:

1. Si getent hosts name está mal pero dig @upstream name está bien: vacía systemd-resolved (y revisa dominios de enrutamiento por enlace).
2. Si getent está bien pero tu app está mal: probablemente sea caché en la app, conexiones persistentes obsoletas o una ruta de resolvedor diferente (DoH, netgo, JVM).
3. Si dig @upstream está mal: vaciar localmente no ayudará. Escala a los propietarios del DNS o evita el resolutor para validar.
4. Si los contenedores están mal pero el host está bien: estás en territorio DNS de contenedores (127.0.0.11, kube-dns, CoreDNS, node-local-dns).

El único “vaciar” que debes hacer por defecto

Ninguno. Vaciar por defecto es trabajo ocupado. Tu comportamiento por defecto debe ser demostrar la ruta, luego vaciar la capa que realmente está cacheando.

Broma #2: Reiniciar NetworkManager para arreglar DNS es como reiniciar la oficina para corregir una errata.

Tres mini-historias corporativas desde las trincheras DNS

Mini-historia 1: El incidente causado por una suposición errónea (“vacié DNS y sigue roto”)

Una empresa SaaS mediana desplegó un nuevo endpoint interno detrás de un balanceador de carga. El cambio fue limpio: actualizar DNS de un antiguo VIP al nuevo, TTL puesto a 30 segundos y una ventana de migración gradual. El on-call ejecutó dig y vio la nueva IP al instante. Energía para celebrar.

Pero los servidores de aplicación seguían llamando al VIP antiguo durante otra hora. Algunas peticiones tuvieron éxito (porque el VIP antiguo todavía servía algo), otras golpearon un pool de backends muertos y devolvieron timeouts. El canal de incidentes se llenó de “DNS está cacheado en algún lado”. Alguien vació systemd-resolved en un subconjunto de servidores. Sin cambio.

La suposición equivocada: que la aplicación usaba el resolvedor del SO en cada petición. No lo hacía. La app era un servicio JVM con una configuración de caché DNS heredada de una imagen base antigua. Cacheaba resultados positivos más tiempo del que nadie recordaba, y el servicio usaba un pool de conexiones persistente que no resolvía de nuevo de todos modos.

La solución no fue “vaciar DNS”. La solución fue: reducir el TTL de caché DNS en la JVM a un valor sensato para ese servicio, añadir un paso en el despliegue para “reciclar” el pool de conexiones durante cambios de endpoint, y mejorar los runbooks para que “dig dice X” no termine la investigación.

También aprendieron una lección dolorosa: el TTL de DNS no obliga a los clientes a comportarse. Es una sugerencia educada. Los sistemas de producción no suelen ser educados.

Mini-historia 2: La optimización que salió mal (caché local en todos lados)

Una gran empresa con una malla de microservicios ruidosa decidió reducir la carga sobre los resolutores centrales. La idea era racional: instalar un resolvedor local en caché en cada VM. Eligieron un forwarder ligero con valores de cacheo agresivos por defecto. La latencia mejoró en pruebas sintéticas. Los gráficos de resolutor se calmaron. Todos volvieron a casa a tiempo durante dos semanas.

Luego tuvieron una respuesta a incidente de seguridad donde necesitaban reconducir un conjunto de nombres de servicio rápidamente lejos de un segmento de red comprometido. Se hicieron cambios DNS centralmente. Algunos nodos se actualizaron rápido, otros no. El plan de “caché en todos lados” se convirtió en “inconsistencia en todos lados”.

Lo que les pegó no fue solo el cacheo positivo. La caché negativa y el comportamiento de “serve-stale” (configurado para ocultar fallas upstream) significaron que algunos hosts seguían devolviendo respuestas antiguas incluso cuando upstream había cambiado. El propósito mismo del DNS—indirección rápida—fue atenuado por la “optimización de rendimiento”.

La solución requirió dos cambios: topes de TTL dictados por política (no extender más allá del TTL autoritativo para nombres críticos) y una palanca operativa clara para invalidar cachés para zonas específicas durante incidentes. Mantuvieron el cacheo local, pero lo trataron como infraestructura de producción con control de cambios y observabilidad, no como un “truco de velocidad”.

La lección: las cachés no son gratis. Son pequeñas bases de datos distribuidas con personalidad.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día (demuéstralo en la red)

Un equipo fintech ejecutaba Ubuntu 24.04 en una mezcla de metal desnudo y VMs. Una mañana, un subconjunto de nodos no pudo alcanzar una API de partner de pagos tras un cambio DNS del partner. El partner juró que DNS se actualizó. El dig del equipo en un host estaba de acuerdo. Otros no. La ansiedad llegó pronto.

El on-call siguió una rutina aburrida pero fiable: primero, resolvectl status para confirmar servidores upstream; segundo, getent hosts para comportamiento NSS; tercero, dig @upstream. Los resultados fueron consistentes: algunos nodos consultaban un resolutor corporativo, otros otro, debido a enrutamiento DNS por enlace tras un evento de failover de VPN.

No “vacían DNS y rezan”. Capturaron un breve tcpdump que mostraba exactamente qué resolutor cada host afectado estaba consultando y las respuestas devueltas. Esa captura de paquetes terminó el debate en diez minutos, porque los paquetes no participan en política.

Una vez clara la causa raíz—rutas de resolutor divididas—arreglaron la configuración de red para asegurar que todos los nodos usaran el mismo par de resolutores para ese dominio de enrutamiento, y añadieron monitorización que comprueba la lista de servidores DNS por enlace de resolved para detectar deriva.

No fue glamoroso. Fue correcto. Y evitó una espiral de culpas de varias horas entre el equipo de apps, el equipo de red y un partner externo.

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

1) Síntoma: dig muestra la nueva IP, la app sigue usando la IP antigua

Causa raíz: Caché DNS a nivel de app o reutilización persistente de conexiones (pooling/keep-alive). A veces la app nunca vuelve a resolver después del arranque.

Solución: Verifica con ss -tnp qué IP está conectada; recicla la app/pool; configura TTL DNS en el runtime; asegura búsquedas por petición cuando corresponda.

2) Síntoma: Vaciar systemd-resolved no cambia nada

Causa raíz: La caché equivocada. O bien el upstream está obsoleto, o el cliente no usa resolved (contenedores, DoH, resolvedor custom).

Solución: Consulta upstream directamente con dig @server; comprueba /etc/resolv.conf en contenedores; captura tráfico DNS con tcpdump.

3) Síntoma: Solo algunas interfaces/nodos resuelven dominios internos

Causa raíz: Enrutamiento DNS por enlace / dominios split-horizon; un VPN o NIC secundaria cambió los dominios de enrutamiento de resolved.

Solución: Usa resolvectl status y resolvectl query para ver qué enlace respondió; corrige la configuración de netplan/NetworkManager para que la interfaz correcta sea propietaria del dominio.

4) Síntoma: El nombre “no existe” justo después de crearlo

Causa raíz: Caché negativa (local o upstream). Tu resolvedor almacenó NXDOMAIN basándose en parámetros SOA.

Solución: Vacía cachés locales; consulta múltiples resolutores upstream; espera el TTL negativo o invalida la caché upstream si la controlas.

5) Síntoma: getent hosts devuelve una IP rara que dig no muestra

Causa raíz: Anulación en /etc/hosts u orden de NSS / interceptación mDNS.

Solución: Inspecciona /etc/hosts y /etc/nsswitch.conf; elimina anulaciónes obsoletas; vuelve a ejecutar getent hosts.

6) Síntoma: IPv4 funciona a veces, IPv6 falla y “parece DNS”

Causa raíz: Existe un registro AAAA; el cliente prefiere IPv6; el camino IPv6 está roto.

Solución: Comprueba dig AAAA name; valida conectividad IPv6; arregla enrutamiento/firewall o ajusta la política del cliente.

7) Síntoma: Los contenedores no resuelven, el host sí

Causa raíz: Capa DNS del runtime de contenedores (127.0.0.11) o configuración DNS de Kubernetes; la caché node-local puede diferir.

Solución: Inspecciona /etc/resolv.conf dentro del contenedor; prueba resolución desde dentro; ajusta la configuración del daemon/kube DNS en lugar de las cachés del host.

8) Síntoma: Las consultas DNS fallan por tiempo de espera de forma esporádica

Causa raíz: Firewall, problemas de MTU, o alcance del resolutor; a veces el fallback a TCP está bloqueado; a veces DoT está bloqueado.

Solución: Usa tcpdump para ver reintentos; prueba TCP/53 y TCP/853; confirma enrutamiento y reglas de seguridad.

Listas de verificación / plan paso a paso

Lista de verificación para incidentes: “DNS está mal en Ubuntu 24.04”

1. Confirma qué estás probando: ¿Estás probando la app, NSS o DNS directo?
2. Comprueba el modo de resolvedor: ls -l /etc/resolv.conf y systemctl status systemd-resolved.
3. Inspecciona DNS por enlace: resolvectl status.
4. Compara respuestas: getent hosts name vs dig name vs dig @upstream name.
5. Comprueba anulaciónes: grep name /etc/hosts y grep '^hosts:' /etc/nsswitch.conf.
6. Vacía solo cuando esté justificado: sudo resolvectl flush-caches.
7. Valida en la red: tcpdump para puerto 53/853 mientras emites consultas.
8. Si persiste la discrepancia de la app: confirma conexiones (ss -tnp), reinicia/recicla la app/pool e inspecciona el comportamiento de caché del runtime.
9. Si el upstream está obsoleto: escala a los propietarios del DNS o evita el resolutor para validar; no sigas vaciando clientes.

Lista de prevención: evita futuros “DNS miente”

1. Estandariza la propiedad del resolvedor: decide si resolved es el stub en todos lados, o si ejecutas un resolvedor local dedicado. No hagas ambos accidentalmente.
2. Establece expectativas de TTL sensatas: documenta qué TTLs usa tu organización para nombres críticos y cómo las cachés pueden limitarlos.
3. Operativiza los cambios DNS: para migraciones de endpoints, incluye pasos de reinicio/reciclado de pool de aplicaciones cuando los clientes puedan cachear.
4. Monitorea desviaciones de resolutor: alerta si los servidores DNS por enlace difieren de lo esperado (especialmente después de eventos VPN).
5. Separa “resolución de nombres” de “conectividad” en los runbooks: siempre comprueba la IP y la ruta realmente conectadas, no solo las respuestas DNS.
6. Forma a los equipos en NSS: haz de getent la herramienta por defecto “¿qué verán las apps?”.

Preguntas frecuentes

1) En Ubuntu 24.04, ¿cuál es el comando correcto para vaciar DNS?

Si usas systemd-resolved (común en 24.04), usa sudo resolvectl flush-caches. Pero solo después de demostrar que resolved es la capa de caché en tu ruta.

2) ¿Por qué dig muestra una IP y mi aplicación usa otra?

dig es un cliente DNS directo; tu app probablemente usa NSS y la pila de resolvedores del sistema, o cachea en proceso, o reutiliza conexiones existentes. Compara con getent hosts y revisa conexiones activas con ss -tnp.

3) ¿Reiniciar systemd-resolved es mejor que vaciar cachés?

Reiniciar es más drástico y puede interrumpir la resolución brevemente. Prefiere resolvectl flush-caches primero. Reinicia solo si resolved está trabado (raro) o cambiaste su configuración.

4) ¿Por qué no debo editar /etc/resolv.conf directamente?

Porque en Ubuntu 24.04 suele ser un symlink gestionado por systemd/netplan/NetworkManager. Tus cambios pueden desaparecer en reboot o al cambiar enlaces, y estarás depurando un archivo de ayer.

5) ¿Cuál es el mejor comando “verdadero” para saber qué resolverá el sistema?

getent hosts name. Sigue las reglas NSS, incluido /etc/hosts, mDNS y DNS vía la pila de resolutores configurada.

6) ¿Puede systemd-resolved enrutar DNS de forma diferente para distintas interfaces?

Sí. Puede seleccionar servidores DNS y dominios de búsqueda por enlace. Esto es una causa común de “algunos nodos funcionan, otros no”, especialmente con VPNs.

7) ¿Cómo sé si el problema de caché es upstream y no local?

Consulta el servidor upstream directamente: dig @DNS_SERVER name. Si el upstream está mal, vaciar cachés locales no cambiará la respuesta.

8) ¿Por qué un registro DNS recién creado aún devuelve NXDOMAIN?

Caché negativa. Las respuestas NXDOMAIN pueden almacenarse según parámetros SOA. Vacía cachés locales y luego comprueba upstream; si upstream sigue devolviendo NXDOMAIN, espera o invalida la caché upstream si la controlas.

9) Mi host resuelve bien pero los contenedores no. ¿Por qué?

Los contenedores suelen usar una dirección de resolvedor distinta (como el 127.0.0.11 de Docker) y reglas de forwarding diferentes. Diagnostica desde dentro del contenedor y arregla la capa DNS del contenedor—no el stub del host.

10) ¿Cómo puedo demostrar qué IP de resolutor está usando mi host sin adivinar?

resolvectl status muestra el servidor DNS actual y los servidores DNS por enlace. Combínalo con tcpdump para confirmar que el tráfico va a donde crees.

Conclusión: siguientes pasos que realmente mueven la aguja

Si tomas un hábito operativo de este caso: deja de decir “vacía DNS” como si fuera una única palanca. En Ubuntu 24.04 es una pila. Tu trabajo es identificar qué capa está mintiendo—o más a menudo, qué capa está repitiendo fielmente una verdad obsoleta que aprendió antes.

Haz esto la próxima vez, en este orden:

1. Usa getent hosts para ver lo que verán las aplicaciones.
2. Usa resolvectl status y resolvectl query para ver qué enlace y qué resolutor upstream están involucrados.
3. Usa dig @upstream para separar cacheo local de obsolescencia upstream.
4. Usa tcpdump cuando empiecen las discusiones. Los paquetes zanjan discusiones.
5. Vacía solo la caché que demostraste que está en la ruta.

Y cuando alguien sugiera reiniciar servicios de red al azar porque “DNS está raro”, entrégales una captura de paquetes y una copia de tu runbook. Con suavidad. Tendrás que seguir trabajando con ellos mañana.