Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

There's value in solving the security challenges of HTTPS once, and to then resist reinventing the wheel elsewhere. Using it for DNS doesn't strike me as a particularly bad case of shoehorning.

What specifically don't you like about the use of HTTPS? Would you prefer DNS-over-TLS? Apparently [0] that's an option too. I don't think it would be possible to be quite as lightweight as the plain old UDP-based DNS protocol while giving the desired security properties.

[0] https://en.wikipedia.org/wiki/DNS_over_TLS

View on HN

I specifically mentioned "HTTP" and not "HTTPS" because, while there are some security extension headers in http; the majority of HTTPS's security is a solved-once situation already in the form of TLS.

The reason I don't like HTTP for all purposes is because, while it has proven to be expandable, I feel like we're going to have this "oh shit" moment in 10 years where we realise all the cruft we've added to it and how it's bogging down otherwise simple communication.

DNS was designed to be incredibly low latency, QUIC is a response to the high latency of TCP for HTTP in general; but then you're still sending a fair amount of content that is completely unneeded.

A few dozen bytes here and there don't matter much, but that mentality is why computers today have worse input lag than computers 30 years ago, despite being many hundreds of times faster.

I can see where you're coming from. I share your disdain for avoidable bloat.

I suspect you know rather more about QUIC than I do. DNS-over-QUIC sounds like a secure, low-latency solution, at least on the face of it. Would it really be possible to shave off much overhead there?

DoH does not fix the security issues with DNS. My ISP hijacks it and sends you to a page full of ads when you visit a missing domain just like older DNS. The browser vendors even provide explicit instructions for this.

Literally all this does is break things.

How does your ISP hijack an HTTPS connection? Are you using your ISP's DNS service?

They don’t hijack https they hijack DoH. The point behind this is to protect the average user but they’re just going to get the recursive resolver from dhcp. People who bother to use something are the same ones who will tunnel traffic or run their own resolver.

> They don’t hijack https they hijack DoH

DoH stands for DNS-over-HTTPS. You cannot hijack DoH without hijacking an HTTPS connection.

> they’re just going to get the recursive resolver from dhcp

In answer to my earlier question then, you're using your ISP's DoH DNS service, correct? If that's the case, there's no hijacking going on.

> People who bother to use something are the same ones who will tunnel traffic or run their own resolver.

This is the reason Firefox went with CloudFlare's DoH. Resisting ISPs' bullshit is much of the point.

> You cannot hijack DoH without hijacking an HTTPS connection.

Not true. An ISP can always reroute packets where ever they want. Want to reroute from a trusted resolver to your own, which is bootstrapped over regular DNS? No problem. Client checks it? No problem, it will fallback to regular DNS.

> Client checks it? No problem, it will fallback to regular DNS.

That's a good point, I'd missed that. I'd hope the browser would show a warning in this case though.

I don't imagine there'd be any point redirecting a DoH request rather than just blocking it outright though. No serious DoH implementation is going to fail to check the cert.

Unless you have trusted a CA from your ISP, they won't have a valid cert. They can divert the packETS, but their response will be invalid (fail when the client checks the cert).

I addressed this in my response. You're right that redirection does little more than just blocking the traffic, on account of the certificate check, but if the attacker can force a fallback to regular DNS, that's a problem.

Every browser DoH implementation checks certificates.

Nope. All you have to do is block the ones the two border vendors use as defaults and you’re back to square one.

Right, as withinboredom said. I don't know if ISPs are likely to be so brazen though.

DNS latency is much more provider specific then protocol. If you were using both in a vacuum, you'd be correct, but in the real world DoH does not have any significant impact on latency. Switching to Cloudflare's DoH service improved my DNS resolution significantly over my ISPs.

I think it's over complicated too, but I bet that in real-world use, the latency might not be that noticeable.

For one thing, if your DNS server is nearby, as it traditionally is with an ISP, latency is usually low. If you want to establish a TCP connection quickly, one thing that helps an enormous amount is to move the server as close to the client as possible.

I don't know if they are planning to do this, but you could also do some connection caching. Keep that TCP connection open while you are browsing.

It is a shame to have to do things to mitigate latency that you could have just not added in the first place. But at least the mitigation probably works.

> Would you prefer DNS-over-TLS?

I'd prefer dnscrypt (https://en.wikipedia.org/wiki/DNSCrypt). I'm still not sure why we're going with DoH instead of dnscrypt.

Has anyone even written an I-D for DNSCrypt?

> There's value in solving the security challenges of HTTPS once, and to then resist reinventing the wheel elsewhere.

TLS does that part. HTTPS solved/worked around a lot of web problems (same-origin policy) that don't apply to DNS.

Reply on news.ycombinator.com