5 ms·

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 part

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 https://en.wikipedia.org/wiki/DNS_over_TLS

dijit 6y ago
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.
- MaxBarraclough 6y ago
  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?
- swiley 6y ago
  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.
  - MaxBarraclough 6y ago
    How does your ISP hijack an HTTPS connection? Are you using your ISP's DNS service?
    - swiley 6y ago
      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.
      - MaxBarraclough 6y ago
        > 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.
        withinboredom 6y ago
        > 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.
        MaxBarraclough 6y ago
        > 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.
- 293984j29384 6y ago
  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.
- adrianmonk 6y ago
  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.
feanaro 6y ago
> Would you prefer DNS-over-TLS? I'd prefer dnscrypt (https://en.wikipedia.org/wiki/DNSCrypt https://en.wikipedia.org/wiki/DNSCrypt). I'm still not sure why we're going with DoH instead of dnscrypt.
- tptacek 6y ago
  Has anyone even written an I-D for DNSCrypt?
dehrmann 6y ago
> 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.

dijit 6y ago

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.

MaxBarraclough 6y ago
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?
swiley 6y ago
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.
- MaxBarraclough 6y ago
  How does your ISP hijack an HTTPS connection? Are you using your ISP's DNS service?
  - swiley 6y ago
    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.
    - MaxBarraclough 6y ago
      > 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.
      - withinboredom 6y ago
        > 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.
        MaxBarraclough 6y ago
        > 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.
293984j29384 6y ago
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.
adrianmonk 6y ago
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.

feanaro 6y ago

> Would you prefer DNS-over-TLS? I'd prefer dnscrypt (https://en.wikipedia.org/wiki/DNSCrypt https://en.wikipedia.org/wiki/DNSCrypt). I'm still not sure why we're going with DoH instead of dnscrypt.

tptacek 6y ago
Has anyone even written an I-D for DNSCrypt?

dehrmann 6y ago

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