DNS: Problemas de MTU pueden romper DNS — Cómo probarlo y solucionarlo

Lo que realmente ocurre: por qué la MTU rompe DNS

DNS es pequeño hasta que deja de serlo. Las consultas A para zonas modestas suelen caber cómodamente en un único paquete UDP. Pero en el momento en que las respuestas crecen—firmas DNSSEC, múltiples registros, cadenas largas en TXT (hola, SPF/DMARC), registros SVCB/HTTPS, o simplemente un resolvedor que se pone parlanchín—puedes acabar con una respuesta que excede la MTU de camino entre cliente y servidor.

Cuando eso sucede, una de dos cosas debe ser cierta para que DNS sobre UDP funcione:

• La respuesta debe fragmentarse y todos los fragmentos deben llegar, en orden, al cliente.
• O el cliente y el servidor deben negociar una carga útil menor (típicamente vía EDNS(0)) para que la fragmentación nunca ocurra.

En redes reales, la fragmentación es frágil. Los firewalls descartan fragmentos. Los dispositivos NAT “ayudan” expirándolos. Algunos balanceadores de carga hashéan solo con el primer fragmento (que no contiene los puertos UDP de los fragmentos posteriores), y entonces tus fragmentos toman caminos distintos como en un proyecto grupal.

Así que la consulta DNS sale, el resolvedor envía una respuesta UDP demasiado grande, esa respuesta se fragmenta, un fragmento desaparece y el cliente se queda esperando. Eventualmente reintenta, quizá por TCP, quizá a otro resolvedor, quizá no. Desde fuera ves: “inestabilidad de DNS”. Desde dentro ves: “un problema de red de capa 2–3 disfrazado de capa 7”.

El Descubrimiento de MTU de Camino (PMTUD) debería prevenir este lío haciendo que los routers envíen ICMP “Fragmentation Needed” (IPv4) o “Packet Too Big” (IPv6) para que los endpoints aprendan el tamaño máximo. Pero PMTUD exige que ICMP pase. Muchos entornos tratan a ICMP como un invitado no deseado y luego se sorprenden cuando las tuberías gotean.

Una realidad operativa: DNS suele ser el primer protocolo que muestra dolor por MTU porque es ubicuo, usa UDP por defecto y está implicado en casi cualquier otra cascada de fallos. Cuando DNS falla, todo parece roto. Tu trabajo es demostrar que es MTU y luego arreglar el camino para no pasar la próxima semana culpando al resolvedor.

Broma #1: Si bloqueas ICMP porque es “inseguro”, has reinventado el equivalente en redes de quitar la luz del aceite porque molestaba.

El mecanismo clave: EDNS(0) y “¿cuánto es demasiado?”

El DNS clásico limitaba respuestas UDP a 512 bytes. EDNS(0) (RFC 2671, luego RFC 6891) extendió DNS para que los clientes pudieran anunciar un búfer UDP mayor (a menudo 1232 bytes es un valor moderno seguro). Eso es bueno: reduce el retroceso a TCP y mejora el rendimiento. También es malo: aumenta la probabilidad de que excedas la MTU de algún camino roto y sufras descartes silenciosos.

Así que el patrón “MTU rompe DNS” frecuentemente se ve así:

1. El cliente envía una consulta DNS con EDNS(0) anunciando 4096 bytes.
2. El resolvedor devuelve una respuesta UDP de 1600–3000 bytes.
3. Algún salto no puede transportarla (por ejemplo, túnel VPN, enlace PPPoE, red overlay, MTU mal configurada en una vNIC).
4. Ocurre fragmentación o debería ocurrir PMTUD, pero los fragmentos/ICMP se bloquean.
5. El cliente agota el tiempo, reintenta o cae a TCP—si se le permite.

Por qué suele afectar “solo a algunos dominios”

Los problemas de MTU no rompen tanto el DNS como rompen las respuestas DNS grandes. Por eso puedes resolver example.com todo el día mientras que some-dnssec-heavy-domain.tld falla. Cualquier dominio con DNSSEC, registros TXT largos, muchos registros en un RRset o cadenas CNAME es candidato.

La parte más aterradora es que puedes “arreglar” esto por accidente cambiando de resolvedor, con caching, o esperando. Ninguno de esos arregla el camino. Solo mueven el síntoma hasta que te muerda un nombre más importante a las 2 a.m.

Hechos e historia que importan en producción

• Hecho 1: El límite original de respuesta UDP de DNS fue 512 bytes; EDNS(0) elevó ese límite permitiendo que los clientes anuncien un búfer UDP mayor.
• Hecho 2: La adopción de DNSSEC hizo que las respuestas grandes sean comunes, porque las firmas y el material de clave añaden volumen—especialmente para respuestas negativas (pruebas NSEC/NSEC3).
• Hecho 3: Un tamaño EDNS UDP “seguro” ampliamente usado hoy es alrededor de 1232 bytes para evitar problemas de fragmentación IPv6 en rutas típicas.
• Hecho 4: PPPoE reduce la MTU de Ethernet de 1500 a 1492, y los túneles encima pueden dejarla aún más baja. Puedes perder otros ~60–80 bytes con facilidad.
• Hecho 5: Los routers IPv4 pueden fragmentar paquetes, pero los routers IPv6 no fragmentan en tránsito; la fragmentación la realizan los endpoints, lo que hace a PMTUD y la entrega de ICMPv6 mucho más importantes.
• Hecho 6: Muchos middleboxes tratan los fragmentos IP como sospechosos y los descartan, a veces intencionalmente, a veces como efecto secundario de “endurecimiento de seguridad”.
• Hecho 7: Algunos dispositivos NAT y firewalls rastrean mal los flujos UDP para fragmentos, porque los fragmentos posteriores no incluyen información de puertos UDP.
• Hecho 8: La caída a TCP de DNS forma parte del diseño del protocolo, pero en redes empresariales TCP/53 a menudo está bloqueado “porque DNS es UDP”. Así conviertes un problema leve de MTU en un incidente.
• Hecho 9: Las redes overlay en la nube y la encapsulación (VXLAN, Geneve, IPsec, GRE) reducen rutinariamente la MTU efectiva. Cuando apilas túneles, apilas overhead, no felicidad.

Una cita para recordar en la cultura de operaciones, porque aplica brutalmente bien a los misterios de MTU:

“La realidad debe prevalecer sobre las relaciones públicas; la naturaleza no se deja engañar.” — Richard Feynman (paráfrasis)

Guion de diagnóstico rápido (haz esto primero)

Si DNS está inestable y sospechas MTU, no empieces reinstalando systemd-resolved ni discutiendo cuál resolvedor público es mejor. Haz esto:

1) Confirma que es “DNS de respuesta grande”

• Elige un dominio que falla y otro que funciona.
• Prueba con EDNS activado y desactivado.
• Prueba UDP vs TCP explícitamente.

2) Mide la MTU de camino en la dirección que falla

• Desde el cliente hacia la IP del resolvedor (no “Internet”).
• Usa pings con el bit DF (IPv4) o pings IPv6 con tamaño.
• Espera encontrar un número menor que 1500 en VPNs, PPPoE, overlays y algunos caminos en la nube.

3) Busca agujeros de ICMP y descartes de fragmentos

• Captura de paquetes en el cliente o cerca del resolvedor.
• Revisa reglas de firewall para ICMP “Fragmentation Needed” / “Packet Too Big”.
• Comprueba si TCP/53 funciona; si lo hace, estás frente a un problema de fragmentación UDP.

4) Aplica la mitigación de menor riesgo primero

• Reduce el tamaño EDNS UDP en clientes/resolvedores (p. ej., 1232).
• Permite TCP/53 donde sea apropiado.
• Corrige MTU de túneles/interfaces y aplica MSS clamping correctamente (no adivines; mide).

Demostrarlo con comandos: 12+ tareas reales y decisiones

Las siguientes tareas están escritas como si estuvieras de guardia: ejecutas un comando, interpretas la salida y tomas una decisión. Ejecútalas desde un cliente que experimente fallos y, si es posible, desde un host cercano al resolvedor también.

Task 1: Reproduce la falla con dig y captura tiempos

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +tries=1 +time=2
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Qué significa: Tienes un problema de alcanzabilidad cliente→resolvedor en la capa DNS. Aún no es suficiente para concluir MTU.

Decisión: Compáralo con un dominio “pequeño” y luego fuerza TCP para ver si el problema es UDP.

Task 2: Compara con una respuesta pequeña conocida

cr0x@server:~$ dig @10.20.30.40 example.com A +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 example.com A +tries=1 +time=2
;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34
;; Query time: 18 msec

Qué significa: El DNS básico hacia el resolvedor funciona. Así que probablemente depende del contenido: tamaño de respuesta, fragmentación, DNSSEC o filtrado de paquetes.

Decisión: Fuerza TCP para el nombre que falla. Si TCP tiene éxito, sospecha fragmentación/PMTUD en UDP.

Task 3: Forzar DNS por TCP (evita problemas de fragmentación UDP)

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +tcp +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +tcp +tries=1 +time=2
;; ANSWER SECTION:
large-dnssec-domain.example. 300 IN A 203.0.113.77
;; Query time: 42 msec

Qué significa: TCP/53 funciona y devuelve una respuesta. El camino UDP es el probable culpable, no los datos del resolvedor.

Decisión: Confirma que la respuesta es grande y activa comportamiento EDNS/fragmentación.

Task 4: Inspecciona EDNS y la negociación de tamaño UDP

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=4096

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=4096
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; connection timed out; no servers could be reached

Qué significa: Anunciar un búfer UDP grande dispara la falla. Eso es consistente con problemas de MTU/fragmentación.

Decisión: Intenta un búfer más pequeño (1232) y mira si se vuelve fiable.

Task 5: Reduce el búfer EDNS para evitar fragmentación

cr0x@server:~$ dig @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=1232 +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @10.20.30.40 large-dnssec-domain.example A +dnssec +bufsize=1232 +tries=1 +time=2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; ANSWER SECTION:
large-dnssec-domain.example. 300 IN A 203.0.113.77
;; Query time: 29 msec

Qué significa: Un UDP más pequeño tiene éxito. Probablemente tu camino no puede transportar de forma fiable respuestas UDP más grandes.

Decisión: Ahora necesitas probar la limitación de MTU/camino, no solo la “rareza” de EDNS. Mide PMTU a continuación.

Task 6: Mide MTU de camino IPv4 con pings con DF

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1472

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Qué significa: La MTU de tu interfaz (o un salto temprano) está por debajo de lo esperado, o estás en un enlace con MTU reducida. El error local indica que la pila local no puede enviar ese tamaño en esa interfaz.

Decisión: Encuentra la MTU real de la interfaz y luego busca en binario el camino con tamaños menores. También verifica si el resolvedor se alcanza por una interfaz de túnel.

Task 7: Encuentra la MTU de interfaz y la interfaz de salida usada

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 10.8.0.1 dev tun0 src 10.8.0.10 uid 1000
    cache

cr0x@server:~$ ip link show dev tun0
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
    link/none

Qué significa: El DNS hacia el resolvedor va por tun0 con MTU 1400. Eso ya es menor que Ethernet 1500; suma cabeceras y fácilmente puedes colapsar UDP grande.

Decisión: Prueba PMTU al resolvedor con tamaños por debajo de 1400 y confirma dónde falla.

Task 8: Confirma la mayor carga útil sin fragmentar al resolvedor (búsqueda binaria)

cr0x@server:~$ ping -M do -s 1372 -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1372(1400) bytes of data.
1380 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=31.2 ms
1380 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=30.7 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

cr0x@server:~$ ping -M do -s 1392 -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1392(1420) bytes of data.
From 10.8.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.8.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1400)

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss

Qué significa: Tu PMTU es 1400 en ese camino, y el ICMP “Frag needed” en realidad te está llegando (bien). Si ICMP estuviera bloqueado, podrías ver solo timeouts.

Decisión: Dado que PMTU es 1400, pregunta: ¿por qué falló EDNS de 4096? Porque una ruta con MTU 1400 fragmentará respuestas UDP más grandes. Si los fragmentos se descartan, obtienes timeouts. Siguiente paso: confirmar pérdida de fragmentos con tcpdump.

Task 9: Captura paquetes DNS y busca comportamiento de fragmentación

cr0x@server:~$ sudo tcpdump -ni tun0 -vvv 'host 10.20.30.40 and (udp port 53 or tcp port 53)' -c 20
tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
IP 10.8.0.10.50821 > 10.20.30.40.53: 12345+ [1au] A? large-dnssec-domain.example. (56)
IP 10.20.30.40.53 > 10.8.0.10.50821: 12345* 1/0/1 A 203.0.113.77 (1492)
IP 10.8.0.10.42233 > 10.20.30.40.53: 54321+ [1au] A? large-dnssec-domain.example. (56)
IP 10.8.0.10.42233 > 10.20.30.40.53: Flags [S], seq 101, win 64240, options [mss 1360,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
IP 10.20.30.40.53 > 10.8.0.10.42233: Flags [S.], seq 202, ack 102, win 65160, options [mss 1360,sackOK,TS val 2 ecr 1,nop,wscale 7], length 0

Qué significa: Puedes ver una respuesta UDP grande (1492 bytes en la red) que excede la MTU 1400 en el túnel; dependiendo del punto de captura puede que veas o no la fragmentación explícita. La presencia de SYN TCP después sugiere que el cliente está reintentando y cayendo a TCP.

Decisión: Si no ves la respuesta UDP completa llegar (o la ves salir del servidor pero no llegar al cliente), tienes pérdida de fragmentos. Mitiga reduciendo el tamaño EDNS y/o arreglando la MTU del túnel y permitiendo ICMP.

Task 10: Confirma si TCP/53 está permitido de extremo a extremo

cr0x@server:~$ nc -vz 10.20.30.40 53
Connection to 10.20.30.40 53 port [tcp/domain] succeeded!

Qué significa: TCP/53 está abierto en ese camino. Eso es una red de seguridad; muchas redes no lo tienen.

Decisión: Si TCP funciona, puedes mitigar rápidamente asegurando que clientes/resolvedores usen correctamente el fallback a TCP y reduciendo tamaños UDP. Si TCP está bloqueado, arregla eso inmediatamente—luego continúa con la causa raíz de MTU.

Task 11: Revisa ajustes del resolvedor sobre tamaño EDNS (ejemplo BIND)

cr0x@server:~$ sudo named-checkconf -p | grep -E 'edns-udp-size|max-udp-size' || true
        max-udp-size 4096;

Qué significa: El resolvedor está dispuesto a enviar respuestas UDP muy grandes. Eso es optimista en redes empresariales con túneles y firewalls.

Decisión: Reduce a un número más seguro (a menudo 1232) salvo que controles cada salto y puedas demostrar que tamaños mayores funcionan de forma fiable.

Task 12: Aplica un tamaño UDP seguro en el resolvedor (BIND) y valida la configuración

cr0x@server:~$ sudo sed -i 's/max-udp-size 4096;/max-udp-size 1232;/' /etc/bind/named.conf.options
cr0x@server:~$ sudo named-checkconf
cr0x@server:~$ sudo systemctl reload bind9
cr0x@server:~$ sudo systemctl status bind9 --no-pager -l
● bind9.service - BIND Domain Name Server
     Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
     Active: active (running)

Qué significa: El resolvedor ahora está limitado a respuestas UDP más pequeñas, reduciendo el riesgo de fragmentación.

Decisión: Vuelve a probar los dominios que fallaban con dig sin forzar +bufsize. Si el problema desaparece, has probado la sensibilidad a MTU/fragmentos. Aún así, arregla la red, pero has comprado estabilidad.

Task 13: Revisa si ICMP “frag needed” está siendo bloqueado por el firewall del host (Linux)

cr0x@server:~$ sudo iptables -S | grep -E 'icmp|fragmentation|RELATED' || true
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT

Qué significa: ICMP está permitido en el host. Si antes viste solo timeouts, el descarte puede estar en un firewall de red, no en el host.

Decisión: Si ICMP está bloqueado en algún punto del camino, corrige la política para permitir los tipos ICMP esenciales (no “todo ICMP para siempre”, pero sí lo suficiente para PMTUD).

Task 14: Revisa MSS clamping en un gateway VPN (mitigación común para TCP, no UDP)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i clamp || true
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Qué significa: MSS clamping está en su lugar, lo que ayuda a TCP a evitar problemas de MTU. No hace nada para la fragmentación UDP de DNS.

Decisión: No te pares aquí. La gente ve “clamp-mss-to-pmtu” y declara victoria, luego se pregunta por qué DNS sobre UDP sigue fallando. Necesitas dimensionado EDNS y/o corrección de MTU.

Task 15: Chequeo rápido en Kubernetes: ¿CoreDNS ve truncamiento o reintentos?

cr0x@server:~$ kubectl -n kube-system logs deploy/coredns --tail=50 | grep -E 'timeout|truncated|SERVFAIL' || true
[ERROR] plugin/errors: 2 large-dnssec-domain.example. A: read udp 10.244.2.15:46122->10.20.30.40:53: i/o timeout

Qué significa: CoreDNS está agotando tiempo en lecturas UDP hacia el resolvedor upstream. Si TCP tiene éxito desde el mismo pod/red, sospecha MTU/fragmentación entre el clúster y el resolvedor (a menudo una desalineación de MTU en overlays).

Decisión: Verifica MTU de red de pods y nodos, y ajusta CoreDNS (o el upstream) a un tamaño EDNS seguro. Luego arregla la MTU del overlay/túnel correctamente.

Tres micro-historias corporativas (cómo suele ir)

1) El incidente causado por una suposición errónea

Implementaron una nueva VPN site-to-site entre dos oficinas. Venía con las promesas habituales: “conectividad transparente”, “sin cambios en aplicaciones”, “es solo routing”. El equipo de red configuró la MTU del túnel con un valor por defecto que usaban desde hace años y siguió adelante. Nadie midió nada, porque ¿por qué medir algo que es “estándar”?

El lunes por la mañana el volumen de tickets se disparó. Los usuarios podían acceder a apps internas por IP, pero los nombres eran inestables. Algunas páginas web cargaban, otras giraban eternamente, y el portal de login fallaba de una forma que parecía problema de autenticación. Los gráficos del resolvedor se veían limpios. CPU bien. QPS normal. El de guardia empezó persiguiendo “rendimiento del servidor DNS”.

Tomó a una persona ejecutar dig +tcp. De repente los dominios fallidos se resolvieron al instante y el “fallo de autenticación” se parecía mucho a “tamaño de respuesta DNSSEC”. Las capturas mostraron respuestas UDP saliendo del resolvedor y nunca llegando intactas al cliente. El camino del túnel tenía una MTU efectiva menor de la asumida, y el firewall en el medio descartaba fragmentos.

La suposición errónea no era sobre las cuentas de MTU; era sobre la titularidad. Todos asumieron “la VPN lo maneja” y “DNS es diminuto”. La solución fue embarazosa de simple: corregir la MTU del túnel, permitir los ICMP necesarios y limitar EDNS UDP en el resolvedor como medida adicional. El postmortem incluyó una acción clara: cualquier nuevo túnel debe incluir una prueba PMTU medida en la lista de verificación de despliegue.

2) La optimización que se volvió en contra

Otra organización tenía una iniciativa de rendimiento: reducir latencia evitando TCP para DNS. Alguien notó que las consultas TCP eran una fracción no trivial del tráfico del resolvedor en horas pico. Así que “optimizaron” subiendo los tamaños EDNS en la flota y ajustando firewalls para “preferir UDP”. El cambio se veía bien en un benchmark estrecho: menos handshakes TCP, algo menos de tiempo medio de consulta.

Dos semanas después, un subconjunto de empleados remotos empezó a reportar que “algunos sitios no existen” y “la VPN es inestable”. Fue intermitente y enloquecedor. El equipo de resolvedor vio más retransmisiones y timeouts pero no podía reproducir desde el centro de datos. El equipo de VPN culpó a la Wi‑Fi. El de escritorios culpó al OS. Todos tenían una historia plausible; ninguno estaba en lo cierto.

La causa raíz fue la optimización: respuestas UDP mayores aumentaron la frecuencia de fragmentación en enlaces VPN con MTU efectiva menor. El camino incluía un dispositivo de seguridad que descartaba fragmentos no primeros como parte de un “baseline de hardening”. La configuración vieja forzaba más truncamiento y fallback a TCP que—aunque más lento—era fiable. Habían optimizado la ventana de seguridad fuera.

El rollback redujo el tamaño EDNS UDP a un valor conservador y permitieron explícitamente TCP/53. Luego arreglaron la configuración del dispositivo de seguridad para dejar de descartar fragmentos a ciegas y permitieron los tipos ICMP necesarios para PMTUD. La lección no fue “nunca optimices”. Fue “optimiza solo lo que puedas observar de extremo a extremo”, especialmente cuando el protocolo es UDP y la red está llena de middleboxes con opiniones.

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

Un equipo tenía una regla que sonaba aburrida: cualquier cambio de resolvedor requería una prueba canaria desde al menos tres puntos de vista de red—centro de datos, VPN y una VPC en la nube. El conjunto de pruebas no era sofisticado. Era un puñado de dig, algunos nombres DNSSEC grandes conocidos y un caso forzado de +bufsize para simular el peor comportamiento.

Durante una actualización rutinaria, su canario desde la VPN empezó a fallar solo en los nombres de “respuesta grande”. Todo lo demás pasó. La actualización en sí estaba bien. La diferencia fue que el pool de concentradores VPN había sido renovado esa misma semana, y un nuevo modelo de appliance tenía una MTU efectiva menor debido a una capa de encapsulación extra.

Porque probaron desde el borde, lo detectaron antes que los usuarios lo notaran. Bajaron el tamaño EDNS UDP en el resolvedor como mitigación inmediata, luego corrigieron la MTU de la VPN y aseguraron que los mensajes ICMP “Packet Too Big” fueran permitidos. Sin llamada de incidente, sin escalada ejecutiva, sin tickets. Solo pruebas aburridas que previnieron drama.

Broma #2: El trabajo de confiabilidad aburrido es como usar hilo dental—nadie se jacta, pero todos notan cuando no lo haces.

Soluciones que realmente perduran (y qué evitar)

Categoría A: Hacer que DNS sea menos propenso a fragmentarse

Establece un tamaño EDNS UDP conservador

Si solo haces una mitigación, haz esta. Muchos resolvedores y clientes permiten ajustar el tamaño de carga útil UDP anunciado/aceptado. Un objetivo operativo común es 1232 bytes, elegido para jugar bien con IPv6 y overhead típico de túneles.

Lado resolvedor (ejemplos):

• BIND: max-udp-size 1232;
• Unbound: ajusta edns-buffer-size / msg-buffer-size según convenga
• PowerDNS Recursor: configura límites EDNS UDP

El control exacto difiere, pero la intención operativa es la misma: dejar de emitir respuestas UDP “heroicas” que dependan de fragmentación a través de redes desconocidas.

Permite TCP/53 y asegúrate de que el fallback funcione

El fallback a TCP no es un “agradable de tener”. Es la salida de emergencia del protocolo cuando UDP falla o hay truncamiento. Bloquear TCP/53 es un clásico de autodaño empresarial.

No “prefieras UDP” bloqueando TCP. Eso no es preferencia; es sabotaje. Permite TCP/53 al menos entre clientes y resolvedores recursivos, y entre resolvedores y upstreams si operas así.

Categoría B: Arregla el camino (la causa raíz real)

Corrige la MTU en túneles y overlays

Si DNS viaja por un túnel, la MTU del túnel debe tener en cuenta el overhead de encapsulación. IPsec, WireGuard, OpenVPN, GRE, VXLAN—elige tu veneno. El overhead varía y puede apilarse. El enfoque correcto es:

1. Medir PMTU entre endpoints.
2. Establecer MTUs de interfaz en consecuencia.
3. Verificar con pings DF y pruebas DNS reales.

Deja de descartar ICMP esencial

PMTUD necesita mensajes ICMP. No necesitas permitir todos los tipos ICMP desde cualquier lugar, pero sí necesitas permitir los que hacen que la red funcione. Para IPv4, eso es “Fragmentation Needed”. Para IPv6, “Packet Too Big” es innegociable.

Si tu política de seguridad dice “no ICMP”, reescríbela. Si no puedes, al menos sé honesto: estás cambiando corrección operativa por una sensación.

Maneja los fragmentos intencionalmente

Algunos entornos optan por descartar fragmentos como postura de seguridad. Si haces eso, debes compensar: limitar EDNS, asegurar fallback a TCP y verificar que las aplicaciones que dependen de UDP no excedan la MTU. DNS es el caso más visible, pero no la única víctima.

Categoría C: Arregla el comportamiento del cliente (útil, pero no ocultes el fallo de camino)

Las pilas clientes varían. Algunos stub resolvers anuncian búferes EDNS grandes y son agresivos con reintentos UDP. Otros caen rápido a TCP. Algunos son… creativos.

En flotas gestionadas puedes imponer valores seguros:

• Usa un resolvedor caché local (systemd-resolved, Unbound, dnsmasq) con un EDNS conservador.
• Asegura que los clientes VPN configuren MTU sensato y no dependan solo de PMTUD, especialmente si ICMP está filtrado.
• Prefiere DNS sobre TLS/HTTPS solo si entiendes las implicaciones MTU/PMTUD (están basados en TCP, lo que puede ayudar, pero añaden otras piezas móviles).

Qué evitar (porque “arregla” lo equivocado)

• Evita cambiar de resolvedor como parche como solución primaria. Puede cambiar tamaños de respuesta y caching, enmascarando el problema.
• Evita aumentar el tamaño EDNS UDP como truco de rendimiento a menos que controles y pruebes todo el camino.
• Evita “simplemente bloquear fragmentos” sin una estrategia compensatoria de DNS (límite EDNS + fallback TCP).
• Evita adivinar valores de MTU. Mide PMTU. Luego establece la MTU.

Errores comunes: síntoma → causa raíz → arreglar

1) “Solo algunos dominios no resuelven”

Síntoma: Un puñado de dominios agota el tiempo; la mayoría funciona. El servidor DNS parece sano.

Causa raíz: Respuestas UDP grandes (DNSSEC/TXT/muchos registros) se fragmentan; los fragmentos se descartan o ICMP está bloqueado.

Solución: Reduce EDNS UDP size (empieza en 1232), permite TCP/53, arregla MTU/ICMP en túneles/firewalls.

2) “DNS funciona en mi hotspot pero falla en la VPN corporativa”

Síntoma: Mismo cliente, mismo resolvedor, diferente camino de red cambia el comportamiento.

Causa raíz: La VPN reduce la MTU efectiva y/o bloquea ICMP; la fragmentación falla.

Solución: Ajusta la MTU de la VPN, permite ICMP “frag needed/packet too big”, limita EDNS size.

3) “DNS por TCP funciona, UDP se agota”

Síntoma: dig +tcp funciona; dig (UDP) falla de forma intermitente.

Causa raíz: Fragmentación UDP o agujero PMTUD.

Solución: Investiga PMTU; permite fragmentos o reduce tamaño UDP; asegúrate de que TCP/53 no esté bloqueado.

4) “Hicimos MSS clamping, pero DNS sigue fallando”

Síntoma: Alguien señala --clamp-mss-to-pmtu esperando milagros.

Causa raíz: MSS clamping solo impacta TCP. DNS usa principalmente UDP.

Solución: Limita EDNS UDP size y arregla MTU/ICMP; no confundas mitigaciones TCP con comportamiento UDP.

5) “Bloqueamos ICMP y ahora cosas al azar cuelgan”

Síntoma: Grandes transferencias se estancan; DNS ocasionalmente agota; IPv6 empeora.

Causa raíz: PMTUD falla; se forman agujeros negros; los endpoints siguen enviando paquetes demasiado grandes.

Solución: Permite tipos ICMP esenciales; valida con ping DF y captura de paquetes.

6) “DNS del clúster Kubernetes es inestable tras habilitar cifrado en overlay”

Síntoma: Pods obtienen timeouts DNS intermitentes; los nodos pueden estar bien.

Causa raíz: La MTU del overlay se redujo por encapsulación; los pods siguen asumiendo 1500; pérdida de fragmentos o descartes en nodos.

Solución: Ajusta MTU del CNI correctamente, verifica la alineación MTU nodo/pod, limita EDNS en CoreDNS/upstream.

Listas de verificación / plan paso a paso

Paso a paso: del síntoma a la causa raíz (probado en campo)

1. Elige dos nombres: uno que falla y uno que funciona. Prefiere un nombre pesado en DNSSEC para el que falla.
2. Ejecuta tres consultas: UDP normal, TCP forzado, UDP con +bufsize=1232.
3. Si TCP tiene éxito y el búfer pequeño funciona: trata como MTU/fragmentación hasta que se pruebe lo contrario.
4. Identifica la ruta: ip route get <resolver_ip> y registra la interfaz de salida.
5. Revisa la MTU de la interfaz: ip link show dev <if>.
6. Mide PMTU al resolvedor: pings DF (IPv4) o pings dimensionados (IPv6). Registra el mayor tamaño que funciona.
7. Captura paquetes: en la interfaz de salida mientras reproduces. Busca reintentos, truncamiento, respuestas faltantes.
8. Revisa la política de firewall: asegúrate que ICMP esencial pase; verifica la postura sobre fragmentos.
9. Mitiga rápido: fija max-udp-size del resolvedor (o equivalente) a 1232; asegúrate de que TCP/53 esté permitido.
10. Arregla permanentemente: corrige MTU de túneles/overlays; evita apilar túneles sin recalcular overhead.
11. Prueba de regresión: canario desde VPN + centro de datos + nube con consultas de respuesta grande.
12. Documenta: registra valores PMTU por ruta principal e integra pruebas en la gestión de cambios.

Lista operativa: “vamos a cambiar MTU/túneles/firewalls”

• Mide PMTU antes y después del cambio desde al menos dos endpoints.
• Prueba DNS UDP con EDNS en 1232 y con un valor mayor (para exponer problemas de fragmentación temprano).
• Verifica que TCP/53 esté permitido para clientes hacia resolvedores recursivos.
• Verifica que los tipos ICMP necesarios para PMTUD estén permitidos (especialmente ICMPv6 Packet Too Big).
• Decide tu política sobre fragmentos intencionalmente; no heredes defaults a ciegas.
• Actualiza EDNS max UDP size del resolvedor si el entorno incluye túneles/overlays que no controlas completamente.

Preguntas frecuentes

1) ¿Por qué DNS usa UDP si es frágil?

Latencia y simplicidad. UDP evita el establecimiento de conexión y escala bien para consultas pequeñas. El protocolo incluye fallback a TCP para respuestas más grandes y reintentos por pérdida. La fragilidad viene de middleboxes y PMTUD roto, no de DNS por sí mismo.

2) Si permito TCP/53, ¿sigo necesitando arreglar MTU?

Sí. El fallback TCP es una red de seguridad, no una cura. Si tu camino es un agujero negro de PMTU, otros protocolos basados en UDP (e incluso TCP en ciertos casos) también pueden sufrir. Arregla la red para que se comporte de forma predecible.

3) ¿Qué tamaño EDNS UDP debo elegir?

Si operas a través de VPNs/overlays/firewalls empresariales, empieza en 1232 bytes. Si controlas cada salto y puedes demostrar que funciona algo mayor, puedes aumentarlo. Pero no lo subas porque a un benchmark le gustó.

4) ¿Cómo saber si es fragmentación vs “servidor DNS malo”?

La prueba clásica: dig +tcp funciona mientras UDP se agota, y dig +bufsize=1232 funciona mientras +bufsize=4096 falla. Las capturas de paquete mostrarán respuestas UDP faltantes o reintentos.

5) ¿Por qué IPv6 suele empeorar esto?

Los routers IPv6 no fragmentan en tránsito. Los endpoints deben manejarlo, y PMTUD depende de que ICMPv6 “Packet Too Big” llegue al remitente. Si tu red bloquea ese ICMPv6, estás creando un agujero negro IPv6 por diseño.

6) ¿DNSSEC puede ser el detonante aunque yo no “use DNSSEC”?

Sí. Los resolvedores recursivos pueden validar DNSSEC y solicitar registros adicionales, y los clientes pueden pedir DNSSEC (el bit DO). Incluso sin peticiones del cliente, el comportamiento upstream puede agrandar respuestas para ciertos nombres.

7) ¿Y DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT)?

Van sobre TCP (y a menudo TLS), por lo que son menos sensibles a la fragmentación UDP. Pero introducen modos de fallo distintos (intercepción por proxies, inspección TLS, límites de conexión, latencia). No uses DoH/DoT como parche para MTU roto a menos que aceptes esos tradeoffs.

8) Veo respuestas “truncadas” (bit TC). ¿Eso es MTU?

No necesariamente. Truncamiento significa que el servidor cortó intencionalmente la respuesta UDP y pide al cliente reintentar por TCP. Eso puede ser causado por límites de tamaño, políticas o comportamiento upstream. Los problemas de MTU a menudo aparecen como timeouts en lugar de truncamiento limpio porque la respuesta se pierde en vuelo.

9) ¿Puede una sola regla de firewall romper solo respuestas DNS grandes?

Absolutamente. Una regla que descarta fragmentos IP, o bloquea ICMP “frag needed”, perjudica selectivamente paquetes que exceden la PMTU. Las respuestas pequeñas siguen funcionando, por eso este problema perdura tanto en producción.

Próximos pasos que puedes hacer hoy

Los errores de MTU no se anuncian. Se disfrazan de DNS inestable, timeouts “aleatorios” y quejas de usuarios que parecen subjetivas hasta que te das cuenta de que los tamaños de paquete son objetivos.

1. Demuéstralo: ejecuta dig normal vs +tcp vs +bufsize=1232 para un nombre que falle.
2. Mídelo: encuentra la interfaz de salida y la PMTU hacia la IP del resolvedor usando pings DF.
3. Mitiga rápido: limita EDNS UDP del resolvedor a 1232 y asegúrate de que TCP/53 esté permitido.
4. Arregla de verdad: corrige MTU de túneles/overlays y permite ICMP esencial para PMTUD; decide la política de fragmentos intencionalmente.
5. Manténlo arreglado: añade una prueba canaria desde VPN + centro de datos + nube que incluya al menos una respuesta DNSSEC grande.

Haz esas cinco cosas y dejarás de tratar a DNS como un servicio místico y empezarás a verlo como lo que es: paquetes, tamaños y caminos. La red todavía encontrará nuevas formas de decepcionarte, pero al menos sabrás dónde mirar primero.