DNSSEC comporte certains risques, mais ils ne sont pas directement liés à la réflexion ou à l'amplification. L'extension de la taille du message EDNS0 est un hareng rouge dans ce cas. Laissez-moi expliquer.
Tout échange de paquets qui ne dépend pas d'une preuve d'identité antérieure est soumis à des abus par des attaquants DDoS qui peuvent utiliser cet échange de paquets non authentifié comme réflecteur, et peut-être aussi comme amplificateur. Par exemple, ICMP (le protocole derrière "ping") peut être abusé de cette manière. Tout comme le paquet TCP SYN, qui sollicite jusqu'à 40 paquets SYN-ACK même si le SYN a été usurpé pour provenir d'une victime qui ne veut pas de ces paquets SYN-ACK. Et bien sûr, tous les services UDP sont vulnérables à cette attaque, y compris NTP, SSDP, uPNP, et comme indiqué par d'autres réponses ici, y compris DNS.
La plupart des appliances de détection d'intrusion, de prévention des intrusions et d'équilibreur de charge sont des goulots d'étranglement, incapables de suivre le trafic de "débit de ligne". De nombreux routeurs ne peuvent pas non plus fonctionner au débit de ligne et certains commutateurs. Ces goulots d'étranglement, en étant la plus petite chose "sur le chemin", et plus petits que les liens eux-mêmes, sont la cible réelle des attaques DDoS basées sur la congestion. Si vous pouvez garder le pare-feu de quelqu'un occupé par le trafic d'attaque, un bon trafic ne passera pas, même si les liens ne sont pas pleins. Et ce qui ralentit un pare-feu n'est pas le nombre total de bits par seconde (qui peut être augmenté en utilisant des messages plus gros, et EDNS0 et DNSSEC feront l'affaire), mais plutôt le nombre total de paquets par seconde.
Il y a beaucoup de légendes urbaines sur la façon dont DNSSEC aggrave les DDoS en raison de la plus grande taille des messages de DNSSEC, et bien que cela ait un sens intuitif et "sonne bien", c'est tout simplement faux. Mais s'il y avait un brin de vérité dans cette légende, la vraie réponse serait encore ailleurs - [parce que DNSSEC utilise toujours EDNS0, mais EDNS0 peut être utilisé sans DNSSEC], et de nombreuses réponses normales non DNSSEC sont aussi grandes qu'un DNSSEC réponse serait. Considérez les enregistrements TXT utilisés pour représenter les stratégies SPF ou les clés DKIM. Ou tout grand ensemble d'adresses ou d'enregistrements MX. En bref, aucune attaque ne nécessite DNSSEC, et donc toute focalisation sur DNSSEC en tant que risque DDoS est une énergie mal dépensée.
DNSSEC comporte des risques! Il est difficile à utiliser et plus difficile à utiliser correctement. Souvent, cela nécessite un nouveau flux de travail pour les modifications des données de zone, la gestion du bureau d'enregistrement, l'installation de nouvelles instances de serveur. Tout cela doit être testé et documenté, et chaque fois que quelque chose de cassé est lié au DNS, la technologie DNSSEC doit être étudiée comme une cause possible. Et si vous faites tout correctement, le résultat final sera qu'en tant que signataire de zone, vos propres contenus et systèmes en ligne seront plus fragiles pour vos clients. En tant qu'opérateur de serveur distant, le résultat sera que le contenu et les systèmes de tous les autres vous seront plus fragiles. Ces risques sont souvent considérés comme supérieurs aux avantages, car le seul avantage est de protéger les données DNS contre la modification ou la substitution en vol. Cette attaque est si rare qu'elle ne vaut pas tous ces efforts. Nous espérons tous que DNSSEC deviendra omniprésent un jour, en raison des nouvelles applications qu'il permettra. Mais la vérité est qu'aujourd'hui, DNSSEC est tout coût, aucun avantage, et avec des risques élevés.
Donc, si vous ne voulez pas utiliser DNSSEC, c'est votre prérogative, mais ne laissez personne vous confondre que le problème de DNSSEC est son rôle d'amplificateur DDoS. DNSSEC n'a aucun rôle nécessaire en tant qu'amplificateur DDoS; il existe d'autres façons moins chères d'utiliser DNS comme amplificateur DDoS. Si vous ne voulez pas utiliser DNSSEC, que ce soit parce que vous n'avez pas encore bu le Kool Aid et que vous voulez être un dernier (plus tard) pas un premier (maintenant).
Les serveurs de contenu DNS, parfois appelés «serveurs d'autorité», doivent être empêchés d'être utilisés comme amplificateurs réfléchissant DNS, car DNS utilise UDP et parce que UDP est exploitable par des paquets de source falsifiée. Le moyen de sécuriser votre serveur de contenu DNS contre ce type d'abus n'est pas de bloquer UDP, ni de forcer TCP (en utilisant l'astuce TC = 1), ni de bloquer la requête ANY, ni de désactiver DNSSEC. Aucune de ces choses ne vous aidera. Vous avez besoin d'une limitation du taux de réponse DNS(DNS RRL), une technologie entièrement gratuite qui est maintenant présente dans plusieurs serveurs de noms open source, notamment BIND, Knot et NSD. Vous ne pouvez pas résoudre le problème de réflexion DNS avec votre pare-feu, car seul un boîtier de médiation sensible au contenu tel que le serveur DNS lui-même (avec RRL ajouté) en sait suffisamment sur la demande pour pouvoir deviner avec précision ce qui est une attaque et ce qui ne l'est pas. Je tiens à souligner, encore une fois: DNS RRL est gratuit, et chaque serveur d'autorité doit l'exécuter.
En terminant, je veux exposer mes préjugés. J'ai écrit la plupart de BIND8, j'ai inventé EDNS0 et j'ai co-inventé DNS RRL. Je travaille sur DNS depuis 1988 en tant que 20-quelque chose, et je suis maintenant grincheux 50-quelque chose, avec de moins en moins de patience pour des solutions à moitié cuites à des problèmes mal compris. Veuillez accepter mes excuses si ce message ressemble trop à "hé les enfants, descendez de ma pelouse!"