Conceptos básicos del envenenamiento de caché DNS: Endurezca su resolver sin sobreingeniería

Qué es realmente el envenenamiento de caché (y qué no lo es)

“Envenenamiento de caché DNS” es cuando un resolver recursivo almacena una respuesta falsa y la sirve a los clientes hasta que expire (o sea desalojada).
La palabra clave es caché. El atacante no necesita comprometer su servidor autoritativo para hacerle daño; solo necesita
que su resolver crea una mentira el tiempo suficiente.

Esto es diferente de:

• Secuestro en el registrador (alguien cambia los registros NS en el registrador del dominio). Eso no es envenenamiento de caché; es compromiso de cuenta.
• Manipulación en ruta (MITM reescribiendo respuestas DNS). Eso es un ataque de red; el cacheo puede amplificarlo, pero la causa raíz es la intercepción del tráfico.
• Mala configuración (registros A/AAAA erróneos, TTLs obsoletos, sorpresas por split-horizon). Desde la perspectiva del cliente se ve idéntico.
• Tormentas NXDOMAIN (muchas respuestas negativas). No es envenenamiento; aún así es doloroso.

El envenenamiento importa porque DNS es un sistema de distribución de confianza que precede a los modelos de amenaza modernos. Fue diseñado para fiabilidad y
escala, no para adversarios activos. Hemos añadido defensas. Funcionan, pero solo si las activa y no las sabotea con optimizaciones “útiles”.

El radio de afectación lo determinan dos decisiones que usted controla:

• ¿Quién puede consultar su resolver? Si ejecuta un resolver abierto, convierte los problemas de extraños en sus problemas.
• ¿Con qué rigor valida el resolver las respuestas? La validación DNSSEC y reglas de bailiwick sensatas convierten muchos intentos de envenenamiento en ruido inofensivo.

Chiste corto #1: DNS es como el chisme de oficina: una vez que lo equivocado llega a la caché, todos lo repiten con absoluta confianza.

Cómo funciona el envenenamiento: de las conjeturas a la persistencia

Un resolver recursivo pregunta a servidores ascendentes y almacena en caché las respuestas. Los atacantes quieren insertar una respuesta falsa en esa caché.
Históricamente, el envenenamiento consistía en competir con la respuesta real con una respuesta forjada y ganar la confianza del resolver.

Las piezas que hacen posible el envenenamiento

Una respuesta DNS forjada debe coincidir con lo que el resolver espera: el ID de transacción, el puerto de origen y la sección de pregunta.
Los resolvers antiguos usaban IDs previsibles y puertos fijos. Eso reducía el espacio de adivinanza a algo que un atacante podía forzar por fuerza bruta.
Los resolvers modernos aleatorizan IDs y puertos de origen, haciendo la adivinanza fuera de ruta mucho más difícil.

Pero “más difícil” no es “imposible.” Los atacantes buscan:

• Dispositivos NAT que colapsan puertos de origen (la randomización de puertos queda anulada por middleboxes).
• Canales laterales que filtran información de puerto o ID.
• Configuraciones de reenvío débiles (forwarders que aceptan basura, o que no validan DNSSEC).
• Resolvers mal configurados que aceptan registros adicionales fuera de bailiwick (vector clásico de envenenamiento).
• TTLs largos que hacen que una única victoria dure mucho tiempo.

Por qué importa la sección “additional” (y por qué bailiwick es una palabra adulta)

Las respuestas DNS pueden contener registros extra en la sección “additional”, como registros glue A para servidores de nombres.
Un resolver debería ser exigente respecto a lo que almacena en caché desde allí. La regla práctica es “bailiwick”: cachear datos adicionales solo si están dentro
de la autoridad del servidor que los proporcionó, y aun así con precaución.

El envenenamiento a menudo intenta introducir algo como:

• Un registro A para www.victim.com en una respuesta que no debería ser autorizada para él.
• Un registro NS apuntando victim.com a un nameserver controlado por el atacante, más glue para ese nameserver.

Una vez que un resolver almacena en caché una delegación maliciosa (NS envenenado), el atacante obtiene palanca: las consultas futuras pueden redirigirse a sus servidores,
que pueden responder de forma consistente y “legítima” desde el punto de vista del resolver. Ahí es cuando el incidente se vuelve persistente.

DNSSEC cambia el juego—si realmente valida

DNSSEC añade firmas a los datos DNS para que un resolver que valida pueda detectar manipulaciones. No cifra DNS. No impide que alguien sepa qué consulta.
Tampoco protege zonas no firmadas, y puede verse socavado por mal manejo de la trust-anchor o por validación desactivada “temporalmente”.

Activar la validación DNSSEC es como ponerse el cinturón de seguridad. No le vuelve invencible, pero la alternativa es confiar en que la física sea indulgente.

Una cita, porque la operación es un deporte de contacto: “La esperanza no es una estrategia.” — Vince Lombardi.

Hechos interesantes y contexto histórico (corto y concreto)

• DNS es anterior a la web: DNS se estandarizó en los años 80; HTTP llegó después. El modelo de amenazas era “red de campus”, no “adversario global”.
• 2008 fue un punto de inflexión: La divulgación de Dan Kaminsky mostró envenenamiento de caché práctico a escala, forzando parches y randomización masiva.
• La randomización de puerto de origen se volvió por defecto después de esa era porque los IDs de 16 bits eran adivinables con suficientes intentos.
• “0x20 encoding” existe: Algunos resolvers aleatorizan mayúsculas/minúsculas en las consultas para añadir entropía; es ingenioso pero no un sustituto de la validación real.
• NAT puede sabotear la seguridad: Algunos NAT antiguos reescribían puertos de origen de forma predecible, reduciendo la entropía que creía tener.
• El firmado DNSSEC se concibió en los 90 conceptualmente, pero su despliegue real tardó debido a la complejidad operativa y el miedo a la gestión de claves.
• La zona raíz se firmó en 2010, lo que hizo viable la validación DNSSEC de extremo a extremo sin trucos de confianza personalizados.
• El cache negativo está estandarizado (SOA minimum / comportamiento de TTL negativo). Es esencial para la escala y también una fuente común de “¿por qué no resuelve aún?”.
• Los resolvers son amplificadores de DDoS cuando están abiertos: no es envenenamiento, pero está relacionado: la recursión abierta convierte su infraestructura en el arma de otro.

Guía rápida de diagnóstico

Está de guardia. Algo huele a DNS. No intente arreglarlo todo a la vez. Haga esto en orden y pare cuando encuentre el cráter humeante.

Primero: determine si el resolver miente o si el upstream está cambiando

1. Consulte su resolver y un resolver externo conocido para el mismo nombre y compare respuesta + TTL.
2. Compruebe el estado de validación DNSSEC (¿está activada y falla?).
3. Trace la delegación (¿lo están enviando a servidores NS inesperados?).

Segundo: busque persistencia y alcance en la caché

1. Compruebe el comportamiento del TTL: ¿la respuesta incorrecta cuenta hacia abajo (cacheada) o fluctúa (upstream)?
2. Compruebe varios clientes/subredes: ¿es un nodo de resolver, un sitio o en todas partes?
3. Compruebe si hay un forwarder implicado: muchas implementaciones de “resolver” son solo forwarders con pasos extra.

Tercero: confirme que no es autoinfligido

1. Busque en los diffs de gestión de configuración cambios de DNS (forwarders, views, ACLs, alternancia de DNSSEC).
2. Compruebe colisiones de split-horizon (zona interna que enmascara la externa).
3. Inspeccione el comportamiento del NAT/firewall si sospecha riesgo de envenenamiento fuera de ruta (reescritura de puertos, timeouts UDP).

El objetivo: separar “caché envenenada” de “la verdad autoritativa cambió” de “nos rompimos a nosotros mismos.” Esas son tres clases de incidente distintas.

Tareas prácticas: comandos, salidas y la decisión que toma

Estas son deliberadamente prácticas. Ejecútelas en un host cliente y en el host del resolver. Compare salidas. Tome decisiones.
Usaré 10.0.0.53 como IP del resolver recursivo interno y resolver1 como su hostname.

Tarea 1 — Confirme qué resolver está usando realmente su host

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

Qué significa: Este host está enviando DNS a 10.0.0.53 (primario) y 10.0.0.54 (secundario).
DNSSEC aquí es sobre el resolver stub y puede indicar “unsupported” incluso si la recursión valida aguas arriba.

Decisión: Si el “Current DNS Server” no es el resolver previsto, detenga y corrija la configuración de DHCP/systemd-resolved.
Depurar envenenamiento en la caja equivocada es como culpar a la luna.

Tarea 2 — Compare la respuesta de su resolver con una referencia externa conocida

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  296  IN  A  203.0.113.50

cr0x@server:~$ dig @1.1.1.1 www.example.com A +noall +answer +ttlid
www.example.com.  300  IN  A  93.184.216.34

Qué significa: Su resolver devuelve una IP diferente a la de un resolver público. Eso puede ser envenenamiento, split-horizon o divergencia aguas arriba.

Decisión: Si el dominio debería ser público y consistente, trátelo como incidente y continúe. Si es intencionalmente interno, documentelo y siga adelante.

Tarea 3 — Compruebe si la respuesta incorrecta está en caché (TTL decrementando)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  296  IN  A  203.0.113.50

cr0x@server:~$ sleep 5; dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  291  IN  A  203.0.113.50

Qué significa: El TTL decreciente indica que el resolver está sirviendo desde caché.

Decisión: Respuesta incorrecta cacheada implica que necesita purgar/flush de caché (con cuidado) y buscar la causa raíz. Si el TTL se restablece hacia arriba, su resolver la está obteniendo repetidamente de algún lugar.

Tarea 4 — Trace la delegación para ver de dónde provienen las respuestas

cr0x@server:~$ dig +trace www.example.com A
; <<>> DiG 9.18.24 <<>> +trace www.example.com A
;; global options: +cmd
.                       3600    IN      NS      a.root-servers.net.
...
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
www.example.com.        300     IN      A       93.184.216.34

Qué significa: +trace evita la caché de su resolver y realiza resolución iterativa desde la raíz hacia abajo.
Si +trace devuelve el registro correcto pero su resolver no, el resolver es sospechoso.

Decisión: Si el trace es correcto pero la respuesta del resolver difiere, inspeccione envenenamiento de caché o una anulación interna. Si el trace también está “mal”, la verdad autorizada cambió o su red está interceptando DNS.

Tarea 5 — Pida el estado de validación DNSSEC en la respuesta

cr0x@server:~$ dig @10.0.0.53 www.example.com A +dnssec +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42012
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.com.  300  IN  A  93.184.216.34

Qué significa: No ve la bandera ad (Authenticated Data). Eso puede significar que la validación DNSSEC está desactivada, no es compatible para este nombre, o su resolver no es un validador.

Decisión: Si espera validación, confírmelo en el resolver. Si no la espera, decida si eso sigue siendo aceptable en 2025 (normalmente no lo es).

Tarea 6 — En Unbound, verifique que DNSSEC esté activado y funcionando

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 2
modules: 2 [subnetcache validator]
uptime: 18432 seconds
options: reuseport control(ssl)

Qué significa: La lista de módulos incluye validator, una buena señal de que la validación DNSSEC está compilada y activa.

Decisión: Si no ve validator, no está validando. Corrija la configuración antes de discutir sobre envenenamiento.

Tarea 7 — En BIND9, confirme la recursión y quién puede usarla

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,120p'
options {
        recursion yes;
        allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };
        allow-query-cache { 10.0.0.0/8; 192.168.0.0/16; };
        dnssec-validation auto;
        minimal-responses yes;
        ...
};

Qué significa: La recursión está activada (bien) pero restringida a redes internas (también bien). dnssec-validation auto; es el valor por defecto seguro normal.

Decisión: Si allow-recursion es any; o está ausente, trátelo como un problema de seguridad. La recursión abierta invita al abuso y aumenta su exposición.

Tarea 8 — Compruebe patrones SERVFAIL (a menudo DNSSEC o problemas upstream)

cr0x@server:~$ dig @10.0.0.53 badsig.example A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61457
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Qué significa: SERVFAIL puede significar fallas de validación, timeouts o fallos upstream. Si se correlaciona con zonas con DNSSEC, suele ser validación.

Decisión: Revise los logs del resolver por errores de DNSSEC; no desactive la validación para “arreglar” producción. Eso es como resolver una alarma de humo quitando las pilas.

Tarea 9 — Verifique que el resolver no esté reenviando a un upstream no confiable o roto

cr0x@server:~$ sudo ss -uapn | grep -E ':(53)\b'
UNCONN 0      0         10.0.0.53:53         0.0.0.0:*    users:(("unbound",pid=1187,fd=6))
UNCONN 0      0         10.0.0.53:49322      8.8.8.8:53   users:(("unbound",pid=1187,fd=9))
UNCONN 0      0         10.0.0.53:42617      1.1.1.1:53   users:(("unbound",pid=1187,fd=10))

Qué significa: Este resolver está realizando consultas UDP/53 salientes a resolvers públicos. Ese es un diseño de reenvío, no de recursión completa.

Decisión: Decida si el reenvío es intencional. Si reenvía, hereda el comportamiento upstream y reduce su capacidad para hacer validación de extremo a extremo y depuración.

Tarea 10 — Inspeccione el comportamiento NAT que puede reducir la entropía de puertos

cr0x@server:~$ sudo conntrack -L -p udp --dport 53 2>/dev/null | head
udp      17 25 src=10.0.0.53 dst=1.1.1.1 sport=42617 dport=53 src=1.1.1.1 dst=203.0.113.10 sport=53 dport=42617 [ASSURED]
udp      17 25 src=10.0.0.53 dst=8.8.8.8 sport=49322 dport=53 src=8.8.8.8 dst=203.0.113.10 sport=53 dport=49322 [ASSURED]

Qué significa: Puede ver los flujos UDP y los puertos de origen. Si observa repetidamente puertos secuenciales o reutilizados debido al NAT, está perdiendo entropía.

Decisión: Si su NAT es predecible, corrija la configuración del NAT o mueva el resolver para que pueda preservar la aleatoriedad.

Tarea 11 — Revise estadísticas de Unbound en busca de anomalías de caché

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'num.cachehits|num.cachemiss|num.query|unwanted|cache'
num.query=1842099
num.cachehits=1320091
num.cachemiss=522008
unwanted.queries=183
unwanted.replies=91
msg.cache.count=76231
rrset.cache.count=54012

Qué significa: Altos cache hits son normales. Aumentos en unwanted.replies pueden indicar respuestas falsificadas que no coinciden con consultas pendientes.

Decisión: Si unwanted.replies se dispara, investigue intentos de suplantación en la red o dispositivos upstream rotos. No es prueba de envenenamiento, pero es una pista valiosa.

Tarea 12 — Capture tráfico DNS para confirmar qué hay en la red

cr0x@server:~$ sudo tcpdump -ni any udp port 53 -vv -c 5
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
IP 10.0.0.53.42617 > 1.1.1.1.53: 42012+ A? www.example.com. (33)
IP 1.1.1.1.53 > 10.0.0.53.42617: 42012* 1/0/1 A 93.184.216.34 (49)
IP 10.0.0.53.49322 > 8.8.8.8.53: 1337+ DS? example.com. (29)
IP 8.8.8.8.53 > 10.0.0.53.49322: 1337 1/0/1 DS 370 13 2 49AAC11D... (68)
IP 203.0.113.66.53 > 10.0.0.53.42617: 42012 1/0/0 A 203.0.113.50 (49)

Qué significa: La IP externa 203.0.113.66 está enviando una respuesta que coincide con el ID de transacción y el puerto de la consulta pendiente.
Si esa IP no es su upstream y llega antes que la legítima, tiene un problema serio: se está produciendo suplantación en ruta o por fallo de enrutamiento/ACL.

Decisión: Escale inmediatamente: equipo de red para ACLs/enrutamiento, equipo de seguridad para respuesta a incidentes, y aísle el resolver si puede.

Tarea 13 — Revise logs de consultas de BIND por clientes inesperados y abuso de recursión

cr0x@server:~$ sudo rndc querylog
query logging is now on

cr0x@server:~$ sudo tail -n 5 /var/log/named/named.log
client @0x7f3c9c0a: query: randomstring.badness.example IN A +E(0)K (198.51.100.77)
client @0x7f3c9c0a: query: www.example.com IN A +E(0)K (10.10.14.22)
client @0x7f3c9c0a: query: api.internal.corp IN A +E(0)K (10.20.1.9)

Qué significa: Una IP pública consultando su resolver sugiere recursión abierta o fuga por firewall. También observe subdominios aleatorios: pueden ser intentos de amplificación o de evadir caché.

Decisión: Si hay IPs públicas usando recursión, bloquéelas inmediatamente y corrija las ACLs. Esto es seguridad y estabilidad.

Tarea 14 — Compruebe si está filtrando zonas internas al exterior (views / split horizon)

cr0x@server:~$ dig @10.0.0.53 api.internal.corp A +noall +answer
api.internal.corp.  60  IN  A  10.55.0.21

cr0x@server:~$ dig @1.1.1.1 api.internal.corp A +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11610

Qué significa: El nombre interno existe solo internamente. Bien. Pero si un resolver externo devuelve algo, tiene una colisión o fuga.

Decisión: Asegúrese de que los sufijos internos sean verdaderamente privados y no colisionen con TLDs públicos. Considere usar una estrategia de dominios internos reservados para evitar sorpresas.

Tarea 15 — Valide que su resolver rechaza basura fuera de bailiwick (prueba de saneamiento)

cr0x@server:~$ dig @10.0.0.53 ns1.example.com A +noall +authority +additional
example.com.     172800  IN  NS  a.iana-servers.net.
example.com.     172800  IN  NS  b.iana-servers.net.
a.iana-servers.net.  172800 IN A  199.43.135.53
b.iana-servers.net.  172800 IN A  199.43.133.53

Qué significa: La sección additional contiene registros glue para los nameservers. Eso es esperado y glue en-bailiwick para la cadena de delegación.

Decisión: Si ve que su resolver cachea registros A adicionales no relacionados (para nombres no involucrados en la delegación), endurezca la configuración y actualice el software del resolver.

Endurecimiento del resolver que realmente importa

Endurecer resolvers es sobre todo pensar en denegar por defecto y reducir ambigüedades. No está intentando ser ingenioso.
Está intentando ser aburrido, correcto y resistente tanto a atacantes como a las “mejoras” de sus compañeros.

1) Deje de ejecutar recursión abierta (en serio)

Restrinja quién puede consultar y quién puede recursar. Son dos ACL distintas. Hágalo bien en ambas.
Si ejecuta un resolver abierto, atraerá abuso, generará patrones de tráfico confusos y aumentará la probabilidad de que basura suplantada llegue a su caché.

• BIND: establezca allow-recursion y allow-query-cache solo a redes internas.
• Unbound: configure access-control para subredes permitidas; niegue todo lo demás.

2) Active la validación DNSSEC y no la trate como opcional

La validación DNSSEC es la mitigación más eficaz contra el envenenamiento para zonas firmadas. Convierte “tal vez” en “no”.
Sí, introduce nuevos modos de fallo (firmas expiradas, DS rotos). Está bien. Sabemos cómo monitorizarlos.

Lo que no debe hacer: desactivar DNSSEC durante una caída y olvidarse de volver a activarlo. Así se pasa de “inestabilidad temporal”
a “compromiso silencioso”.

3) Mantenga su software de resolver actualizado

La seguridad de los resolvers es un objetivo en movimiento: correcciones de bailiwick, mejor randomización, análisis más robusto, mejoras de QNAME minimization,
y mitigaciones para nuevos canales laterales. Las versiones antiguas acumulan bordes afilados. Sangrará.

4) Preserve la entropía de extremo a extremo (puertos, IDs y la red intermedia)

La randomización de puertos solo ayuda si los paquetes conservan sus puertos. Si su resolver está detrás de un NAT que reescribe puertos de forma predecible,
pierde entropía. Mueva el resolver al borde, corrija el comportamiento del NAT o use un diseño que evite esa ruta NAT.

5) Prefiera recursión completa sobre reenvío ciego (cuando pueda)

Reenviar a resolvers públicos es operativo y fácil. También es un cambio de confianza. Está externalizando parte de su postura de seguridad y toda su
claridad de diagnóstico. La recursión completa hace el análisis de causa raíz más limpio y reduce la dependencia de los caprichos de un upstream.

Si debe reenviar (por cumplimiento, política, restricciones de egress), hágalo a resolvers controlados por usted o a upstreams confiables y mantenga la validación DNSSEC
localmente cuando sea posible.

6) Active la QNAME minimization

QNAME minimization reduce la filtración de información y reduce ligeramente el valor de algunos juegos de suplantación al minimizar lo que revela a cada upstream.
No es su defensa principal contra envenenamiento, pero es una mejora barata.

7) Use limitación de tasa donde proteja la estabilidad, no como un hechizo mágico

La limitación de tasa ayuda contra inundaciones y algunos patrones de fuerza bruta. No “resolverá el envenenamiento”.
Pero puede mantener el resolver vivo el tiempo suficiente para que responda y reduce el potencial de amplificación.

8) Registre con intención: lo suficiente para investigar, no para ahogar

Los logs de consultas 24/7 son costosos y ruidosos. Use muestreo o toggles de corto plazo (rndc querylog, aumento de verbosidad en Unbound),
y mantenga métricas estructuradas siempre activas: ratio de aciertos de caché, tasas de SERVFAIL, replies no deseadas, principales QNAMEs por volumen.

9) Fije las zonas internas y evite colisiones

El split-horizon DNS suele ser necesario. También es terreno fértil para comportamientos “tipo envenenamiento”: respuestas diferentes según origen,
views aplicadas erróneamente, zonas internas que enmascaran dominios públicos reales. Use sufijos claros, pruebe externamente y automatice verificaciones.

10) Defina su postura sobre EDNS, cookies y fallback a TCP

EDNS aumenta tamaños y capacidades de mensaje DNS. Es bueno, pero interactúa con MTU, fragmentación y middleboxes.
Las EDNS Cookies pueden añadir resiliencia contra respuestas suplantadas en algunos escenarios añadiendo un token al intercambio (soporte variable).
Asegúrese de que el fallback a TCP funcione: algunos ataques y fallos dependen de romper las suposiciones UDP.

Chiste corto #2: Cada vez que alguien dice “DNS es simple”, un resolver deja caer un paquete UDP fragmentado y trama venganza en silencio.

Tres microhistorias del mundo corporativo

Microhistoria 1: El incidente causado por una suposición incorrecta

Una empresa ejecutaba dos resolvers recursivos por sitio. El documento de diseño decía “anycast”, pero la implementación fue “dos IPs en DHCP”.
Un ingeniero supuso que eso significaba que los clientes conmutarían sin problemas cuando un resolver estuviera no saludable.

Un lunes, un nodo resolver empezó a devolver registros obsoletos para un pequeño conjunto de dominios con mucho tráfico. No estaba totalmente muerto. Simplemente estaba equivocado.
Los TTL eran largos. El helpdesk recibió informes de “la página de inicio de sesión a veces está mal”. Es el tipo de informe que desearía fuera una broma.

La suposición equivocada: el equipo pensó que el resolver secundario enmascararía los problemas del primario. En realidad, la mayoría de pilas de clientes se mantienen con el primer servidor
a menos que se agote el tiempo de espera. Un resolver que responde rápido—incorrectamente—no dispara la conmutación. Se convierte en una fuente autorizada de mentiras para esa población de clientes.

La solución no fue heroica. Dejaron de tratar “dos IPs” como alta disponibilidad. Añadieron chequeos de salud del resolver, retiraron nodos no saludables de los pools DHCP,
y estandarizaron procedimientos de vaciado de caché. Lo más importante: construyeron una pequeña comprobación sintética que comparaba respuestas de cada resolver contra un trace externo.

La conclusión del postmortem fue directa: “respuestas rápidas y equivocadas son peores que timeouts.” Esa frase se convirtió en requisito de diseño, no en lección.

Microhistoria 2: La optimización que salió mal

Otra organización tenía quejas de latencia desde oficinas remotas. Alguien propuso optimizar: reenviar todo el DNS a un par central de resolvers
porque “los cache hits serán mayores”. Técnicamente cierto. Operativamente, una trampa.

Implementaron el reenvío sobre una VPN. El volumen de consultas estaba bien, pero las respuestas EDNS empezaron a fragmentarse, y la ruta VPN tenía una MTU efectiva menor.
Algunos fragmentos se perdían. Ciertos dominios empezaron a fallar intermitentemente con SERVFAIL o colgar largo tiempo por la lógica de reintentos y problemas con fallback a TCP.

El equipo notó el síntoma pero diagnosticó lo incorrecto primero: “los servidores autoritativos son inestables.” Abrieron tickets, esperaron y no llegaron a nada.
Mientras tanto, un atacante en una red compartida (no en ruta hacia el datacenter, pero cerca de algunos clientes de sucursal) tuvo más facilidad para suplantar respuestas
porque la ruta de reenvío y el comportamiento NAT redujeron la entropía efectiva e incrementaron retransmisiones.

No ocurrió nada catastrófico, pero el incidente fue una clase magistral de fragilidad autoinfligida. La “optimización” concentró confianza y fallo.
La solución fue desplegar resolvers locales en sucursales con recursión completa, preservar la randomización de puertos localmente, y mantener el reenvío solo como política de emergencia.

La lección final: el cacheo no es razón para crear un único punto de rareza. Especialmente no para DNS.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una compañía de pagos tenía una política: los resolvers validan DNSSEC, y desactivar la validación requiere un cambio formal con caducidad.
La gente se quejaba en semanas tranquilas. Durante un incidente real, esa política rindió frutos.

Un dominio de un SaaS tercero empezó a resolverse a una IP inesperada para un subconjunto de redes. Los resolvers públicos no estaban de acuerdo entre sí.
Los resolvers validadores de la compañía devolvían SERVFAIL para algunas respuestas y respuestas correctas para otras. Eso parecía una caída de DNS a los equipos de aplicaciones.

Porque tenían métricas, SRE vio un aumento en fallos de validación y “unwanted replies”. Capturas de paquetes mostraron respuestas forjadas llegando
más rápido que las legítimas en una ruta ISP. La validación DNSSEC rechazó los datos forjados. El impacto fue resolución degradada (timeouts y reintentos),
pero no redirección silenciosa al atacante.

Temporalmente enrutaron la salida de los resolvers por otro proveedor, manteniendo la validación activada. El servicio se estabilizó.
Más tarde, el ISP reconoció un problema consistente con interferencias en el tráfico. La compañía nunca tuvo que decir a clientes “podemos haberle enviado al host equivocado.”

La práctica aburrida no fue solo “DNSSEC activado.” Fue “DNSSEC activado, monitorizado y difícil de desactivar.” Lo aburrido funciona. Lo aburrido escala.

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

1) Síntoma: Algunos usuarios llegan a la IP equivocada, otros están bien

Causa raíz: Un nodo de resolver tiene caché envenenada/obsoleta, o los clientes están fijos al primer servidor.

Solución: Compare respuestas por IP de resolver; vacíe la caché en el nodo afectado; retírelo de rotación; añada chequeos sintéticos por nodo.

2) Síntoma: Respuesta incorrecta persiste horas incluso después de “arreglar DNS”

Causa raíz: TTL largo cacheado en resolvers recursivos; cache negativo; forwarder intermedio; o aplicaciones cacheando DNS internamente.

Solución: Mida la cuenta regresiva del TTL en cada capa. Purge caches donde las controle; reduzca TTL antes de migraciones; reiniciar solo como último recurso.

3) Síntoma: Pico súbito de SERVFAIL para dominios populares

Causa raíz: Fallos de validación DNSSEC (cadena DS rota, firmas expiradas) o timeouts/fragmentación upstream.

Solución: Revise logs por errores de validación; confirme EDNS/MTU en la ruta; asegure el fallback a TCP; no desactive validación sin un plan acotado.

4) Síntoma: CPU del resolver está bien, pero los clientes ven timeouts

Causa raíz: Pérdida de paquetes, firewall que descarta fragmentos, o timeouts de estado UDP; ocasionalmente agotamiento de conntrack.

Solución: Haga tcpdump en el resolver; revise conntrack; permita DNS TCP/53; ajuste EDNS buffer o path MTU; corrija ACLs de red.

5) Síntoma: IPs públicas aparecen en logs del resolver como clientes

Causa raíz: Recursión abierta expuesta a Internet o enrutamiento VPN erróneo; a veces un error en grupos de seguridad cloud.

Solución: Bloquee la recursión con ACLs; firewall UDP/TCP 53; confirme SG/NACL cloud; verifique que no está anunciando accidentalmente IPs de resolver.

6) Síntoma: Resolver devuelve A “correcto” pero TLS falla por mismatch de certificado

Causa raíz: La respuesta DNS apunta al host equivocado (envenenamiento o split-horizon), o los CDNs cambian bordes y sus suposiciones de pinning están desactualizadas.

Solución: Compare con +trace y varios resolvers; verifique si está sobreescribiendo la zona internamente; valide registros autoritativos.

7) Síntoma: Problemas solo con respuestas grandes (TXT, DNSKEY, algunos HTTPS/SVCB)

Causa raíz: Fragmentación EDNS perdida; problemas de path MTU; middleboxes rotos; TCP bloqueado.

Solución: Asegure que TCP/53 funcione de extremo a extremo; ajuste el buffer EDNS; prefiera versiones modernas de resolvers con valores por defecto sensatos.

8) Síntoma: Picos de consultas a subdominios aleatorios (p. ej. a1b2c3.example.com)

Causa raíz: Flood para evadir caché, intento de DDoS, o beaconing de malware; también puede ser descubrimiento de servicios con mal comportamiento.

Solución: Use RPZ o política local para bloquear patrones malos conocidos; implemente limitación de tasa; identifique IPs de origen; coordine con seguridad.

Listas de verificación / plan paso a paso

Fase 1 — Establezca la línea base de su postura de seguridad del resolver (1–2 días)

1. Inventario de resolvers: IPs, versiones, si recursan o reenvían, y hacia dónde sale su egress.
2. Confirme ACLs de recursión: solo redes internas pueden recursar; el resto obtiene refusal.
3. Active validación DNSSEC: valide en el resolver, no solo en los clientes.
4. Verifique que TCP/53 esté permitido: tanto inbound hacia resolver desde clientes (si hace falta) como outbound desde el resolver.
5. Confirme que la randomización de puertos sobrevive al NAT: revise conntrack/flujos; corrija mapeos predecibles.
6. Active métricas: ratio de aciertos de caché, SERVFAIL, NXDOMAIN, replies no deseadas, histogramas de latencia.

Fase 2 — Añada salvaguardas que prevengan inseguridad “temporal” (1–2 semanas)

1. Configuración como código: resolvers gestionados por su pipeline normal, no por ediciones artesanales por SSH.
2. Control de cambios para toggles DNSSEC: cualquier desactivación requiere caducidad y un responsable.
3. Cheques sintéticos por nodo resolver: compare contra +trace para un pequeño conjunto de dominios; alerte ante divergencias.
4. Toggle de logging de consultas de corto plazo: runbook operativo para activar logs 15 minutos con retención segura.

Fase 3 — Endurecimiento sin sobreingeniería (continuo)

1. Prefiera recursión completa salvo que la política obligue a reenviar. Si reenvía, sea explícito sobre la confianza y monitorice al upstream.
2. Minimice la complejidad de split-horizon: mantenga zonas internas pequeñas y claras; evite enmascarar dominios públicos.
3. Cadencia de parches: trate las actualizaciones de resolvers como actualizaciones de seguridad, porque lo son.
4. Ejercicio de mesa: simule “respuesta DNS errónea” y “fallo de validación DNSSEC” y practique la respuesta.

Preguntas frecuentes (FAQ)

1) ¿Sigue existiendo el envenenamiento de caché DNS en 2025?

Sí, pero las versiones fáciles están mayormente muertas en resolvers modernos con buena randomización y reglas de bailiwick.
El riesgo restante es mala configuración, confianza en reenvíos, pérdida de entropía por NAT, interferencia en ruta y “validación desactivada.”

2) Si uso DoH/DoT, ¿estoy a salvo del envenenamiento de caché?

DoH/DoT protege el tramo cliente→resolver contra manipulación en ruta. No valida automáticamente DNSSEC, y no le protege si el resolver está comprometido o mal configurado.
Es una mejora de transporte, no un oráculo de la verdad.

3) ¿Cuál es el único mejor paso de endurecimiento?

Active la validación DNSSEC en el resolver recursivo y manténgala activa. Luego restrinja la recursión a clientes internos.
Esos dos cambios eliminan clases enteras de problemas.

4) ¿Por qué mi resolver devuelve SERVFAIL cuando resolvers públicos devuelven una IP?

Lo más frecuente: fallo de validación DNSSEC. Los resolvers públicos pueden estar configurados de forma distinta, ignorando la validación para esa zona,
o pueden tener un estado de caché diferente. Revise sus logs antes de culpar a Internet.

5) ¿Cómo distingo envenenamiento de split-horizon DNS?

El split-horizon suele ser consistente por red de origen y zonas configuradas. El envenenamiento a menudo muestra divergencia entre resolvers,
cambios de delegación inesperados y anomalías como respuestas no deseadas. Use +trace y compare respuestas internas vs externas.

6) ¿Debemos vaciar cachés durante un presunto incidente de envenenamiento?

A veces sí—después de capturar evidencia. Vaciar puede destruir la prueba que necesita (capturas de paquetes, logs, RRsets en caché).
Si vacía primero y pregunta después, su postmortem será un ejercicio de escritura creativa.

7) ¿Los TTL largos siempre son malos?

No. Los TTL largos son excelentes para estabilidad y coste. Son malos cuando los datos están equivocados. Operativamente, debe reducir TTLs antes de migraciones planificadas
y evitar TTLs extremadamente largos en registros que cambian con frecuencia.

8) ¿Ejecutar múltiples resolvers soluciona el envenenamiento?

Reduce la probabilidad de que una caché envenenada afecte a todos, pero solo si los clientes realmente usan múltiples resolvers y monitoriza el comportamiento por nodo.
Dos resolvers con el mismo upstream de reenvío defectuoso son solo redundancia del mismo error.

9) ¿Qué hay de “0x20 encoding” y otros trucos de entropía?

Pueden ayudar en casos concretos, pero no son una defensa primaria. Trátelos como condimento, no como plato principal.
La validación DNSSEC, la randomización adecuada y las ACLs son el plato principal.

10) ¿Cómo evito la sobreingeniería?

No construya una plataforma DNS de seguridad a medida. Ejecute un resolver moderno (Unbound o BIND), valide DNSSEC, bloquee la recursión,
monitorice métricas clave y practique respuesta a incidentes. La mayoría de equipos fallan por no cubrir lo básico, no por falta de funciones exóticas.

Conclusión: pasos prácticos siguientes

El envenenamiento de caché DNS es menos sobre hacks de Hollywood y más sobre higiene operativa: quién puede consultarle, en quién confía y si su resolver
puede distinguir la verdad de la basura. A los atacantes les gusta la ambigüedad. A las caídas también. Su trabajo es eliminar ambas.

1. Esta semana: verifique ACLs de recursión, confirme que la validación DNSSEC está activada y ejecute las comprobaciones “comparar contra externo” en sus dominios principales.
2. La próxima semana: añada monitorización sintética por resolver para divergencia de respuestas y fallos de validación; haga que “desactivar DNSSEC” sea un cambio controlado con caducidad.
3. Este trimestre: modernice versiones de resolvers, audite NAT/egress por pérdida de entropía y simplifique zonas split-horizon.

Si hace solo una cosa: deje de aceptar respuestas rápidas y equivocadas como “saludables”. DNS es infraestructura. Trátelo como algo que importa, porque todo lo demás depende de ello.