DNSSEC has some risks, but they are not directly related to reflection or amplification. The EDNS0 message size expansion is a red herring in this case. Let me explain.
Any exchange of packets that does not depend on a previous proof of identity is subject to abuse by DDoS attackers who can use that unauthenticated packet exchange as a reflector, and perhaps also as an amplifier. For example, ICMP (the protocol behind “ping”) can be abused in this way. As can the TCP SYN packet, which solicits up to 40 SYN-ACK packets even if the SYN was spoofed to come from some victim who doesn’t want those SYN-ACK packets. And of course, all UDP services are vulnerable to this attack, including NTP, SSDP, uPNP, and as noted by other responses here, also including DNS.
Most intrusion detection, intrusion prevention, and load balancer appliances are bottlenecks, unable to keep up with “line rate” traffic. Also many routers can’t run at line rate, and some switches. These bottlenecks, by being the smallest thing “in the path”, and smaller than the links themselves, are the actual target of congestion-based DDoS attacks. If you can keep somebody’s firewall busy with attack traffic, then good traffic won’t get through, even if the links aren’t full. And what slows down a firewall isn’t the total number of bits per second (which can be increased by using larger messages, and EDNS0 and DNSSEC will do), but rather the total number of packets per second.
There’s a lot of urban legend out there about how DNSSEC makes DDoS worse because of DNSSEC’s larger message size, and while this makes intuitive sense and “sounds good”, it is simply false. But if there were a shred of truth to this legend, the real answer would still lay elsewhere– [because DNSSEC always uses EDNS0, but EDNS0 can be used without DNSSEC], and many normal non-DNSSEC responses are as large as a DNSSEC response would be. Consider the TXT records used to represent SPF policies or DKIM keys. Or just any large set of address or MX records. In short, no attack requires DNSSEC, and thus any focus on DNSSEC as a DDoS risk is misspent energy.
DNSSEC does have risks! It’s hard to use, and harder to use correctly. Often it requires a new work flow for zone data changes, registrar management, installation of new server instances. All of that has to be tested and documented, and whenever something breaks that’s related to DNS, the DNSSEC technology must be investigated as a possible cause. And the end result if you do everything right will be that, as a zone signer, your own online content and systems will be more fragile to your customers. As a far-end server operator, the result will be, that everyone else’s content and systems will be more fragile to you. These risks are often seen to outweigh the benefits, since the only benefit is to protect DNS data from in-flight modification or substitution. That attack is so rare as to not be worth all this effort. We all hope DNSSEC becomes ubiquitous some day, because of the new applications it will enable. But the truth is that today, DNSSEC is all cost, no benefit, and with high risks.
So if you don’t want to use DNSSEC, that’s your prerogative, but don’t let anyone confuse you that DNSSEC’s problem is its role as a DDoS amplifier. DNSSEC has no necessary role as a DDoS amplifier; there are other cheaper better ways to use DNS as a DDoS amplifier. If you don’t want to use DNSSEC, let it be because you have not yet drunk the Kool Aid and you want to be a last-mover (later) not a first-mover (now).
DNS content servers, sometimes called “authority servers”, must be prevented from being abused as DNS reflecting amplifiers, because DNS uses UDP, and because UDP is abusable by spoofed-source packets. The way to secure your DNS content server against this kind of abuse is not to block UDP, nor to force TCP (using the TC=1 trick), nor to block the ANY query, nor to opt out of DNSSEC. None of those things will help you. You need DNS Response Rate Limiting (DNS RRL), a completely free technology which is now present in several open source name servers including BIND, Knot, and NSD. You can’t fix the DNS reflection problem with your firewall, because only a content-aware middlebox such as the DNS server itself (with RRL added) knows enough about the request to be able to accurately guess what’s an attack and what’s not. I want to emphasize, again: DNS RRL is free, and every authority server should run it.
In closing, I want to expose my biases. I wrote most of BIND8, I invented EDNS0, and I co-invented DNS RRL. I’ve been working on DNS since 1988 as a 20-something, and I am now grumpy 50-something, with less and less patience for half-baked solutions to misunderstood problems. Please accept my apologies if this message sounds too much like “hey you kids, get offa my lawn!”