It's sort of pathetic that our answer to trying to stop DDoS amplification attacks is to cripple public UDP services. It shouldn't be acceptable for an ISP to originate spoofed packets. There is absolutely no excuse for it, yet we continue to accept it as some kind of inevitability and treat symptom after symptom of the same root cause.
It is kind of epic how DJB predicted this.<p>"Domains with DNSSEC, because of the size of some responses, are usually ripe for this type of abuse, and many DNS providers struggle to combat DNSSEC-based DDoS attacks. Just last month, Akamai published a report on attacks using DNS lookups against their DNSSEC-signed .gov domains to DDoS other domains. They say they have seen 400 of these attacks since November."<p><a href="https://cr.yp.to/djbdns/forgery.html" rel="nofollow">https://cr.yp.to/djbdns/forgery.html</a>
<i>By implementing ECDSA natively in assembler, he was able to speed up signing by 21x.</i><p>Let's hope it is resistant to side-channel attacks[0] ;)<p>[0] <a href="https://news.ycombinator.com/item?id=11223266" rel="nofollow">https://news.ycombinator.com/item?id=11223266</a>
Resolvers obviously can't generate signatures for synthesized responses to ANY queries.<p>So when the DO bit was set, the draft suggests returning unsigned records, because the initiator can then explicitly ask for HINFO and get a signed response.<p>However, resolvers just return SERVFAIL if the response doesn't validate. Will Qmail retry with more specific records after a SERVFAIL response code?
While ECDSA size is nice comparatively, the screenshot is a little misleading if strictly comparing algo sizes. It's not showing cloudflare's ksk, and cloudflare doesn't sign its own KSK (though there's no reason to really, but the other domain appears to).
It seems like one solution might be to simply not send more data from the DNS server than it has received from the IP it is sending to. You could still spoof an IP and bounce traffic, but then you couldn't amplify it.