¿Qué es DNS Amplification? Cómo funciona el ataque de reflexión DNS

En marzo de 2013, un ataque contra Spamhaus generó aproximadamente 300 Gbps de tráfico — un récord en su momento — utilizando servidores DNS públicos como amplificadores. El atacante envió pequeñas queries DNS con la IP de la víctima falsificada como origen, y servidores de todo el mundo entregaron respuestas amplificadas directamente a Spamhaus. Este es el principio del DNS Amplification.

Un ataque de Amplificación DNS (DNS Amplification Attack) es un ataque DDoS de reflexión que abusa del protocolo DNS, normalmente transportado por UDP, para generar tráfico volumétrico contra una víctima. Aunque el protocolo explotado pertenece a la capa de aplicación, el impacto predominante suele recaer sobre el ancho de banda, los paquetes por segundo y la capacidad de red en las capas inferiores. El ataque usa IP spoofing para dirigir respuestas de terceros hacia el objetivo.

DNS Amplification vs. DNS Flood — diferencia conceptual

Antes de profundizar en el mecanismo, es útil diferenciar dos ataques que frecuentemente se confunden:

EDNS(0) (RFC 6891) — cómo habilita respuestas más grandes

La especificación original del protocolo DNS (RFC 1035) limita el tamaño máximo de mensajes UDP a 512 bytes. EDNS(0) (Extension Mechanisms for DNS, RFC 6891) introdujo un mecanismo de extensión que permite al cliente anunciar un tamaño máximo de payload UDP mayor, a través de un registro OPT pseudotype en la sección adicional de la query.

El tamaño efectivamente usado depende del valor anunciado por el cliente, la configuración del servidor, el camino de red y las políticas para evitar fragmentación. Aunque valores mayores, como 4.096 bytes, han sido comunes en algunas configuraciones, muchos operadores adoptan límites menores — frecuentemente alrededor de 1.232 bytes — para reducir problemas de fragmentación.

EDNS(0) puede aumentar significativamente el potencial de amplificación al permitir respuestas UDP mayores que 512 bytes. Sin embargo, la reflexión DNS no depende exclusivamente de EDNS(0): consultas menores aún pueden provocar respuestas mayores, y el factor efectivo depende del tipo de consulta, de la zona, de la configuración del servidor, del uso de DNSSEC y de las políticas de tamaño de respuesta.

Migrar a TCP podría limitar el vector, ya que el three-way handshake TCP hace que el IP spoofing sea mucho más difícil de ejecutar con éxito: el servidor enviaría el SYN-ACK a la IP falsificada de la víctima, que nunca completaría el handshake. EDNS(0) mantiene el vector de amplificación operacional sobre UDP al permitir respuestas mayores sin requerir conexión.

Cómo funciona la reflexión y amplificación DNS

El ataque combina IP spoofing con la asimetría de tamaño entre query y respuesta sobre UDP. El mecanismo ocurre en etapas encadenadas:

En la primera etapa, el atacante envía queries DNS con la IP de origen falsificada — sustituyendo su propia dirección por la dirección de la víctima. La query es pequeña y puede declarar soporte a EDNS(0) con un tamaño de payload elevado. El tipo de registro elegido es aquel que tiende a generar una respuesta mayor.

En la segunda etapa, el servidor DNS responde a la dirección IP de origen presente en el datagrama UDP. Como UDP no requiere handshake y la dirección de origen puede haber sido falsificada, la respuesta se envía a la víctima indicada por el atacante.

En la tercera etapa, la víctima recibe respuestas que nunca solicitó. Cuando el atacante usa múltiples servidores DNS en paralelo, las respuestas convergen simultáneamente hacia la víctima, generando tráfico volumétrico que puede presionar su capacidad de red.

Potencial de amplificación por tipo de consulta

El factor de amplificación varía considerablemente con el tipo de consulta, el servidor, la zona, el uso de DNSSEC, las configuraciones de respuesta, los límites UDP y el camino de red. Las descripciones siguientes son cualitativas, no universales.

RFC 8482 — respuestas mínimas para queries ANY

Históricamente, las queries del tipo ANY eran un vector relevante de amplificación DNS porque podían devolver múltiples conjuntos de registros asociados al nombre consultado, generando respuestas mayores. La RFC 8482, publicada en 2019, define respuestas mínimas para consultas DNS del tipo ANY, reduciendo la práctica histórica de responder con todos los RRsets disponibles para el nombre consultado. Una implementación puede responder con un registro HINFO sintetizado u otro conjunto mínimo de datos, según la política adoptada.

Este comportamiento reduce el potencial de amplificación asociado a consultas ANY en implementaciones que lo adoptan. No elimina otros tipos de consultas o fuentes de respuestas DNS grandes, como consultas a registros DNSSEC, DNSKEY o TXT, dependiendo de la configuración y la zona consultada. La adopción no es universal y el comportamiento efectivo depende de la implementación y la política del operador.

Open resolvers y servidores autoritativos como reflectores

Un open resolver DNS es un servidor DNS configurado para responder queries recursivas de cualquier dirección IP en internet — no solo de clientes autorizados. Esta configuración lo convierte en un amplificador potencial para DNS Amplification.

Históricamente, los open resolvers fueron una fuente importante de amplificación porque aceptan consultas recursivas de cualquier origen. Sin embargo, los servidores autoritativos públicamente accesibles también pueden usarse como reflectores cuando responden a consultas con IP de origen falsificada. La exposición y las medidas de defensa varían entre servicios recursivos y autoritativos.

La cantidad de resolvers expuestos y permisivos varía a lo largo del tiempo y depende de la metodología de medición. Proyectos de escaneo y operadores DNS identifican continuamente servidores recursivos abiertos en internet, pero los números globales deben presentarse solo con fuente, fecha y metodología verificables.

Variaciones: otros protocolos UDP usados en reflexión

DNS Amplification es el caso más documentado, pero el principio de reflexión y amplificación sobre UDP se aplica a otros protocolos:

NTP Amplification: explota el protocolo NTP. El comando monlist (asociado a servidores legados o mal configurados) históricamente devolvía grandes listas de clientes como respuesta a una solicitud pequeña. Menos prevalente hoy porque los servidores NTP modernos y actualizados generalmente deshabilitan este comportamiento por defecto.

SSDP Amplification: usa el protocolo UPnP/SSDP presente en dispositivos IoT. Los dispositivos que exponen SSDP en internet pueden ser abusados como reflectores. El vector persiste por el gran número de dispositivos IoT innecesariamente expuestos.

CLDAP Amplification: usa el protocolo CLDAP (Connectionless LDAP). Los servidores LDAP expuestos pueden ser abusados como reflectores. Menos documentado pero posible en redes con servidores LDAP accesibles públicamente.

Técnicas de mitigación

BCP 38 — filtrado de IP spoofing en el origen

El RFC 2827 (BCP 38) orienta a los ISPs a filtrar paquetes con direcciones de origen inválidas o imposibles que salen de sus redes. Si un cliente envía un paquete con una IP de origen que no pertenece al bloque IP asignado a él, el ISP puede descartar ese paquete antes de reenviarlo a internet.

La adopción amplia y correcta del filtrado de origen reduciría drásticamente los ataques de reflexión que dependen del IP spoofing en la internet pública. No elimina los ataques DDoS realizados por botnets con IPs reales ni sustituye otras capas de defensa.

La adopción del filtrado de origen sigue siendo incompleta y desigual entre redes. Proyectos como el CAIDA Spoofer Project proporcionan evidencia de que el IP spoofing aún es posible desde parte de internet, pero sus resultados deben interpretarse según la cobertura y la metodología de medición — no generalizarse como porcentajes globales definitivos.

Response Rate Limiting (RRL) en servidores DNS

El RRL limita la emisión de respuestas DNS repetitivas o similares según criterios definidos por la implementación y la política del operador. Es especialmente útil en servidores autoritativos para reducir el potencial de abuso en reflexión y amplificación.

RRL no sustituye la desactivación de la recursión abierta, el filtrado anti-spoofing ni el dimensionamiento de la infraestructura. Sus parámetros deben probarse para evitar impacto en clientes legítimos y en escenarios de alta demanda real.

Desactivar la recursión abierta en resolvers

Los resolvers DNS deben configurarse para responder solo a clientes autorizados mediante ACLs basadas en IP. Un ejemplo de configuración en BIND para restringir la recursión:

options {
    allow-recursion { trusted-clients; };
    allow-query-cache { trusted-clients; };
};

Este ejemplo presupone que la ACL trusted-clients ya está definida y que el servidor está destinado solo a la resolución para redes autorizadas. Antes de aplicar cambios en producción, valida la configuración según la versión de BIND en uso, la separación entre servicios recursivos y autoritativos y las necesidades de los clientes legítimos. Los resolvers públicos legítimos tienen un modelo operacional diferente y no deben aplicar simplemente esta restricción sin la planificación adecuada.

Anycast para distribución del tráfico

Con Anycast, el mismo prefijo IP se anuncia via BGP desde múltiples puntos de presencia. Las políticas BGP pueden dirigir diferentes fuentes a puntos distintos, ayudando a distribuir el tráfico y acercar la mitigación a parte de los orígenes.

La distribución real no es necesariamente uniforme ni basada únicamente en proximidad geográfica: depende de políticas de enrutamiento, peering, capacidad y topología. Por ello, Anycast debe combinarse con capacidad adecuada, telemetría y mecanismos de mitigación en cada punto de presencia.

Scrubbing centers y filtrado upstream

Los scrubbing centers son infraestructuras especializadas en inspección y filtrado de tráfico volumétrico. En partes de la red que observan tanto consultas como respuestas, los controles pueden correlacionar las respuestas DNS recibidas con consultas previamente observadas y reducir el tráfico no solicitado.

Esta correlación depende de la visibilidad bidireccional, asimetría de ruta, NATs, arquitectura de resolución DNS y políticas de timeout. El puerto UDP 53 de forma aislada no es evidencia suficiente de un ataque — también transporta tráfico DNS legítimo.

Detección con NetFlow, sFlow y telemetría de red

La detección de DNS Amplification requiere análisis de telemetría de red. NetFlow y sFlow normalmente proporcionan metadatos de flujo — direcciones, puertos, volumen, PPS, duración — pero no contenido de payload DNS. Para identificar EDNS(0), QTYPE, registros OPT o contenido DNS específico, se necesita DPI, captura de paquetes, sensor DNS o telemetría de appliance especializado.

En redes con visibilidad bidireccional de queries y respuestas UDP/53, el tráfico DNS legítimo tiende a mostrar correlación temporal entre queries enviadas y respuestas recibidas. La proporción no es necesariamente 1:1, ya que la caché, las retransmisiones, los timeouts, DNSSEC, NATs, múltiples resolvers y otros factores pueden alterar el patrón. La señal más indicativa de amplificación es alto volumen de respuestas UDP con puerto de origen 53 sin queries salientes correspondientes visibles.

Señales operativas de detección

Errores comunes y orientaciones

Bloquear todo el tráfico UDP entrante en el puerto 53: esto también bloquea respuestas DNS legítimas de resolvers externos. Usa controles que correlacionen respuestas a queries enviadas por la red para distinguir tráfico solicitado de respuestas no solicitadas reflejadas.

Depender solo de blackhole routing para mitigar el ataque: el blackhole routing descarta todo el tráfico hacia la IP de la víctima, incluyendo el legítimo — completando el objetivo del atacante. Usa scrubbing selectivo cuando sea posible.

No configurar RRL en el propio servidor DNS autoritativo: aunque no sea un open resolver, un servidor DNS autoritativo puede usarse en ataques de reflexión si acepta queries de cualquier fuente. RRL puede limitar el volumen de respuestas similares enviadas a destinos individuales, pero requiere ajuste para no afectar a clientes legítimos.

Ignorar los dispositivos IoT como posibles amplificadores SSDP: segmenta los dispositivos IoT en VLANs aisladas y evalúa bloquear el tráfico SSDP de salida hacia internet. Los dispositivos con UPnP activado y expuestos pueden ser reclutados como amplificadores.

Preguntas frecuentes

¿Por qué se usa UDP en lugar de TCP en DNS Amplification? UDP no requiere un handshake, por lo que el atacante puede enviar queries con IP falsificada sin establecer una conexión real. EDNS(0) permite respuestas UDP mayores que 512 bytes, aumentando la asimetría disponible. Con TCP, el three-way handshake haría que el IP spoofing fuera mucho más difícil: el servidor enviaría el SYN-ACK a la IP de la víctima, que nunca completaría el handshake, y el atacante no recibiría la respuesta amplificada.

¿Cuál es el papel del EDNS(0) en el ataque? EDNS(0) puede aumentar el potencial de amplificación al permitir respuestas UDP mayores que 512 bytes. El factor real depende de la consulta, el servidor, el tamaño anunciado, DNSSEC, la configuración de respuesta y el camino de red. La reflexión DNS existía antes de EDNS(0) — consultas menores aún pueden provocar respuestas mayores en determinados escenarios.

¿La RFC 8482 elimina completamente el vector de queries ANY? En implementaciones que aplican respuestas mínimas a consultas ANY, la utilidad de ese tipo de consulta como vector de amplificación se reduce significativamente. Esto no elimina otros tipos de consultas o fuentes de respuestas DNS grandes. El comportamiento efectivo depende de la implementación y la política del operador.

¿El DNS Amplification solo afecta a los open resolvers? No. Los servidores autoritativos públicamente accesibles también pueden usarse como reflectores cuando responden a consultas con IP de origen falsificada. El objetivo final del ataque es la víctima cuyo enlace se satura — los servidores DNS se usan como intermediarios, no como objetivos.

¿BCP 38 resuelve completamente el problema? La adopción amplia y correcta del filtrado de origen reduciría drásticamente los ataques de reflexión que dependen del IP spoofing en internet. No elimina los ataques DDoS realizados por botnets con IPs reales ni sustituye otras capas de defensa. La adopción sigue siendo incompleta y desigual, lo que mantiene el vector operacional y hace necesarias medidas complementarias como RRL, Anycast y scrubbing.

¿Cómo se distingue un pico de tráfico DNS legítimo de un ataque reflejado? La distinción se hace por el patrón de flujo. En redes con visibilidad bidireccional, el tráfico DNS legítimo tiende a mostrar correlación entre queries enviadas y respuestas recibidas. Un ataque reflejado genera alto volumen de respuestas entrantes sin queries salientes correspondientes — patrón identificable en datos NetFlow/sFlow como puerto de origen 53 sin puerto de destino 53 correspondiente. La confirmación del vector (EDNS(0), QTYPE, tamaño real) requiere captura de paquetes o DPI.

Cómo implementar en Azion

Azion puede componer una estrategia de mitigación contra ataques de reflexión y amplificación DNS, conforme a los productos contratados, los protocolos publicados y las políticas configuradas.

1. Controles de red distribuidos: una arquitectura distribuida puede ayudar a absorber y filtrar tráfico UDP anómalo antes de que alcance el origen. El comportamiento efectivo depende de la topología, la capacidad, las rutas y las políticas aplicadas.

2. Mitigación de tráfico volumétrico: los recursos de protección DDoS y las políticas de red pueden ayudar a detectar aumentos de PPS y banda asociados a ataques de reflexión, aplicando controles según el perfil de tráfico observado.

3. Protección de servicios DNS: para los servicios DNS publicados, los controles de configuración, la limitación de respuestas y las políticas de acceso pueden reducir el riesgo de que resolvers o servidores autoritativos sean abusados como reflectores, según los recursos habilitados.

4. Observabilidad: logs, métricas y telemetría de red pueden ayudar a identificar tráfico UDP anómalo, cambios de volumen, distribución de orígenes y presión sobre los enlaces durante un incidente.

La cobertura efectiva depende de la arquitectura DNS, los servicios publicados, los productos habilitados, las políticas configuradas y el perfil del ataque.

Aprende más en la documentación de DDoS Protection de Azion.