Hacker News new | past | comments | ask | show | jobs | submit login
DNS: A look back at a look back (apnic.net)
66 points by okket 7 months ago | hide | past | web | favorite | 15 comments

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?

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/

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

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.

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.

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

Oh yes, I was so pissed off when I saw that for the first time. At home I run my own resolver, so this does not affect me, but I still cannot understand how somebody could think this was a good idea...

Paywalls rarely use DNS hijacking because it risks putting a bad entry in the clients cache and breaking them. They just intercept http (and sometimes HTTPS) connections to inject a temporary HTTP redirect to an auth page.

Eh you're right, thank you - I meant routers that hijack DNS to send you to a captive portal or splash page.

> 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.

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.

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

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.

Personally, I'm excited for DNS-over-QUIC, which should be a best of both worlds.

DNS-over-QUIC is a plausible alternative to DNSCurve, but you're still looking at a fallback to TCP TLS when you encounter a middlebox which is interfering with all the UDP traffic it doesn't outright block.

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?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact