DNSSEC tiene algunos riesgos, pero no están directamente relacionados con la reflexión o la amplificación. La expansión del tamaño del mensaje EDNS0 es una pista falsa en este caso. Dejame explicar.
Cualquier intercambio de paquetes que no dependa de una prueba de identidad previa está sujeto a abuso por parte de los atacantes DDoS que pueden usar ese intercambio de paquetes no autenticado como reflector, y quizás también como amplificador. Por ejemplo, se puede abusar de ICMP (el protocolo detrás de "ping") de esta manera. Al igual que el paquete TCP SYN, que solicita hasta 40 paquetes SYN-ACK incluso si el SYN fue falsificado para provenir de alguna víctima que no quiere esos paquetes SYN-ACK. Y, por supuesto, todos los servicios UDP son vulnerables a este ataque, incluidos NTP, SSDP, uPNP y, como se señala en otras respuestas aquí, también incluyen DNS.
La mayoría de los dispositivos de detección de intrusiones, prevención de intrusiones y balanceador de carga son cuellos de botella, incapaces de mantenerse al día con el tráfico de "velocidad de línea". Además, muchos enrutadores no pueden funcionar a velocidad de línea y algunos conmutadores. Estos cuellos de botella, al ser la cosa más pequeña "en el camino", y más pequeños que los enlaces en sí, son el objetivo real de los ataques DDoS basados en la congestión. Si puede mantener el firewall de alguien ocupado con el tráfico de ataque, entonces el buen tráfico no pasará, incluso si los enlaces no están llenos. Y lo que ralentiza un cortafuegos no es el número total de bits por segundo (que puede aumentarse usando mensajes más grandes, y EDNS0 y DNSSEC lo harán), sino el número total de paquetes por segundo.
Hay mucha leyenda urbana sobre cómo DNSSEC empeora DDoS debido al mayor tamaño de mensaje de DNSSEC, y aunque esto tiene un sentido intuitivo y "suena bien", es simplemente falso. Pero si hubiera una pizca de verdad en esta leyenda, la respuesta real aún estaría en otra parte: [porque DNSSEC siempre usa EDNS0, pero EDNS0 se puede usar sin DNSSEC], y muchas respuestas normales que no son DNSSEC son tan grandes como un DNSSEC la respuesta sería Considere los registros TXT utilizados para representar políticas SPF o claves DKIM. O simplemente cualquier conjunto grande de direcciones o registros MX. En resumen, ningún ataque requiere DNSSEC y, por lo tanto, cualquier enfoque en DNSSEC como riesgo DDoS es energía mal utilizada.
¡DNSSEC tiene riesgos! Es difícil de usar y más difícil de usar correctamente. A menudo requiere un nuevo flujo de trabajo para cambios de datos de zona, gestión de registradores, instalación de nuevas instancias de servidor. Todo eso tiene que ser probado y documentado, y cada vez que algo se rompe relacionado con DNS, la tecnología DNSSEC debe investigarse como una posible causa. Y el resultado final si hace todo bien será que, como firmante de zona, su propio contenido y sistemas en línea serán más frágiles para sus clientes. Como operador de servidor remoto, el resultado será que el contenido y los sistemas de todos los demás serán más frágiles para usted. A menudo se considera que estos riesgos superan los beneficios, ya que el único beneficio es proteger los datos DNS de la modificación o sustitución en vuelo. Ese ataque es tan raro que no vale la pena todo este esfuerzo. Todos esperamos que DNSSEC se vuelva omnipresente algún día, debido a las nuevas aplicaciones que habilitará. Pero la verdad es que hoy, DNSSEC es todo costo, sin beneficios y con altos riesgos.
Entonces, si no desea usar DNSSEC, esa es su prerrogativa, pero no permita que nadie lo confunda con el problema de DNSSEC como su función como amplificador DDoS. DNSSEC no tiene la función necesaria como amplificador DDoS; Hay otras formas mejores y más baratas de utilizar DNS como amplificador DDoS. Si no desea utilizar DNSSEC, hágalo porque aún no ha bebido el Kool Aid y quiere ser el último en mover (más tarde) no el primero (ahora).
Se debe evitar que los servidores de contenido DNS, a veces llamados "servidores de autoridad", sean abusados como amplificadores reflectores de DNS, porque DNS usa UDP y porque UDP es abusable por paquetes de fuente falsificada. La forma de proteger su servidor de contenido DNS contra este tipo de abuso no es bloquear UDP, ni forzar TCP (usando el truco TC = 1), ni bloquear CUALQUIER consulta, ni optar por no recibir DNSSEC. Ninguna de esas cosas te ayudará. Necesita limitar la tasa de respuesta de DNS(DNS RRL), una tecnología completamente gratuita que ahora está presente en varios servidores de nombres de código abierto, incluidos BIND, Knot y NSD. No puede solucionar el problema de reflexión de DNS con su firewall, porque solo un middlebox con contenido como el servidor DNS en sí (con RRL agregado) sabe lo suficiente sobre la solicitud para poder adivinar con precisión qué es un ataque y qué no. Quiero enfatizar, nuevamente: DNS RRL es gratuito, y todos los servidores de autoridad deberían ejecutarlo.
Para terminar, quiero exponer mis prejuicios. Escribí la mayor parte de BIND8, inventé EDNS0 y co-inventé DNS RRL. He estado trabajando en DNS desde 1988 con 20 y tantos años, y ahora tengo 50 y tantos gruñones, con cada vez menos paciencia para encontrar soluciones a medias a problemas incomprendidos. Por favor acepte mis disculpas si este mensaje suena demasiado como "¡Hola chicos, salgan de mi césped!"