Búsquedas DNS lentas en Linux: solucione systemd-resolved correctamente

Guía rápida de diagnóstico

Si las búsquedas DNS se sienten lentas, no empiece editando archivos de configuración. Empiece por demostrar dónde se gasta el tiempo. Busca: reintentos, expansión de dominios de búsqueda, retrasos por fallback IPv6/IPv4, bloqueos por validación DNSSEC o un stub local que no es realmente local.

1) Confirme que es DNS, no TCP

Elija un nombre de host que sepa que es lento en su app (no un dominio de juguete). Mida la resolución por separado de la conexión.

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

real    0m2.183s
user    0m0.010s
sys     0m0.006s

Qué significa: getent usa la misma ruta NSS que sus aplicaciones. Si esto tarda segundos, ha encontrado el subsistema adecuado.

Decisión: Si getent es lento pero un dig @server directo es rápido, su cuello de botella es la lógica del resolvedor local (dominios de búsqueda, orden NSS, comportamiento del stub), no el DNS ascendente.

2) Identifique la ruta de resolución activa

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

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.example

Qué significa: Esto le indica si systemd-resolved está en juego y qué servidores DNS y dominios cree que existen.

Decisión: Si resolv.conf mode es stub, las apps probablemente consultan 127.0.0.53. Si es foreign o static, algo más está gestionando /etc/resolv.conf y debe depurar ese propietario.

3) Busque reintentos y timeouts

cr0x@server:~$ resolvectl query api.internal.example
api.internal.example: 192.0.2.41                     -- link: ens192

-- Information acquired via protocol DNS in 2.127s.
-- Data is authenticated: no

Qué significa: El tiempo “acquired in” es el dolor visible para el usuario.

Decisión: Si es >200ms de forma consistente en una LAN, probablemente está viendo timeouts/reintentos o un dominio de búsqueda roto. Pase a la captura de paquetes o a los registros de resolved.

4) Diferencie “DNS ascendente lento” de “comportamiento lento del resolvedor”

cr0x@server:~$ dig +tries=1 +time=1 @10.0.0.53 api.internal.example A

; <<>> DiG 9.18.24-1ubuntu1.2-Ubuntu <<>> +tries=1 +time=1 @10.0.0.53 api.internal.example A
;; global options: +cmd
;; ANSWER SECTION:
api.internal.example.  60 IN A 192.0.2.41

;; Query time: 7 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Wed Dec 31 12:12:12 UTC 2025
;; MSG SIZE  rcvd: 68

Qué significa: El DNS ascendente es rápido. Su ruta de resolución local no lo es.

Decisión: Enfóquese en la configuración de systemd-resolved, NSS y el stub. No pierda una semana gritándole al equipo de DNS.

La cadena de resolución: dónde se esconden los segundos

La resolución de nombres en Linux no es “una consulta DNS”. Es una cadena de decisiones, y cada decisión puede añadir demora.

El camino que la mayoría de la gente realmente ejecuta

1. Una aplicación llama a getaddrinfo() (a menudo pidiendo A y AAAA). Algunas apps hacen esto en el camino crítico. Otras lo hacen en cada petición porque el cacheo “es difícil”.
2. glibc consulta NSS vía /etc/nsswitch.conf y recorre las fuentes configuradas (files, resolve, dns, mdns, wins…). El orden importa. El manejo de fallos importa más.
3. Si systemd-resolved está habilitado y NSS está configurado con resolve, glibc habla con resolved por D-Bus o el módulo nss-resolve. De lo contrario, glibc usa /etc/resolv.conf y envía paquetes DNS directamente.
4. Si /etc/resolv.conf apunta a 127.0.0.53, su “nameserver” es un stub local escuchando en localhost. Ese stub reenvía hacia arriba, aplica ruteo split DNS, cachea, puede validar DNSSEC y trata de ser útil.
5. Los servidores ascendentes pueden ser resolvers cacheadores locales, DNS corporativo, un resolver proporcionado por la VPN o algo que su laptop recibió por DHCP en un hotel y que debería ser ilegal.

El síntoma “DNS está lento” puede provenir de cualquier capa. Y sí, dig puede ser rápido mientras su app es lenta, porque dig evita partes de esta cadena. Si diagnostica solo con dig, está depurando el sistema equivocado.

Una cita para mantener en la cabeza mientras persigue esto: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. No es específica de DNS, pero aplica dolorosamente.

Chiste #1: DNS es el único lugar donde “siempre es la red” y “nunca es la red” de algún modo son ambas verdad.

Hechos e historia que explican las rarezas actuales

• El comportamiento original del resolvedor precede a su nube. La lógica por defecto de “dominios de búsqueda” viene de una era donde resolver printer como printer.office era normal, y el coste de consultas adicionales se ignoraba.
• NSS es un sistema de complementos, no solo DNS. Las búsquedas de nombres pueden involucrar archivos locales, LDAP, mDNS, WINS y el resolvedor de systemd. Un mal orden puede añadir segundos por llamada.
• systemd-resolved popularizó un stub local. Esa dirección 127.0.0.53 no es un “servidor DNS real”; es una capa de conveniencia para soportar split DNS, cacheo y políticas.
• El cache negativo es una característica de rendimiento. Sin él, errores tipográficos y dominios muertos se convierten en timeouts repetidos. Con él, las malas configuraciones pueden parecer “pegajosas” hasta que expira la caché.
• Las búsquedas AAAA se volvieron estándar y eso cambió la latencia. Los clientes dual-stack suelen solicitar AAAA y A; rutas IPv6 rotas pueden añadir retrasos incluso cuando IPv4 funciona bien.
• EDNS(0) mejoró DNS, luego las MTU lo arruinaron. Respuestas UDP de mayor tamaño ayudan con registros modernos, pero cuando el descubrimiento de MTU de ruta está roto, obtiene reintentos y retrocesos que parecen “lentitud aleatoria”.
• DNSSEC es computacionalmente barato hasta que no lo es. La validación normalmente añade poco overhead, pero desincronización horaria y cadenas ascendentes rotas pueden causar consultas adicionales y retrasos.
• Las VPN hicieron al split DNS normal. En ambientes corporativos ahora se enrutan sufijos internos a resolvers internos y el resto a resolvers públicos. Eso es un motor de políticas, no “solo DNS”.

Cómo se manifiesta “DNS lento” (y por qué dig puede engañar)

Estos son los patrones clásicos:

• La primera consulta es lenta, luego es rápida. Alguna capa de cacheo funciona, pero el primer fallo es costoso (timeouts o expansión de la lista de búsqueda).
• Sólo algunos nombres son lentos. Normalmente ruteo split DNS (enlace equivocado), fuga de zona interna o un servidor DNS que puede resolver públicos pero no privados (o viceversa).
• Sólo algunos programas son lentos. Las apps que usan libc/NSS son lentas; herramientas como dig son rápidas. Eso apunta al orden NSS, comportamiento del stub resolved o fallback IPv6/IPv4.
• Todo lento después de conectar la VPN. La VPN empujó dominios de búsqueda y ahora cada nombre de una sola etiqueta genera una pequeña tormenta de consultas.
• Picos intermitentes de varios segundos. Reenvíos por pérdida de UDP, problemas de MTU o un servidor DNS que ocasionalmente no está disponible.
• NXDOMAIN es lento. Las respuestas negativas están tomando la ruta larga (dominios de búsqueda) o agotando el tiempo por desajuste de servidores DNS.

Chiste #2: Si quiere experimentar viajes en el tiempo, ejecute apt update en un portátil con una lista de dominios de búsqueda mala.

Tareas prácticas: comandos, salidas, decisiones

Estos no son “comandos aleatorios”. Cada uno responde una pregunta específica, y cada pregunta debería cambiar lo que hace a continuación.

Task 1: Demostrar que la ruta lenta usa libc/NSS

cr0x@server:~$ time getent hosts github.com
140.82.121.3    github.com

real    0m1.612s
user    0m0.003s
sys     0m0.004s

Significado: getent hosts usa NSS. Si esto es lento, sus aplicaciones serán lentas.

Decisión: Continúe con comprobaciones de NSS y resolved. Si getent es rápido pero su app es lenta, su app está haciendo otra cosa (proxy, TLS, OCSP o bucles de reintento).

Task 2: Compare la velocidad de consulta DNS directa

cr0x@server:~$ time dig +tries=1 +time=1 github.com A | sed -n '1,20p'
; <<>> DiG 9.18.24-1ubuntu1.2-Ubuntu <<>> +tries=1 +time=1 github.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48219
;; ANSWER SECTION:
github.com.              60 IN A 140.82.121.3

Significado: Si dig es rápido mientras getent es lento, el DNS ascendente está bien.

Decisión: Enfóquese en la cadena de resolución (dominios de búsqueda, stub, DNSSEC, IPv6).

Task 3: Identifique quién posee /etc/resolv.conf

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 31 10:02 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Significado: Si está enlazado a la resolv.conf de systemd, el stub localhost está en uso.

Decisión: No edite /etc/resolv.conf a mano. Perderá. Configure al gestor (resolved, NetworkManager, netplan o su cliente DHCP).

Task 4: Inspeccione el contenido del stub y los dominios de búsqueda

cr0x@server:~$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example dev.corp.example

Significado: Listas de search grandes o erróneas causan consultas extra. Algunos resolvers también prueban comportamiento tipo ndots; libc usa options también.

Decisión: Si la lista de búsqueda es larga, recórtela en la fuente (config DHCP/VPN) o establezca dominios por enlace apropiadamente.

Task 5: Compruebe el orden NSS (asesino silencioso de rendimiento)

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

Significado: Este orden prueba archivos locales, luego mDNS, luego systemd-resolved, luego DNS. mDNS puede añadir retraso para nombres no .local si está mal configurado. Las reglas en corchetes importan.

Decisión: En servidores, prefiera comportamiento determinista. Si no usa mDNS, elimínelo. Si usa resolved, mantenga resolve antes de dns para evitar que el split-DNS se eluda.

Task 6: Observe la visión del mundo de resolved

cr0x@server:~$ resolvectl dns
Global: 10.0.0.53 10.0.0.54
Link 2 (ens192): 10.0.0.53 10.0.0.54

Significado: Confirma qué servidores DNS usará resolved. El DNS por enlace importa con VPNs y múltiples interfaces.

Decisión: Si el enlace equivocado tiene el DNS “DefaultRoute”, corrija la configuración por enlace (NetworkManager, netplan o resolved).

Task 7: Mida con resolvectl (evita NSS pero golpea resolved)

cr0x@server:~$ resolvectl query -t A -c 1 api.internal.example
api.internal.example: 192.0.2.41                     -- link: ens192

-- Information acquired via protocol DNS in 2.044s.

Significado: Lento aquí significa que la ruta de reenvío de resolved es lenta (elección de servidor, reintentos, DNSSEC, problemas de paquetes), no solo expansión de búsqueda NSS.

Decisión: Revise registros y captura de paquetes a continuación.

Task 8: Active registros debug de resolved (temporalmente)

cr0x@server:~$ sudo resolvectl log-level debug
cr0x@server:~$ sudo journalctl -u systemd-resolved -n 50 --no-pager
Dec 31 12:20:11 server systemd-resolved[612]: Sending query for api.internal.example IN A on interface 2/ens192.
Dec 31 12:20:12 server systemd-resolved[612]: Timeout reached on transaction 45123.
Dec 31 12:20:13 server systemd-resolved[612]: Retrying transaction 45123.

Significado: Puede ver literalmente timeouts y reintentos.

Decisión: Si ve timeouts, sospeche pérdida UDP, firewall, servidor equivocado o problemas MTU/EDNS. Si ve intentos repetidos de dominios de búsqueda, sospeche la lista de búsqueda y nombres de etiqueta única.

Task 9: Captura de paquetes: demuestre retransmisiones o problemas de fragmentación

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53)' -vv -c 20
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:22:01.123456 ens192 Out IP 10.0.0.10.51234 > 10.0.0.53.53: 45123+ A? api.internal.example. (40)
12:22:02.124987 ens192 Out IP 10.0.0.10.51234 > 10.0.0.53.53: 45123+ A? api.internal.example. (40)
12:22:03.127001 ens192 In  IP 10.0.0.53.53 > 10.0.0.10.51234: 45123* 1/0/0 A 192.0.2.41 (56)

Significado: Misma consulta enviada dos veces antes de que llegue una respuesta: ese es comportamiento de retransmisión, no “la CPU está lenta”.

Decisión: Si las retransmisiones son comunes, busque pérdida de paquetes, DNS sobrecargado, límites de tasa en firewall o problemas MTU. Si las respuestas llegan sólo por TCP, investigue EDNS y fragmentación.

Task 10: Compruebe si resolved está retrocediendo a TCP

cr0x@server:~$ resolvectl statistics
Transactions: 2145
Cache: size 1024, hits 1432, misses 713
DNSSEC Verdicts: secure 0, insecure 0, bogus 0, indeterminate 0

Significado: Las estadísticas pueden insinuar si el cacheo ayuda. No dirán directamente el retroceso a TCP, pero combinado con tcpdump cuentan una historia.

Decisión: Si los misses de cache son altos para nombres repetidos, sus TTLs pueden ser mínimos o sus apps generan nombres únicos (descubrimiento de servicios fuera de control).

Task 11: Identifique retrasos inducidos por IPv6 (problemas AAAA)

cr0x@server:~$ getent ahosts example.com | head
2606:2800:220:1:248:1893:25c8:1946 STREAM example.com
2606:2800:220:1:248:1893:25c8:1946 DGRAM
2606:2800:220:1:248:1893:25c8:1946 RAW

Significado: Si existe AAAA, su app puede intentar IPv6 primero. Si el ruteo IPv6 está roto, verá retrasos de conexión que parecen demoras por DNS.

Decisión: Si la resolución de nombres es rápida pero las conexiones se estancan, arregle el ruteo/RA/firewall de IPv6 en lugar de tocar DNS. Si la resolución es lenta en sí, continúe depurando resolved.

Task 12: Trace una única búsqueda lenta con strace

cr0x@server:~$ strace -f -tt -o /tmp/ga.trace getent hosts api.internal.example
192.0.2.41      api.internal.example
cr0x@server:~$ tail -n 12 /tmp/ga.trace
12:24:41.100112 connect(3, {sa_family=AF_UNIX, sun_path="/run/systemd/resolve/io.systemd.Resolve"}, 110) = 0
12:24:41.100321 sendto(3, "{...}", 224, 0, NULL, 0) = 224
12:24:43.142901 recvfrom(3, "{...}", 4096, 0, NULL, NULL) = 312
12:24:43.143210 close(3) = 0

Significado: Puede ver la brecha de 2 segundos entre envío y recepción. Esa es latencia del resolvedor, no CPU de la aplicación.

Decisión: Si las demoras ocurren antes de contactar con resolved (p. ej., iterando archivos, mdns), corrija el orden NSS. Si las demoras ocurren esperando a resolved, arregle resolved/ascendentes.

Task 13: Compruebe la configuración de systemd-resolved (lo que realmente configuró)

cr0x@server:~$ systemd-analyze cat-config systemd/resolved.conf
# /etc/systemd/resolved.conf
[Resolve]
DNS=10.0.0.53 10.0.0.54
Domains=corp.example
DNSSEC=no
DNSOverTLS=no
Cache=yes

Significado: Esta es la configuración efectiva, incluidos los drop-ins. Vale más que adivinar qué archivo se usa.

Decisión: Si DNSSEC está en “allow-downgrade” o “yes” y usted está en un entorno empresarial desordenado, considere establecerlo explícitamente (pero hágalo con intención, no con pánico).

Task 14: Asegúrese de que /etc/resolv.conf no esté peleando con su gestor de red

cr0x@server:~$ resolvectl status | grep -E 'resolv\.conf mode'
  resolv.conf mode: stub

Significado: “stub” significa que la vía de integración prevista está activa.

Decisión: Si ve resolv.conf mode: foreign, encuentre quién lo sobrescribió (a menudo un cliente VPN o el paquete legacy resolvconf) y detenga el tira y afloja.

Arregle systemd-resolved correctamente (patrones de ajuste)

“Desactivar systemd-resolved” es el equivalente en DNS a quitar el detector de humo porque hace ruido. A veces necesita reemplazarlo, pero la mayoría de las veces necesita configurarlo para que deje de hacer cosas costosas por usted.

Patrón A: Arregle los dominios de búsqueda (el multiplicador silencioso de consultas)

Si su /etc/resolv.conf tiene múltiples dominios de búsqueda, una búsqueda de db se convierte en:

• db.corp.example
• db.dev.corp.example
• db (dependiendo de las opciones)

Multiplique por A y AAAA, multiplique por reintentos, multiplique por cada microservicio. Se hace la idea.

Qué hacer: En servidores, prefiera FQDN en las configuraciones y mantenga la lista de búsqueda corta. Si DHCP empuja basura, arregle DHCP. Si una VPN empuja basura, arregle el perfil de VPN. Si ninguno es posible, imponga dominios sensatos en resolved por enlace vía su gestor de red.

Patrón B: Use DNS por enlace y dominios de ruteo para split DNS

El enfoque correcto para corporativo + internet suele ser split DNS: sufijos internos a resolvers internos, todo lo demás a un resolver general. systemd-resolved está diseñado para eso. El modo de fallo común es que el DNS de “DefaultRoute” termina en la interfaz equivocada (VPN vs Wi‑Fi), o la VPN sólo quiere corp.example pero por accidente se convierte en el resolver para todo.

Qué hacer: Haga que los dominios internos sean sólo de ruteo cuando corresponda. En la semántica de systemd-resolved, prefijar un dominio con ~ lo convierte en dominio de ruteo. Eso significa “envíe consultas para este sufijo a estos servidores DNS”, no “añada este sufijo a nombres no calificados”. Reduce expansiones de búsqueda inútiles mientras sigue ruteando correctamente.

Patrón C: Decida sobre DNSSEC explícitamente (no deje que los valores por defecto lo sorprendan)

DNSSEC es genial cuando la cadena está íntegra y la hora está sincronizada. En empresas se encontrará con middleboxes que reescriben DNS, portales cautivos que secuestran y zonas internas que nunca fueron firmadas. Eso no significa “apague DNSSEC en todas partes”. Significa decidir dónde quiere validación y dónde no.

Qué hacer: En servidores dentro de una red controlada, establezca la política DNSSEC explícitamente en /etc/systemd/resolved.conf y verifique que su upstream la soporte. En portátiles que deambulan por el mundo, “allow-downgrade” puede evitar tickets de soporte, pero es un compromiso de seguridad. Haga el trade-off conscientemente.

Patrón D: No luche por la propiedad de /etc/resolv.conf

Las distribuciones modernas esperan que algo gestione /etc/resolv.conf. Si lo edita manualmente, será sobrescrito. Si instala un segundo gestor, obtiene heisenbugs.

Qué hacer: Escoja una autoridad: NetworkManager, systemd-networkd/netplan o una configuración estática deliberada. Asegúrese de que su cliente VPN se integre con esa autoridad en lugar de garabatear sobre /etc/resolv.conf directamente.

Patrón E: Arregle timeouts arreglando la red, no ocultándolos

Existen perillas para el comportamiento de reintentos y timeouts, pero si las necesita en una LAN, algo más está mal: pérdida de paquetes, reglas de firewall, un resolvedor sobrecargado, agujeros MTU. Puede “optimizar” alrededor y aun así perder la guerra a las 2 a.m.

Si sus registros muestran timeouts, capture paquetes, identifique qué servidor es lento y elimínelo de la rotación o arréglelo. Si uno de los DNS configurados está muerto, su “DNS rápido” es en realidad “rápido la mitad del tiempo”.

Tres micro-historias corporativas desde el campo

Incidente 1: La suposición equivocada (dig es rápido, así que DNS está bien)

Una compañía mediana tuvo una ola de “caídas intermitentes” en APIs internas. Desde el lado de la aplicación parecía que los stalls eran de connect TCP. Ingenieros ejecutaron dig contra el nombre interno y obtuvieron respuestas en pocos milisegundos. Caso cerrado, pensaron. El equipo de API empezó a investigar pools de hilos y balanceadores de carga en su lugar.

Entonces alguien ejecutó getent ahosts y vio demoras de 1–3 segundos, mayormente para nombres que no existían. Esa fue la primera pista: el servicio no estaba lento, el resolvedor era lento cuando se le pedían typos, nombres de servicio obsoletos o endpoints de feature flags deshabilitados.

La causa raíz fue una larga lista de dominios de búsqueda empujada por un perfil VPN. Cada nombre de etiqueta única generaba múltiples consultas a través de límites de split DNS. Peor aún, algunos sufijos se ruteaban a resolvers que no podían responderlos y simplemente hacían timeout en lugar de responder NXDOMAIN. Cada timeout era de uno o dos segundos. Multiplique por reintentos y por A+AAAA, y obtiene la “caída intermitente”.

La solución no fue desactivar systemd-resolved. La solución fue convertir los “Domains” de la VPN en dominios de ruteo para los sufijos internos, acortar la lista de búsqueda y dejar de usar nombres de etiqueta única en configuraciones de producción. La caída se evaporó. El postmortem incluyó una nueva regla: para servicios Linux, medir con getent, no solo con dig.

Incidente 2: La optimización que salió mal (forzar un servidor DNS “más rápido”)

En otra empresa, alguien decidió que los resolvers corporativos eran “lentos”, basado en unas pocas pruebas desde cafeterías en laptops. La optimización propuesta: fijar resolvers públicos en /etc/systemd/resolved.conf en todas las estaciones de desarrollo. Lo pusieron como tweak estándar de la imagen.

El rendimiento mejoró para dominios públicos. Luego las herramientas internas empezaron a fallar. Algunas zonas internas sólo resolvían en DNS corporativo. Los desarrolladores empezaron a añadir hacks: entradas en hosts, scripts DNS ad-hoc de VPN y la costumbre de copiar IPs en configuraciones “para seguir trabajando”. Predeciblemente, esas IPs cambiaron y los hacks se convirtieron en outages.

La parte más divertida: los resolvers públicos estaban bloqueados en un subconjunto de redes corporativas, así que la “optimización” causó timeouts y largos retrocesos justo donde menos los quiere—durante la respuesta a incidentes en un segmento restringido.

La solución fue un rollback y un mejor diseño de split DNS: sufijos corporativos ruteados a resolvers corporativos, todo lo demás usando los resolvers locales de la red con cacheo. Los desarrolladores ganaron velocidad sin romper nombres internos. Seguridad consiguió política. Operaciones menos tickets. Nadie volvió a fingir que “un servidor DNS sirve para todo” es una estrategia.

Incidente 3: La práctica aburrida y correcta que salvó el día (hacer observable el comportamiento del resolvedor)

Una gran empresa no tenía DNS perfecto. Tenían múltiples resolvers, VPNs y una mezcla de distros. Lo que sí tenían era una práctica aburrida y disciplinada: cada imagen de flota incluía un script ligero de “salud del resolvedor” y un bundle de depuración estándar que capturaba resolvectl status, /etc/nsswitch.conf, /etc/resolv.conf y una traza corta de paquetes cuando se activaba.

Una tarde, una nueva política de firewall empezó a limitar la tasa de fragmentos UDP. Nadie lo anunció como “relacionado con DNS”. El primer síntoma fue lentitud aleatoria en logins, luego problemas al instalar paquetes y microservicios que empezaron a agotar tiempo.

Porque existía el bundle del resolvedor, el on-call no tuvo que adivinar. Compararon trazas de paquetes de hosts saludables y no saludables. Los hosts no saludables mostraban respuestas truncadas, retroceso a TCP y reintentos repetidos. La correlación con un segmento de red específico fue inmediata. Entregaron al equipo de firewall evidencia, no sensaciones.

La solución fue quirúrgica: permitir respuestas DNS fragmentadas o aplicar tamaños EDNS más pequeños en la capa correcta. El incidente terminó sin el habitual carrusel de culpas que dura una semana. La práctica aburrida ganó. Otra vez.

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

1) “dig es rápido pero curl es lento”

Síntoma: dig responde rápido; las aplicaciones cuelgan antes de conectar.

Causa raíz: Las apps usan libc/NSS; dig evita el orden NSS y puede consultar un servidor distinto. Además, las apps a menudo piden A+AAAA más expansión de búsqueda; la prueba con dig probablemente hizo una sola consulta.

Solución: Pruebe con getent ahosts y resolvectl query. Audite /etc/nsswitch.conf y dominios de búsqueda; asegure que el ruteo de resolved sea correcto.

2) “Todo se puso lento después de la VPN”

Síntoma: Las búsquedas de nombres son rápidas antes de la VPN, lentas después.

Causa raíz: La VPN empujó largas listas de búsqueda y/o robó la ruta DNS por defecto, enviando todas las consultas a un resolver sólo accesible por un túnel congestionado.

Solución: Configure split DNS con dominios de ruteo para sufijos internos; mantenga el DNS por defecto en el enlace local salvo que la política requiera lo contrario.

3) “NXDOMAIN tarda 5 segundos”

Síntoma: Errores tipográficos o registros faltantes son dolorosamente lentos.

Causa raíz: Expansión de lista de búsqueda + servidores ascendentes que hacen timeout en lugar de responder; a veces un servidor DNS secundario muerto provocando reintentos.

Solución: Reduzca dominios de búsqueda, elimine servidores DNS muertos y asegure que los resolvers ascendentes respondan correctamente para nombres inexistentes.

4) “Sólo dominios internos son lentos”

Síntoma: Dominios públicos resuelven rápido; zonas internas fallan.

Causa raíz: Split DNS mal ruteado: sufijo interno enviado al resolver equivocado, o múltiples interfaces compitiendo (Wi‑Fi + VPN + puente Docker).

Solución: Use DNS por enlace y dominios de ruteo; verifique con resolvectl status qué enlace posee el dominio.

5) “Picos aleatorios: a veces 20ms, a veces 2s”

Síntoma: Mayormente bien, a veces stalls.

Causa raíz: Pérdida UDP, límites de tasa en firewall, problemas MTU/EDNS o uno de los servidores DNS configurados fallando intermitentemente.

Solución: Captura de paquetes para ver retransmisiones; elimine o arregle resolvers inestables; solucione MTU o manejo de UDP fragmentado.

6) “systemd-resolved sigue cambiando mi resolv.conf”

Síntoma: Las ediciones manuales desaparecen.

Causa raíz: Ese archivo no es suyo. Lo gestiona resolved u otro componente de red.

Solución: Configure al propietario (resolved conf, ajustes de conexión de NetworkManager, netplan/systemd-networkd). Deje de editar /etc/resolv.conf directamente.

Listas de verificación / plan paso a paso

Paso a paso: de “lento” a “arreglado” sin conjeturas

1. Mida con la herramienta correcta: ejecute time getent ahosts name. Registre la demora real.
2. Compruebe la propiedad: ls -l /etc/resolv.conf. Si es un symlink al stub, resolved está en la cadena.
3. Inspeccione dominios de búsqueda: cat /etc/resolv.conf y resolvectl status. Si la búsqueda es larga, es sospechosa.
4. Inspeccione el orden NSS: compruebe la línea hosts:. Elimine fuentes que no use (especialmente en servidores).
5. Compare capas: dig @upstream vs resolvectl query vs getent. Identifique dónde entra la demora.
6. Active debug brevemente: ponga el nivel de logs de resolved en debug y lea timeouts/reintentos.
7. Capture paquetes: confirme retransmisiones, truncación, retroceso a TCP o comportamiento de “sin respuesta”.
8. Arregle la causa: servidor DNS equivocado, secundario muerto, MTU roto, split DNS mal ruteado, incompatibilidad DNSSEC o lista de búsqueda inflada.
9. Revierte ajustes de debug: vuelva el nivel de logs a normal y mantenga el registro de cambios limpio.
10. Vuelva a probar y documente: ejecute las mismas mediciones y capture tiempos antes/después.

Checklist operativo: evitar que vuelva a suceder

• Estandarice cómo se gestiona DNS en cada distro (NetworkManager vs networkd) y no mezcle gestores en el mismo host.
• Defina dominios de búsqueda permitidos por entorno; mantenga conservadores los servidores de producción.
• Monitoree latencia y tasas de error del resolvedor desde hosts, no solo desde los servidores de DNS.
• Tenga un conjunto “sanity” conocido para on-call: getent, resolvectl, journalctl, tcpdump.

Preguntas frecuentes

1) ¿Debo desactivar systemd-resolved para arreglar DNS lento?

Normalmente no. Desactivarlo suele romper split DNS, ruteo VPN y comportamiento consistente entre apps. Arregle el cuello de botella real (dominios de búsqueda, DNS por enlace equivocado, timeouts) y mantenga el motor de políticas.

2) ¿Por qué aparece 127.0.0.53 en /etc/resolv.conf?

Ese es el stub local de systemd-resolved. Las apps consultan localhost; resolved reenvía a los servidores DNS reales y aplica ruteo/cacheo. Si es lento, o está reenviando lentamente o está haciendo demasiado trabajo por consulta.

3) ¿Por qué dig es rápido pero getent es lento?

dig es un cliente DNS; getent sigue NSS y usa la misma ruta que la mayoría de aplicaciones. Un getent lento suele significar que el orden NSS, los dominios de búsqueda o la integración con resolved están causando consultas extra o timeouts.

4) ¿Cómo sé si la demora es expansión de dominio de búsqueda?

Revise los logs debug de resolved y las capturas de paquetes. Verá consultas repetidas por el mismo nombre base con diferentes sufijos. También compare una búsqueda de etiqueta única (db) frente a un FQDN (db.corp.example).

5) ¿DNSSEC hace que las búsquedas sean lentas?

Puedes, pero no es el villano por defecto. La mayor parte del overhead de DNSSEC es pequeña. La lentitud aparece cuando la validación dispara consultas extra, la hora está mal o el DNS ascendente rompe la cadena. Decida la política explícitamente en lugar de esperar que los valores por defecto se comporten.

6) ¿Puede IPv6 causar “lentitud DNS” incluso si DNS está bien?

Sí. Muchas apps resuelven AAAA y luego intentan IPv6 primero. Si la conectividad IPv6 está rota, la demora de conexión puede confundirse con demora de DNS. Separe temporización de resolución (getent) de temporización de conexión (curl -v o nc).

7) ¿Cuál es la forma más segura de cambiar ajustes de resolvedores en servidores?

Cámbielos a través del gestor de red del sistema y confírmelos como código (configs netplan, perfiles NetworkManager o unidades systemd-networkd). Evite ediciones puntuales en /etc/resolv.conf.

8) Tengo múltiples servidores DNS configurados. ¿Por qué sería más lento?

Si un servidor está muerto o descarta respuestas, su resolvedor puede esperar, reintentar y luego cambiar. Eso puede añadir segundos. Varios servidores son buenos cuando están sanos; horribles cuando uno falla silenciosamente.

9) ¿Por qué las respuestas NXDOMAIN a veces tardan más que las exitosas?

Porque el resolvedor puede intentar dominios de búsqueda y varios tipos de registros, y algunos servidores ascendentes hacen timeout en lugar de responder limpiamente para ciertos sufijos. Las respuestas negativas deberían ser rápidas; si no lo son, algo está mal ruteado o roto.

Próximos pasos que puede hacer hoy

Haga tres cosas, en este orden:

1. Mida con getent ahosts y resolvectl query para depurar la misma ruta que usan sus aplicaciones.
2. Haga la cadena de resolución aburrida: orden hosts: sensato, listas de búsqueda cortas, ruteo DNS por enlace correcto y sin guerra por /etc/resolv.conf.
3. Cuando vea segundos, capture evidencia: logs debug de resolved y un tcpdump corto. Luego arregle la causa real—resolvedores muertos, rutas equivocadas, roturas MTU/EDNS—en vez de parchear por encima.

Una vez que el DNS sea rápido y predecible, el resto del sistema deja de sentirse encantado. Ese es todo el sentido de la ingeniería de confiabilidad: menos misterios, más sueño.