Fragmentación DNS EDNS0: la causa oculta de “Funciona en Wi‑Fi, falla en LTE”

Qué es realmente la fragmentación EDNS0 (y por qué LTE es el villano perfecto)

DNS nació con respuestas UDP limitadas a 512 bytes. Eso no fue un “capricho”; fue supervivencia.
Paquetes pequeños significan menos fragmentación, menos retransmisiones, menos sorpresas. Luego Internet se volvió ambicioso:
más registros por respuesta, más glue, IPv6, firmas DNSSEC y la intención de no forzar TCP para todo.

EDNS0 (Extension Mechanisms for DNS) es el compromiso. El cliente (resolver) dice: “Puedo aceptar respuestas UDP de hasta N bytes.”
El servidor intenta ajustarse. Si no puede, establece el bit TC (truncado) y el cliente reintenta sobre TCP.
En papel, esto es elegante. En redes de producción, “el papel” es especie en peligro.

La trampa: cuando anuncias un tamaño UDP grande (comúnmente 1232, 1400, 4096), invitas respuestas UDP grandes.
Las respuestas UDP grandes a menudo exceden la MTU del camino y se fragmentan en la capa IP.
La fragmentación significa: una respuesta DNS se convierte en múltiples paquetes IP que deben llegar todos y reensamblarse correctamente.
Pierdes un fragmento y toda la respuesta DNS se evapora.

Muchas redes móviles y redes con “middleboxes” pesados son alérgicas a los fragmentos. Algunas descartan fragmentos por diseño.
Algunas los manejan mal. Otras los reensamblan incorrectamente. Algunas los limitan por tasa hasta el olvido.
Los caminos Wi‑Fi—especialmente dentro de redes corporativas o banda ancha doméstica—tienden a ser más indulgentes, o al menos consistentes.
Los caminos LTE son una carrera de obstáculos de NATs, firewalls, optimizadores de tráfico y motores de políticas. Ese es el punto: LTE no es “peor”,
es simplemente más complejo.

Tu outage no es que DNS esté caído. Tu outage es que DNS está a veces incompleto.
Esos son los peores outages porque el monitoreo siempre llega tarde a la fiesta.

Broma #1: La fragmentación UDP es como enviar una taza de porcelana en dos sobres—técnicamente posible, emocionalmente irresponsable.

La mecánica en términos sencillos

• El cliente envía una consulta DNS (UDP) con un registro OPT EDNS0 indicando “Puedo recibir X bytes”.
• El servidor responde (UDP) intentando ajustarse dentro de X bytes.
• Si la respuesta aún no cabe, el servidor establece TC=1 (truncado) y el cliente debería reintentar por TCP.
• Si la respuesta cabe en X pero excede la MTU del camino, la capa IP la fragmenta.
• Si los fragmentos se descartan, retrasan o filtran, el cliente ve un timeout—no necesariamente TC.

Por qué el “UDP grande” resulta seductor

A los operadores les gusta evitar TCP para DNS: menos conexiones, menos estado, menor latencia bajo carga.
Algunos resolvers y servidores autoritativos incluso por defecto usan tamaños EDNS generosos porque dan buenos benchmark en laboratorios limpios.
Luego aparecen las redes reales. Especialmente las móviles. Especialmente en roaming. Especialmente con overlays VPN.

Por qué funciona en Wi‑Fi pero falla en LTE

El modelo mental más simple: los usuarios en Wi‑Fi suelen estar detrás de un solo NAT con MTU estable y menos “ayudantes” de paquetes.
Los usuarios en LTE están detrás de carrier-grade NAT, a menudo múltiples capas de aplicación de políticas, y a veces MTUs peculiares.
Añade mecanismos de transición IPv6, túneles y “optimizadores”, y los fragmentos se vuelven sospechosos.

Características comunes del camino LTE que rompen UDP fragmentado

• Carrier-grade NAT (CGNAT) que tiene limitaciones de manejo de fragmentos o timeouts agresivos.
• Políticas de firewall que descartan fragmentos no iniciales porque son difíciles de clasificar.
• Modelado de tráfico que deprioriza o limita por tasa los fragmentos (a veces sin querer).
• Variabilidad de la Path MTU debida a roaming o backhauls tunelizados.
• Traducción IPv6/IPv4 donde el manejo de fragmentos difiere entre pilas o es defectuoso.

El desajuste “tamaño EDNS0 vs MTU”

Supongamos que tu resolver anuncia EDNS0 UDP size 4096. Tu servidor autoritativo responde gustoso con un paquete UDP de 1800 bytes.
Ese payload IP de 1800 bytes no cabe en una MTU Ethernet típica de 1500 bytes después de las cabeceras. Ocurre fragmentación.
En Wi‑Fi, los fragmentos llegan; en LTE, el segundo fragmento desaparece. El cliente ve un timeout.

Ahora supongamos que reduces el tamaño EDNS0 a 1232. Muchas respuestas quedan por debajo de los umbrales de fragmentación.
O el servidor trunca antes, forzando el fallback a TCP. De cualquier modo, dejas de depender de fragmentos frágiles.
Por eso 1232 se ha convertido en un punto práctico: es lo bastante conservador para evitar fragmentación en muchos caminos,
incluyendo IPv6 donde las cabeceras son mayores y las reglas de fragmentación difieren.

Por qué no siempre ves el fallback a TCP

“Pero DNS debería reintentar por TCP si UDP falla.” En teoría, sí.
En realidad:

• Algunos clientes son lentos para hacer fallback, haciendo que la UX parezca “cuelgue y quizá cargue”.
• Algunos middleboxes bloquean DNS sobre TCP (puerto 53) o lo tratan como sospechoso.
• Algunos resolvers cachean fallos parciales, amplificando el dolor durante unos minutos.
• Algunas configuraciones autoritativas no manejan TCP a escala y caducan bajo picos de fallback.

Los errores de fragmentación EDNS0 no solo rompen UDP. Pueden lanzarte a un patrón de carga TCP para el que no estabas dimensionado.

Hechos interesantes y contexto histórico (lo que explica las rarezas de hoy)

• El límite original de 512 bytes de UDP en DNS no fue un estándar arbitrario; se diseñó para una Internet donde la fragmentación era un peligro operativo real.
• EDNS0 se estandarizó a fines de los años 1990 para ampliar DNS sin cambiar el formato central del mensaje, usando un pseudo-registro OPT.
• DNSSEC hizo comunes las “respuestas grandes” añadiendo firmas (RRSIG), claves (DNSKEY) y pruebas de negación de existencia (NSEC/NSEC3).
• “Más grande es más rápido” se volvió un mito operativo cuando algunos resolvers por defecto usaron buffers EDNS0 grandes para reducir fallbacks TCP en benchmarks.
• IPv6 cambió las reglas de fragmentación: los routers no fragmentan; solo los endpoints lo hacen, lo que hace más importante el PMTU discovery y el dimensionamiento de paquetes.
• Algunos firewalls antiguos descartan fragmentos por defecto porque los fragmentos no iniciales no llevan cabeceras L4, complicando el filtrado.
• Los CDNs y respuestas con múltiples registros aumentaron el tamaño de las respuestas: múltiples A/AAAA, variaciones ECS y glue extra pueden inflar las respuestas.
• EDNS Client Subnet (ECS) puede cambiar el tamaño de la respuesta y el comportamiento de caché, empujando ocasionalmente respuestas por encima de los umbrales de fragmentación inesperadamente.
• “DNS sobre TCP existe por una razón”: incluso las primeras especificaciones de DNS incluían TCP como fallback fiable, pero muchos operadores lo trataron como “raro”.

Firmas de falla que puedes reconocer en minutos

Los problemas de fragmentación EDNS0 tienen un olor particular. Ves timeouts, pero solo en ciertas redes.
Ves que algunos tipos de registros fallan (a menudo relacionados con DNSSEC, o con TXT voluminosos).
Y ves “funciona si lo intento de nuevo” porque las rutas de reintento son diferentes.

Síntomas clásicos

• Wi‑Fi funciona, LTE falla (o funciona en un operador, falla en otro).
• Las búsquedas AAAA fallan más que A porque las respuestas son más grandes o porque la MTU del camino IPv6 difiere.
• Fallos de validación DNSSEC en dominios específicos, a menudo intermitentes y dependientes de la geografía.
• Registros TXT grandes (SPF, DKIM, tokens de verificación) causan fallos solo para algunos usuarios.
• Los servidores autoritativos parecen sanos; el volumen de consultas es normal; pero los logs del cliente muestran SERVFAIL o timeouts.
• Capturas de paquetes muestran respuestas salientes sin el ACK/respuesta correspondiente porque UDP no hace ACK; inferes pérdida por reintentos.

Lo que realmente estás observando

Estás viendo un problema de transporte que se hace pasar por un problema de resolución de nombres. DNS es la carga; la fragmentación es el cuchillo.
Tu resolver envía una consulta, tu autoritativo responde, y un fragmento muere en tránsito. La respuesta no puede reensamblarse.
Desde la perspectiva del cliente, es indistinguible de “el servidor no respondió.”

“idea parafraseada” de Richard Cook (seguridad/ops): los sistemas fallan de maneras sorprendentes porque el éxito requiere que muchas cosas salgan bien; la falla necesita que una cosa salga mal.

Guía rápida de diagnóstico

No empieces debatiendo servidores DNS. Empieza probando si estás perdiendo fragmentos o forzando truncamiento.
El objetivo es reducir el problema a una sola frase accionable: “Las respuestas UDP grandes mueren en la ruta LTE.”

Primero: confirma que es tamaño/transporte, no “registros incorrectos”

1. Compara la misma consulta en dos redes (Wi‑Fi vs LTE) usando el mismo resolver, si es posible.
2. Forza tamaños EDNS0 más pequeños y observa si los fallos desaparecen.
3. Forza TCP y observa si los fallos desaparecen (o si TCP está bloqueado).

Segundo: determina dónde se produce la rotura

1. Resolver stub del cliente vs resolver recursivo: ¿funciona consultar al recursivo directamente?
2. Recursivo vs autoritativo: ¿el recursivo falla solo cuando habla con autoridades específicas?
3. Dispositivos de borde: ¿tienes un firewall, balanceador o appliance anti-DDoS frente al DNS autoritativo?

Tercero: aplica la mitigación de menor riesgo

1. Reduce el tamaño UDP anunciado por EDNS0 en resolvers recursivos (a menudo a 1232).
2. Asegura que TCP/53 funcione de extremo a extremo (recursivo a autoritativo, y clientes a recursivo según la arquitectura).
3. Evita respuestas sobredimensionadas: recorta bloat en TXT, reduce registros innecesarios, considera shaping de respuestas DNSSEC.

Tareas prácticas: comandos, salida, qué significa y qué decides (12+)

Task 1: Medir el tamaño de la respuesta y ver si coquetea con fragmentación

cr0x@server:~$ dig example.com A +dnssec +bufsize=4096 @8.8.8.8

; <<>> DiG 9.18.24 <<>> example.com A +dnssec +bufsize=4096 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14651
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; MSG SIZE  rcvd: 97

Qué significa: MSG SIZE rcvd es pequeño aquí, así que la fragmentación no es el problema para esta consulta.
Decisión: Prueba los dominios/tipos de registro que fallan (TXT, DNSKEY, cadenas largas de CNAME), no un A de juguete.

Task 2: Probar un registro “grande” conocido (TXT) con buffer EDNS0 grande

cr0x@server:~$ dig example.com TXT +bufsize=4096 @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53204
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      TXT

;; ANSWER SECTION:
example.com.            3600    IN      TXT     "v=spf1 -all"
example.com.            3600    IN      TXT     "some-long-verification-token=..."
example.com.            3600    IN      TXT     "another-token=..."

;; Query time: 31 msec
;; MSG SIZE  rcvd: 1605

Qué significa: 1605 bytes por UDP probablemente se fragmenten en muchos caminos con MTU 1500.
Decisión: Reprueba con tamaños EDNS0 más pequeños y con TCP para confirmar sensibilidad al tamaño.

Task 3: Forzar un tamaño EDNS0 conservador para evitar fragmentación

cr0x@server:~$ dig example.com TXT +bufsize=1232 @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60421
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      TXT

;; ANSWER SECTION:
example.com.            3600    IN      TXT     "v=spf1 -all"
example.com.            3600    IN      TXT     "some-long-verification-token=..."

;; Query time: 29 msec
;; MSG SIZE  rcvd: 812

Qué significa: La respuesta se redujo (quizá entraron menos registros, o el resolver ajustó).
Decisión: Si LTE empieza a funcionar con 1232 pero no con 4096, has diagnosticado pérdida por fragmentación.

Task 4: Detectar truncamiento (bit TC) y ver si debería ocurrir fallback a TCP

cr0x@server:~$ dig example.com DNSKEY +dnssec +bufsize=512 @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3122
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has been truncated
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.                   IN      DNSKEY

;; Query time: 35 msec
;; MSG SIZE  rcvd: 512

Qué significa: tc está establecido; la respuesta UDP no cupo. Un resolver bien comportado debería reintentar por TCP.
Decisión: Si los clientes aún fallan, verifica si TCP/53 está bloqueado o si el autoritativo maneja mal TCP.

Task 5: Forzar TCP y ver si la “falla en LTE” desaparece

cr0x@server:~$ dig example.com DNSKEY +dnssec +tcp @1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61752
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com.                   IN      DNSKEY

;; ANSWER SECTION:
example.com.            3600    IN      DNSKEY  257 3 13 ...
example.com.            3600    IN      DNSKEY  256 3 13 ...

;; Query time: 44 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)
;; MSG SIZE  rcvd: 1203

Qué significa: TCP funciona y devuelve un payload más grande de forma fiable.
Decisión: Si TCP funciona en todas partes pero UDP falla en LTE, mitiga reduciendo tamaños UDP y asegurando que TCP esté permitido.

Task 6: Verificar si tu resolver recursivo anuncia un tamaño EDNS agresivo

cr0x@server:~$ dig whoami.akamai.net TXT +bufsize=4096 @10.0.0.53

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;whoami.akamai.net.            IN      TXT
;; ANSWER SECTION:
whoami.akamai.net.     20      IN      TXT     "198.51.100.17"
;; MSG SIZE  rcvd: 128

Qué significa: Tu resolver (10.0.0.53) está dispuesto a recibir respuestas UDP de 4096 bytes de autoridades upstream.
Decisión: Considera reducir eso a 1232 salvo que tengas una razón probada para lo contrario.

Task 7: Revisar truncamientos y reintentos en logs de Unbound

cr0x@server:~$ sudo journalctl -u unbound --since "1 hour ago" | egrep -i "trunc|tc|timeout" | tail -n 8
[12234:0] info: response was truncated, retrying with TCP
[12234:0] info: tcp connected to 203.0.113.53 port 53
[12234:0] info: tcp returned answer for example.com. DNSKEY IN
[12234:0] info: resolving example.com. TXT IN: query response was truncated
[12234:0] info: tcp error: connection timed out
[12234:0] info: validation failure <example.com. DNSKEY IN>: no DNSKEY rrset

Qué significa: Ves truncamiento e intentos de fallback a TCP; una conexión TCP agotó tiempo.
Decisión: Investiga la alcanzabilidad de TCP/53 hacia autoridades específicas y cualquier middlebox entre el recursivo e Internet.

Task 8: Confirmar que TCP/53 es alcanzable desde el recursivo al autoritativo

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

Qué significa: TCP/53 es alcanzable a ese servidor desde este host.
Decisión: Si esto falla para algunas autoridades, arregla políticas de firewall/egress o usa un resolver que llegue por TCP de forma fiable.

Task 9: Capturar fragmentos en el recursivo y probar que están ocurriendo

cr0x@server:~$ sudo tcpdump -ni eth0 'udp port 53 and (ip[6:2] & 0x1fff != 0)' -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:03:21.112233 IP 198.51.100.10.53 > 10.0.0.53.49321: UDP, length 1472
14:03:21.112240 IP 198.51.100.10 > 10.0.0.53: ip-proto-17
14:03:21.112245 IP 198.51.100.10 > 10.0.0.53: ip-proto-17
5 packets captured

Qué significa: El filtro matcheó UDP fragmentado (offset de fragmento no cero o flag MF). Estás viendo fragmentos.
Decisión: Si clientes en LTE fallan y observas fragmentación en el camino, reduce tamaños EDNS y prioriza fallback TCP.

Task 10: Revisar comportamiento ICMP relacionado con PMTU (un cómplice silencioso común)

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

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

Qué significa: Tienes una MTU de 1492 en algún punto (PPPoE es un sospechoso habitual), así que los payloads “seguros” son más pequeños.
Decisión: Trata 1232 como línea base y desconfía de cualquier cosa que empuje respuestas UDP DNS por encima de ~1200 bytes de forma rutinaria.

Task 11: Inspeccionar reglas iptables/nftables que puedan descartar fragmentos

cr0x@server:~$ sudo iptables -S | egrep -i "fragment|frag|DROP" | head
-A INPUT -f -j DROP
-A FORWARD -f -j DROP

Qué significa: “-f” coincide con fragmentos; los estás descartando. Eso no es “seguridad”, es sabotaje a protocolos UDP.
Decisión: Deja de descartar fragmentos a ciegas en rutas que enfrentan DNS; en su lugar reduce fragmentación bajando EDNS y permitiendo TCP.

Task 12: Validar que tu DNS autoritativo responde por TCP (algunos no lo hacen hasta que los fuerzas)

cr0x@server:~$ dig yourzone.example DNSKEY +tcp @ns1.yourauth.example

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40422
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; SERVER: 192.0.2.53#53(192.0.2.53) (TCP)
;; MSG SIZE  rcvd: 1890

Qué significa: TCP funciona y devuelve una respuesta grande.
Decisión: Si TCP falla aquí, arregla el soporte TCP autoritativo antes de “tunear EDNS” en otro sitio.

Task 13: En BIND, revisar ajustes EDNS y TCP actuales (autoritativo o recursivo)

cr0x@server:~$ sudo named-checkconf -p | egrep -i "edns|tcp|max-udp-size|clients-per-query|tcp-clients" | head -n 20
tcp-clients 100;
clients-per-query 10;
max-udp-size 4096;

Qué significa: max-udp-size 4096 invita a la fragmentación en caminos reales.
Decisión: Considera bajar max-udp-size (o equivalente) y asegúrate de que tcp-clients esté dimensionado para picos de fallback.

Task 14: En Unbound, confirmar buffer EDNS y ajustarlo con seguridad

cr0x@server:~$ sudo unbound-checkconf | egrep -i "edns-buffer-size|so-rcvbuf|so-sndbuf|tcp-upstream|do-tcp" || true
edns-buffer-size: 4096

Qué significa: Unbound está anunciando 4096 upstream. Eso suele ser demasiado optimista en entornos con mucho tráfico móvil.
Decisión: Fija edns-buffer-size a 1232, luego monitoriza la tasa de consultas TCP y la latencia.

Task 15: Demostrar que cambiar tamaño EDNS altera el comportamiento frente a la misma autoridad

cr0x@server:~$ dig bigdns.example TXT +bufsize=4096 @ns.bigauth.example
;; Query time: 1200 msec
;; connection timed out; no servers could be reached

cr0x@server:~$ dig bigdns.example TXT +bufsize=1232 @ns.bigauth.example
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2211
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 48 msec
;; MSG SIZE  rcvd: 1198

Qué significa: El mismo servidor, el mismo registro; solo cambió el tamaño EDNS. Uno caduca; otro tiene éxito.
Decisión: Esta es tu pistola humeante: fragmentación o intolerancia de middlebox en el camino.

Tres mini-historias corporativas desde la trinchera

Mini-historia 1: El incidente causado por una suposición equivocada

Una compañía que llamaré “Northwind Billing” tenía una configuración ordenada: DNS autoritativo Anycast detrás de un proveedor de scrubbing DDoS,
más un fallback recursivo público popular para diagnósticos internos. Activaron DNSSEC para su zona principal durante un empuje de cumplimiento rutinario.
El despliegue fue silencioso para usuarios de escritorio. Las inscripciones móviles, sin embargo, se desplomaron.

La primera suposición fue terriblemente humana: “Los usuarios móviles tienen mala cobertura.” La segunda suposición fue peor: “DNS es plomería estable.”
Soporte reportó un patrón consistente: banda ancha doméstica y Wi‑Fi de oficina funcionaban; LTE frecuentemente fallaba en la primera carga de página.
Ingeniería persiguió logs de API, luego misses en CDN, luego telemetría de handshake TLS. Todo estaba normal porque nada llegaba a la app.

El avance vino de una captura de paquetes tomada en un hotspot LTE durante la ventana de fallo.
La respuesta DNS que contenía DNSKEY/RRSIG era grande, fragmentada, y el segundo fragmento nunca llegó.
No se puso el bit TC porque la respuesta cabía dentro del buffer EDNS0 anunciado por el resolver; simplemente no cabía en el camino.
El recursivo reintentó; el teléfono del usuario se rindió primero. DNS estaba “activo”. También era inutilizable.

Arreglarlo no fue glamoroso. Redujeron el buffer EDNS0 en su flota recursiva a 1232, confirmaron que TCP/53 estaba permitido,
y monitorizaron el aumento de consultas TCP. La tasa de fallos cayó inmediatamente.
La “suposición equivocada” no fue técnica. Fue gerencial: tratar fallos DNS móviles como “aleatorios” en lugar de “dependientes del camino.”

Mini-historia 2: La optimización que se volvió contra ellos

“Bluejay Media” operaba un servicio recursivo de alto volumen para sus apps. La latencia era una métrica de vanidad: cada milisegundo se discutía.
Alguien notó que el fallback a TCP ocurría más de lo esperado durante picos. La optimización fue sencilla:
elevar el tamaño anunciado EDNS0 para que más respuestas cupieran en UDP, menos handshakes TCP, menor latencia mediana. Los benchmarks lucían bien.

Dos semanas después empezaron a recibir quejas específicas por operador: una gran red móvil tenía problemas intermitentes de login.
No todos. No cada región. Justo lo suficiente para ser una pesadilla.
Sus dashboards mostraban leves aumentos en timeouts DNS, pero no lo suficiente para disparar alertas. Los equipos de app vieron fallos de autenticación.
Seguridad no vio nada. Red no vio nada. Todos veían el problema de otro.

El contragolpe fue clásico: aumentar EDNS0 cambió el sistema de “TC provoca TCP” a “los UDP fragmentados deben sobrevivir”.
En ese operador, los fragmentos se limitaban por tasa agresivamente durante la congestión. Bajo carga, el resolver escupía respuestas fragmentadas a una trituradora.
Los reintentos aumentaron tráfico. El tráfico aumentó congestión. La congestión aumentó drops. No fue un outage; fue un bucle de retroalimentación.

Revirtieron el tamaño EDNS0 y—esto es lo que la gente omite—mantuvieron la reversión.
Luego dimensionaron TCP correctamente, incluyendo límites de conexión, tuning de kernel y observabilidad en las tasas de fallback TCP.
La optimización que “mejoró medianas” fue una regresión de fiabilidad escondida en la latencia de cola y en redes específicas.

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

“Kestrel Finance” tenía una regla interna: todo servicio DNS autoritativo debe soportar bien TCP, y cada cambio en zonas DNS pasa una
“verificación de respuestas grandes” en CI. La regla existía porque uno de sus SREs sénior detestaba personalmente la pérdida de paquetes.
Parecía exceso—hasta que dejó de serlo.

Un proveedor les pidió añadir múltiples registros TXT de verificación y una cadena SPF larga para un nuevo servicio de correo.
La petición de cambio pareció inofensiva. CI la detectó: la respuesta TXT excedía 1400 bytes con DNSSEC activado.
El pipeline no la bloqueó del todo; requirió una exención explícita con un plan de mitigación.

El plan de mitigación fue aburrido: dividir registros TXT cuando fue posible, eliminar tokens obsoletos y asegurar que los resolvers recursivos anunciaran 1232.
También verificaron la alcanzabilidad TCP/53 desde todos los puntos de egress usados por su flota recursiva.
El cambio se desplegó sin drama, porque ya habían ensayado el modo de fallo y diseñado alrededor de él.

El salvavidas no fue un truco ingenioso. Fue paranoia institucionalizada: probar la ruta fea (respuestas grandes) antes que los usuarios,
y tratar TCP como ciudadano de primera clase en lugar de un fallback vergonzoso.

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

1) “Solo fallan usuarios móviles, equipos de escritorio bien” → UDP fragmentado descartado en camino celular → reducir EDNS y confirmar TCP

• Síntoma: timeouts DNS mayormente en LTE; Wi‑Fi estable.
• Causa raíz: respuestas UDP grandes se fragmentan; fragmentos descartados por CGNAT/firewalls.
• Solución: Configurar buffer EDNS a 1232 en recursivos; verificar TCP/53; monitorizar tasa de consultas TCP.

2) “DNSSEC falla aleatoriamente la validación” → fragmentos faltantes producen DNSKEY/RRSIG incompletos → reducir UDP, mejorar TCP, evitar bloat

• Síntoma: SERVFAIL desde resolvers validadores; intermitente, dependiente de operador o región.
• Causa raíz: las respuestas DNSSEC son más grandes; fragmentos perdidos; la validación falla.
• Solución: Bajar tamaño EDNS; asegurar respuestas autoritativas por TCP; reducir tamaño de conjuntos de RR cuando sea posible.

3) “Aumentamos EDNS para reducir TCP y empeoró” → optimización creó dependencia de fragmentos → revertir EDNS, escalar TCP correctamente

• Síntoma: menos respuestas TC pero más timeouts y reintentos.
• Causa raíz: menos truncamientos significa menos fallbacks TCP; ahora UDP grande se fragmenta y muere.
• Solución: Preferir fallback TCP predecible sobre fragmentación frágil; planificar capacidad para clients TCP y estado.

4) “UDP funciona, TCP falla” → middlebox bloquea TCP/53 → permitir TCP o usar DoT/DoH hacia tus recursivos

• Síntoma: dig funciona sin +tcp, falla con +tcp, o TCP caduca hacia autoridades.
• Causa raíz: firewalls/proxies bloquean o limitan TCP/53.
• Solución: Corregir políticas; asegurar que dispositivos stateful permitan TCP/53; si controlas clientes, considera DNS cifrado a un recursivo de confianza.

5) “Falla solo en algunos dominios” → grandes RRsets, TXT largos, muchas A/AAAA, variaciones ECS → recortar y medir tamaños de respuesta

• Síntoma: fallan solo ciertos proveedores o zonas.
• Causa raíz: el tamaño de la respuesta cruza umbrales de fragmentación por el tamaño del RRset.
• Solución: eliminar TXT obsoletos; evitar respuestas con múltiples valores innecesarios; validar con dig +bufsize.

6) “Descartamos fragmentos por seguridad” → rompiste protocolos UDP → deja de hacerlo (y arregla la razón subyacente)

• Síntoma: timeouts UDP aleatorios; DNS peor cuando las respuestas son grandes.
• Causa raíz: reglas de firewall que descartan fragmentos (-f), especialmente en caminos forward.
• Solución: Eliminar descartes genéricos de fragmentos en rutas DNS; usar sizing EDNS sensato y fallback TCP.

Broma #2: Los middleboxes que “optimizan” fragmentos son como becarios que reescriben tus runbooks—confiados, rápidos y creativamente catastróficos.

Listas de verificación / plan paso a paso

Paso a paso: detener el outage primero, luego arreglar correctamente

1. Reproducir en una ruta fallida: usa una conexión LTE real, no una VPN de oficina que finge ser móvil.
2. Ejecuta tres digs para el nombre que falla:
   • por defecto (lo que haga tu resolver)
   • +bufsize=1232
   • +tcp
3. Si +tcp lo arregla, trata esto como un problema de fragmentación/truncamiento UDP hasta que se demuestre lo contrario.
4. Baja el buffer EDNS en resolvers recursivos a 1232 (o similar conservador) y despliega progresivamente.
5. Confirma la alcanzabilidad TCP/53 desde recursivos hacia Internet y desde clientes hacia recursivos (según arquitectura).
6. Vigila stampedes TCP:
   • conteo de conexiones TCP
   • backlog SYN y colas de escucha
   • latencia y timeouts del resolver
7. Recorta respuestas DNS sobredimensionadas:
   • eliminar tokens TXT antiguos
   • simplificar SPF cuando sea posible
   • evitar RRsets con múltiples valores innecesarios
8. Documentar y probar: añade una “prueba de regresión de respuestas grandes” para zonas críticas, especialmente con DNSSEC.

Checklist operacional: cómo luce “bien”

• Los resolvers recursivos anuncian tamaños UDP EDNS conservadores a autoridades upstream (comúnmente 1232).
• DNS autoritativo soporta TCP de forma fiable y a escala.
• Firewalls y balanceadores no descartan fragmentos a ciegas en rutas DNS.
• El monitoreo incluye: tasa de bit TC, tasa de fallback TCP, tasa de timeouts UDP, tasa de SERVFAIL y telemetría de error por operador (si la tienes).
• La gestión de cambios incluye cheques de tamaño de respuesta para TXT, DNSKEY y cadenas de peor caso (CNAME+DNSSEC es un inflador clásico).

Preguntas frecuentes (FAQ)

1) ¿EDNS0 es “malo”?

No. EDNS0 es necesario. Lo malo es pretender que los payloads UDP grandes son entregables de forma fiable a través de redes modernas,
especialmente móviles y a través de middleboxes.

2) ¿Qué tamaño UDP EDNS0 debo usar?

Si quieres un valor práctico en 2025, 1232 es una opción conservadora que suele evitar fragmentación en caminos IPv6 y IPv4 comunes.
Si operas en redes controladas, puedes experimentar con valores mayores, pero necesitas pruebas en caminos de producción, no en bancos de pruebas.

3) ¿Por qué bajar EDNS0 a veces hace que las respuestas “se hagan más pequeñas” en lugar de truncarse?

Algunos resolvers ajustan su comportamiento: pueden evitar añadir ciertos registros opcionales, preferir servidores distintos o recibir variantes cacheadas diferentes.
Pero el resultado operativo clave es lo que importa: menos respuestas UDP fragmentadas y patrones de fallback más predecibles.

4) Si la fragmentación es el problema, ¿por qué no “arreglar la MTU”?

A menudo no puedes. La ruta que falla puede ser la red del carrier, una ruta en roaming o el túnel VPN de un usuario.
Puedes controlar el comportamiento de tu resolver y de tus autoritativos; por lo general no puedes controlar cada MTU entre un teléfono y Internet.

5) ¿TCP para DNS no aumenta latencia y carga?

Puede. Pero UDP poco fiable con reintentos y timeouts es peor—especialmente para la experiencia de usuario.
La estrategia correcta es: mantener las respuestas UDP lo bastante pequeñas para evitar fragmentación y hacer TCP robusto para los casos que lo necesiten.

6) ¿Se puede desplegar DNSSEC sin romper móviles?

Sí. Pero debes planear respuestas más grandes, verificar soporte TCP, mantener RRsets ordenados y evitar anunciar EDNS enormes que conviertan “grande” en “fragmentado.”

7) ¿Por qué falla solo en un operador o en un país?

Porque los middleboxes difieren. Las políticas de manejo de fragmentos difieren. Las MTU difieren. Incluso la gestión de congestión difiere.
Los problemas de fragmentación DNS dependen de la ruta por naturaleza; la variabilidad es una característica del modo de fallo.

8) ¿DoH/DoT es una solución para la fragmentación EDNS0?

Para los clientes, DNS cifrado a un recursivo puede ayudar porque viaja sobre TCP (o QUIC) y evita fragmentos UDP en la pierna cliente→recursivo.
No arregla automáticamente el comportamiento recursivo→autoritativo; aún necesitas un dimensionamiento conservador de EDNS y alcanzabilidad TCP upstream.

9) ¿Cómo sé si mi firewall está descartando fragmentos?

Busca reglas explícitas de descarte de fragmentos (iptables “-f”), inspecciona contadores y captura tráfico. Si respuestas UDP grandes se correlacionan con timeouts,
asume que el manejo de fragmentos está implicado hasta que lo descartes.

10) ¿Sobre qué debo alertar para detectar esto temprano?

Vigila cambios en la tasa de fallback TCP, tasas de SERVFAIL para resolvers validadores, tasas de timeout UDP y percentiles de latencia de consultas.
Combínalo con telemetría de cliente por tipo de red (Wi‑Fi vs celular) si tienes una app.

Conclusión: siguientes pasos que detienen la hemorragia

Los problemas de fragmentación EDNS0 son el tipo de outage que no ves desde la sala de servidores. Los servidores responden. Los gráficos parecen educados.
Los usuarios aún no pueden iniciar sesión porque un fragmento de dos no atravesó el laberinto de un carrier.

Qué hacer, en orden:

1. Demostrarlo rápido con dig: compara +bufsize=4096 vs +bufsize=1232 vs +tcp en Wi‑Fi y LTE.
2. Hacer UDP más pequeño: ajustar tamaños EDNS en recursivos de forma conservadora.
3. Hacer TCP aburrido y fiable: permitirlo, escalarlo y monitorizarlo.
4. Recortar el bloat DNS: tratar la proliferación de TXT y RRsets sobredimensionados como deuda con interés.
5. Añadir una prueba de regresión para tamaños de respuesta, especialmente cuando DNSSEC está involucrado.

Haz eso, y “funciona en Wi‑Fi, falla en LTE” volverá a ser un meme en lugar de un pager.