
DNS: A look back at a look back - okket
https://blog.apnic.net/2018/08/09/dns-a-look-back-at-a-look-back/
======
krylon
About 14 years ago, during my training at a large IT company, I had the
pleasure and privilege to lay out a security policy for a migration from BIND4
to BIND9. I was more than flattered that they bestowed such an important task
to a lowly trainee, so I really dug in there, and for about three months I
immersed myself in the finer details of DNS and security and why the two
rarely talk with each other.

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?

~~~
lgierth
DNS hijacking happens all the time, every day - we just don't seem to
unconditionally recognize it as attacks. Paywalls on airport/cafe wifis,
nation-state censorship of individual websites, etc. :)

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/](https://ooni.torproject.org/)

(edit: clarified that the attack is only on the ipfs.io gateway, not the IPFS
network)

~~~
WorldMaker
I changed the root DNS servers in my home router when I found my (American)
ISP was DNS poisoning bing.com (and who knows what else!) for extra ad
revenue.

~~~
lgierth
Your comment just made me remember that T-Online and a few other german ISPs
hijack NXDOMAIN responses and send you to their crappy search pages.

~~~
blattimwind
You can disable that in your customer settings, though. It's still crap, of
course.

------
zrm
> The transport protocol picked for the DNS, the User Datagram Protocol (UDP),
> was the best option at the time, but is fraught with issues, including being
> a major ingredient for DNS-based DDoS events. Only recently has attention
> turned to finding a more suitable transport arrangement.

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.

~~~
jedisct1
UDP indeed fit DNS like a glove, except on links with excessive latency /
packet loss. This is more of an implementation issue than a problem with UDP,
though.

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.

~~~
zrm
> I'm not very familiar with DNSCurve but I don't think it has any mechanisms
> to prevent amplification.

The DNSCurve page discusses amplification:

[https://dnscurve.org/amplification.html](https://dnscurve.org/amplification.html)

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.

------
DrPhish
Did anyone ever solve the mystery of burrbxr1? I can't find any followups in
searching.

Or is it still constantly querying from an untraceable source to this day?

------
based2
[https://kb.isc.org/article/AA-01639/74/CVE-2018-5740%3A-A-
fl...](https://kb.isc.org/article/AA-01639/74/CVE-2018-5740%3A-A-flaw-in-the-
deny-answer-aliases-feature-can-cause-an-INSIST-assertion-failure-in-
named.html)

