It would be a stupid solution if DNSSEC had some vital role to play in Internet security. But it clearly doesn't, as evidenced by the fact that virtually all high-volume commercial transactions conducted in the industrialized world in 2012 hit the Internet, and none of it is protected by DNSSEC.

If I had to draw a pie chart explaining the rationale behind deploying DNSSEC, a 1/3 slice of that pie would be labeled "IETF's misguided effort to replace the broken TLS CA PKI with yet another PKI controlled largely by the same giant businesses", and the remaining 2/3 slice would be labeled "Self-perpetuating fallacy that DNS must be SEC'd the way IP was (unsuccessfully) SEC'd", or, less charitably, "Windmill tilting exercise on the part of standards bodies".

I don't care about DNSSEC. I just think it's ridiculous to ignore the real flaw, which is that you can bounce DNS packets at anyone you want.

If you want to strip away part of the protocol to fix an attack vector, why not just redact EDNS0? Or do what networks around the world already do and block all port 53 udp packets bigger than 512 bytes. We'll continue to have a size-limited and somewhat inflexible protocol, but at least DNS amplification will have an upper bound.

You can't just wave a magic wand and make it so attackers can't bounce DNS packets, and so it actually does matter than one DNS feature makes those bounced packets much much larger than any other DNS feature.

You can keep DNSSEC and prevent amplification attacks by either limiting the requests to authorized clients or requiring DNSSEC records use only TCP connections. But you don't accept this solution because you hate DNSSEC and you prefer to kill the feature and save the headache.

I get that. Hell, you're probably right that the cost of supporting DNSSEC isn't worth its benefits in the long run. It's still a crappy argument and a crappy way to deal with a long-standing security problem.

If you want to prevent all future UDP DNS amplification attacks you must require all UDP DNS packets be no more than a specific number of bytes (for example, 512, the pre-EDNS0 size). This would fix the root problem forever. All feature extensions can simply require the use of TCP.

I get that there's a large cost involved with every solution except for forcing everyone to abandon DNSSEC. I don't think forcing everyone to abandon DNSSEC is a realistic goal at this point. Instead, I recommend fixing the root problem for all future cases. Everyone can continue to not use DNSSEC, and DNS will never be able to be used in an amplification attack past what was already possible before DNSSEC.

So I mostly agree with this comment (note the thing I said at the top of this thread: not the best argument against DNSSEC). The only thing I disagree with is that "forcing everyone to abandon DNSSEC" is unrealistic. Actually, DNSSEC hasn't been adopted yet. It has seen virtually no uptake in the ~decade since its current incarnation was put forward, and it has not seen a sharp uptake in interest after the "sign the TLDs" hurdle was crossed either. The reality is that lots of security standards put forth by the IETF don't go on to take over the Internet; for instance, your Google Mail connection is protected by SSL/TLS, not IPSEC.