Hacker News Reader

Comment by jeroenhd | Hacker News Reader

DoT and DoH are traditionally available over TCP (or reworked versions of TCP like QUIC), which have built in protections against address spoofing.

Opening port 53 means having to set up a system to prevent abuse. Multiplication attacks through DNS are still as common as ever and mitigation can be incredibly difficult if a botnet is attacking a wide range of IP addresses.

Putting everything behind encryption not only makes life just a tad more private (especially when using ODoH, using which your DNS server can't even know what domains your IP is visiting, though I'm not sure if they support that) while also reducing the complexity of the service they're running.

There are downsides for sure, but I think they don't outweigh the benefits.

View on HN

Only the UDP version of DNS is open to amplification attacks. The TCP version of DNS (which has been supported for 30+ years) should work fine, but some shitty firewalls block it, so people have not relied upon it, and as a result it's not very reliable to use TCP DNS everywhere. Rather than deal with the problem and make UDP-based DNS obsolete ("but UDP is faster!" + "but middleboxes!" is the reason nobody wants to deal with it), people are instead pushing DoH, which just shoves DNS over an HTTPS connection.

It's like, if in response to cars on a certain stretch of road hitting bicycles, you know building a protected bike lane is the best solution. But it's expensive, and it may limit parking, or the amount of lanes for cars, or their max speed. So instead you require everyone to put their bicycle in a car, or just bike on the street and risk being hit.

Nobody wants to deal with the real problem, so we instead institute hacks and try to ignore the problem as long as we can. Anything to avoid expense, cooperation, re-building.

you may have a point about amplification attacks, but that's not the main reason DoH/DoT exists. simply using legacy DNS over TCP will not magically make it encrypted.

DNSCrypt mainly uses UDP, doesn't allow amplification, allows client IP anonymization.

IPv6 shows what happens when you deal with the real problem. Nobody adopts the solution!

I'm aware of DNS over TCP (and why nobody uses it, partially because it depends on operating system fallbacks, heuristics, or complicated configuration), but on the other hand: every operating system supports secure DNS by now, why not use it? It solves two problems, the first being the amplification attack risk, the second being the risk of third parties reading, selling, and manipulating the contents of your DNS requests.

DNS over TCP is actually slower in many configurations, at least the ones I've tested. HTTP libraries and servers have been developed for fast opens with (probably protocol violating) workarounds for getting rid of the handshake in any way they can but DNS implementations seem to care very little, especially on the client side. 1-RTT TLS fixes serious connectivity annoyances while also providing security benefits at minimal overhead.

I personally prefer DoT over DoH, but the industry is moving away from DoT. Taking DNS, which is a fine protocol lacking encryption and sessions and adding encryption and settings is a very simple solution. An nginx stream proxy forwarding TLS traffic for port 853 to 53 is enough to set it up if you're not bothered by the handshake time that can be negligible in the age of 5G and fiber connections if you live in the right area.

Sadly, the "let's turn everything into JSON so I don't have to learn what bytes are" crowd won and becoming an old man yelling at the cloud doesn't solve anything. At least ODoH provides some additional benefits that just encrypting DNS doesn't at the cost of extra latency, though I'm disappointed with how its rollout is going.

Personally, I use DNS over UDP to my local PiHole which deals with all the secure DNS lookup protocols. This way only one device needs to maintain connections and deal with session resumption while every other device can rely on the simplicity and speed of UDP connections. Not exactly a defence-in-depth approach but it works well enough for me.

A real solution would be to meaningfully extend DNS in some way but doing so would require backporting this new protocol to at least ten years of computers, tablets, smartphones and IoT devices. I'd welcome a new protocol that fixes these issues if all I'd need is install another app or set up a forwarding service for legacy software, but most of the world wants something that Just Works(TM) and that Windows 7 server in the basement everybody hides when the auditor visits still needs to work.

> Sadly, the "let's turn everything into JSON so I don't have to learn what bytes are" crowd won

DoH uses raw bytes for DNS answers and not json: https://www.rfc-editor.org/rfc/rfc8484#section-6

Luckily DNS over JSON didn't actually take any hold, but for an uncomfortably long time it was one of the major candidates (alongside DNS over XML). Queries are still often base64'd versions of the binary packet though, which is almost as wasteful. The overengineering of a simple protocol and the wrapping in layers of additional complexity to a fraction of developers' lives just a teensy bit better is what makes me associate this tech with the "DNS over JSON" people.

The idea behind it remains the same. HTTP/http2/http3 as a carrying mechanism for an existing binary format makes no sense when none of the benefits of the new format are actually coming from the HTTP protocol. This only increases the attack surface and complexity of the protocol. I don't know, maybe there's a benefit to setting cookies and language headers for DNS requests but I'm not seeing it. The only potential benefit touted in the RFC is that web applications can now do DNS lookups in a standardised way and I don't see how that's a benefit for anyone but user hostile companies.

Now we've reached the situation where HTTP/2 server push has been deprecated in almost all browsers but is still part of the DoH spec. I don't see the benefit of including server push support in the first place but because it's part of the standard we'll have to deal with potential servers relying on features disabled in libraries or unmaintained code in libraries that lays dormant because the major consumers of HTTP have stopped calling their methods.

I thought one of the benefits of DoH over DoT was that in the case where an adversary (e.g. a state with Internet censorship) is trying to block DNS access, it's not distinguishable from a normal HTTPS connection, which you can't block willy-nilly without breaking most of the internet.

Yes.

And pretty much anyone can run a personal DoH stub resolver for ~$0: https://github.com/serverless-dns/zero

The connection itself can be hard to block, but with public DNS resolvers still using dedicated IP addresses I don't think this is as effective as intended.

Just DoH won't save you from an oppressive government and neither will DoT. You can run DoT on port 443 and it'll appear as normal TLS traffic as well. Unless the state actors are doing extensive fingerprinting (that will expose DoH servers as well) I doubt it'll make a difference in situations where DoH makes sense. In areas where occasional government TLS MitM attacks are common, neither DoH nor DoT will protect you.

Reply on news.ycombinator.com