I clearly remember thinking how lucky we were that nobody had so far come along and just picked at the ripe, juicy, low-hanging fruit of problems inherent to the DNS protocol itself. Nevermind the implementation bugs that might want to join the party.
Fast-forward to the present, where still no major breach of the DNS system has garnered enough public attention to warrant a cutesy name. Not DNSBleed, MeltDNS, DNSrown, or PooDNSle.
Did we just get lucky? Given how low-hanging and overly-ripe this particular fruit was (is?), I find that hard to believe. Either the Domain Name System is far more resilient to attacks than it appears at first glance, or attackers have been feeding us the blue pill all along and attacks like DNS Cache-poisoning are commonplace and some magically manage to stay under the radar. Or do they just not bother?
It is slightly consfusing, because DNS (sans DNSSEC, which many clients remain blissfully unaware of) seems to me to be the Striped Biologist-Taunter of network protocols: it is practically begging to be hijacked and exploited the crap out of.
Do criminals just not care, or do they have too much respect for such a low layer of infrastructure?
I work on IPFS/libp2p and the "only" two known attacks on the official gateway ipfs.io are in Spain (DNS hijacking) and China (dito).
OONI has pretty good data on interference around the world: https://ooni.torproject.org/
(edit: clarified that the attack is only on the ipfs.io gateway, not the IPFS network)
UDP is perfect for DNS. The problem is the original protocol design itself. For example, DNSCurve uses UDP and doesn't have these problems.
The only reason people are turning to TLS now is that errant middleboxes have been interfering with all attempts to improve the security of DNS, and using TLS is seen as a way to get the traffic through.
If DNS had been DNSCurve from the beginning then middleboxes breaking it would be seen as a flaw in the middlebox instead of the new protocol, and protocol ossification would be less of a problem because encrypting the data inhibits interference.
But TLS seems obviously worse than defaulting to DNSCurve or similar and falling back to TLS when breakage is detected.
I'm not very familiar with DNSCurve but I don't think it has any mechanisms to prevent amplification.
DNSCrypt solved this by requiring a question to be at least as large as its response.
The DNSCurve page discusses amplification:
The main point is that amplification is primarily a problem because of DNSSEC records causing small requests to generate very large responses, so if people would use DNSCurve instead then even if the responses were somewhat larger than the requests they wouldn't be so by a factor of 120:1 or more, which is the real issue.
But yes, there are multiple ways to solve the problem. CurveCP (a derivative of DNSCurve) does the same thing, requiring the initial packet to be as large as the response. For that matter DNSCrypt is somewhat a derivative of DNSCurve/CurveCP as well.
The point is that it's quite possible to solve the problem and still use UDP.
Or is it still constantly querying from an untraceable source to this day?