O DNSSEC tem alguns riscos, mas eles não estão diretamente relacionados à reflexão ou amplificação. A expansão do tamanho da mensagem EDNS0 é um arenque vermelho neste caso. Deixe-me explicar.
Qualquer troca de pacotes que não dependa de uma prova de identidade anterior está sujeita a abuso por invasores DDoS que podem usar essa troca de pacotes não autenticada como um refletor e, talvez, também como um amplificador. Por exemplo, o ICMP (o protocolo por trás de "ping") pode ser abusado dessa maneira. Assim como o pacote TCP SYN, que solicita até 40 pacotes SYN-ACK, mesmo que o SYN tenha sido falsificado para vir de alguma vítima que não deseja esses pacotes SYN-ACK. E, é claro, todos os serviços UDP são vulneráveis a esse ataque, incluindo NTP, SSDP, uPNP e conforme observado por outras respostas aqui, incluindo também o DNS.
A maioria dos dispositivos de detecção de intrusão, prevenção de intrusão e balanceador de carga são gargalos, incapazes de acompanhar o tráfego de "taxa de linha". Além disso, muitos roteadores não podem funcionar com taxa de linha e alguns comutadores. Esses gargalos, por serem a menor coisa "no caminho" e menores do que os próprios links, são o alvo real dos ataques DDoS baseados em congestionamento. Se você puder manter o firewall de alguém ocupado com o tráfego de ataque, um bom tráfego não passará, mesmo que os links não estejam cheios. E o que reduz a velocidade de um firewall não é o número total de bits por segundo (que pode ser aumentado usando mensagens maiores, e EDNS0 e DNSSEC farão), mas o número total de pacotes por segundo.
Há muitas lendas urbanas por aí sobre como o DNSSEC piora o DDoS por causa do tamanho maior da mensagem do DNSSEC e, embora isso faça sentido intuitivo e "pareça bom", é simplesmente falso. Mas se houvesse um pingo de verdade nessa lenda, a resposta real ainda estaria em outro lugar - [porque o DNSSEC sempre usa EDNS0, mas o EDNS0 pode ser usado sem o DNSSEC] e muitas respostas normais que não são do DNSSEC são tão grandes quanto o DNSSEC resposta seria. Considere os registros TXT usados para representar políticas SPF ou chaves DKIM. Ou apenas qualquer conjunto grande de endereços ou registros MX. Em resumo, nenhum ataque requer DNSSEC e, portanto, qualquer foco no DNSSEC como risco de DDoS é energia gasta.
DNSSEC tem riscos! É difícil de usar e mais difícil de usar corretamente. Freqüentemente, é necessário um novo fluxo de trabalho para alterações nos dados da zona, gerenciamento de registradores e instalação de novas instâncias do servidor. Tudo isso precisa ser testado e documentado, e sempre que ocorrer algo relacionado ao DNS, a tecnologia DNSSEC deve ser investigada como uma possível causa. E o resultado final, se você fizer tudo certo, será que, como signatário da zona, seu próprio conteúdo e sistemas on-line serão mais frágeis para seus clientes. Como operador de servidor remoto, o resultado será que o conteúdo e os sistemas de todos os outros serão mais frágeis para você. Geralmente, esses riscos superam os benefícios, pois o único benefício é proteger os dados do DNS contra modificações ou substituições em andamento. Esse ataque é tão raro que não vale todo esse esforço. Todos esperamos que o DNSSEC se torne onipresente algum dia, devido aos novos aplicativos que ele permitirá. Mas a verdade é que hoje em dia o DNSSEC tem todos os custos, nenhum benefício e riscos altos.
Portanto, se você não quiser usar o DNSSEC, essa é sua prerrogativa, mas não deixe ninguém confundir que o problema do DNSSEC é seu papel como um amplificador DDoS. O DNSSEC não tem um papel necessário como um amplificador DDoS; existem outras maneiras melhores e mais baratas de usar o DNS como um amplificador DDoS. Se você não quiser usar o DNSSEC, é porque ainda não bebeu o Kool Aid e deseja ser o último a mover (depois) e não o primeiro a mover (agora).
Os servidores de conteúdo DNS, às vezes chamados de "servidores de autoridade", devem ser impedidos de serem abusados como amplificadores refletores de DNS, porque o DNS usa UDP e porque o UDP é abusável por pacotes de origem falsificada. A maneira de proteger seu servidor de conteúdo DNS contra esse tipo de abuso não é bloquear o UDP, nem forçar o TCP (usando o truque TC = 1), nem bloquear a QUALQUER consulta, nem optar pelo DNSSEC. Nenhuma dessas coisas irá ajudá-lo. Você precisa limitar a taxa de resposta de DNS(DNS RRL), uma tecnologia totalmente gratuita que agora está presente em vários servidores de nomes de código aberto, incluindo BIND, Knot e NSD. Você não pode corrigir o problema de reflexão de DNS com seu firewall, porque apenas uma caixa intermediária com reconhecimento de conteúdo, como o próprio servidor DNS (com RRL adicionado), conhece o suficiente a solicitação para poder adivinhar com precisão o que é um ataque e o que não é. Quero enfatizar novamente: o DNS RRL é gratuito e todos os servidores de autoridade devem executá-lo.
Para finalizar, quero expor meus preconceitos. Eu escrevi a maior parte do BIND8, inventei o EDNS0 e co-inventei o DNS RRL. Trabalho no DNS desde 1988 com 20 e poucos anos, e agora estou com 50 e poucos anos, com cada vez menos paciência para soluções incompletas para problemas incompreendidos. Aceite minhas desculpas se esta mensagem parecer muito com "ei, crianças, desçam do meu gramado!"