8 ms·

This is a great summary and I agree with the findings mostly. I think we should separate the "DoH the protocol" from the "DoH decision of using a public resolve

This is a great summary and I agree with the findings mostly. I think we should separate the "DoH the protocol" from the "DoH decision of using a public resolver". For "DoH the protocol", widespread adoption by most users' default resolvers is about as likely as widespread adoption of DNSSEC and DoT. For "DoH decision of using a public resolver", that decision can be done today with resolvers that support DNSSEC/DoT. So if we want users to use a hardcoded default resolver different than their ISP's, come out and say that and stop conflating it w/ the protocol. If we want users to use the DoH protocol, we're in the same boat as asking them to use DNSSEC/DoT. Therefore, for the idea of a hardcoded default resolver in one browser, if it's really something a browser wants to do, why are they waiting on a protocol? And for the idea in another browser of checking known protocol support of the existing resolver, do/can they do that with DoT too? And can they do something besides a hardcoded list to check resolver capabilities (i.e. can I return an additional record/bit from my DNS servers that is essentially DNS equivalent of HTTP Alt-Svc to say I support DoH)?

josteink 7y ago
Great point. I don’t mind improved DNS security. DoH the protocol, being based on HTTP feels wrong, but I guess that’s how the kids these days writes protocols. So be it. DoH, the resolver, being chosen for me, without my consent... that’s an absolute no go. That’s what malware does.
- shawnz 7y ago
  Did you choose your DNS resolver?
  - josteink 7y ago
    Yes. Through lots of actions: By choosing ISP. By setting up my own router. By implementing a pihole. By configuring my OS. No application has any business overriding any of those choices unasked, but should use what the OS provides. Like every application does, except modern browsers which for some reason think they are special. Here’s news for you: they’re not.
    - shawnz 7y ago
      I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser. Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites?
      - josteink 7y ago
        > I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser. That's not a reasonable position. Never before in the history of computing has a regular end-user application actively tried to subvert the operating-system's network defaults. Why should anyone expect that to be the position now? Should I expect Thunderbird too to bypass my DNS-settings? What about Rust's cargo? It's from Mozilla too. Will I need to manually go configure all those tools to do what is the reasonable default, namely following what the OS tells it to do? When Firefox fails to resolve a domain, but nslookup resolves it just fine... What should I as an end-user believe? (Besides that we have an orderly world turning into chaos) Do you really think every application choosing, managing and implementing its own resolver is a scalable way of managing applications and networking? Really? Yeah no. So why should browsers get a free pass do things differently? > Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites? No. But that's not what we're talking about here. What has always been a clear expectation is that if I sign up for an ISP and I use that ISP's default network setup, that I will be using that ISP's DNS. Never in the history of ISPs has there been any other default. So if I may rephrase your question: > Was it explicitly clear to you that by using an ISP as an ISP, you will also by default use their DNS services? Obviously. That's how the internet works and has always worked. In fact, anything else would be strange. Unless I explicitly implement something differently, I have no reason to expect anyone besides my ISP (which I do trust, I'm not from the US) is handling my DNS. Unlike my ISP (which I trust), anyone who deviates from this contract will be someone I actively distrust. I'm looking at you, Mozilla.
        7y ago
cryptonector 7y ago
There's a tension between using private, semi-public (ISP-run), and public resolvers. The more clients a resolver has, the better the privacy protection it offers vis-a-vis authoritative servers, so there's some reason to want to use one's ISP's resolver, or even a public resolver. On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data. Regardless, ISPs need to adopt support for DoT and DoH. Lastly, it'd be nice if we could get authoritative servers to support DoT/DoH, but that will take a long time. It'd have been nice to have settled on DNSCurve for confidentiality a decade ago... Even assuming Curve25519's eventual obsolescence, it would have served us well while waiting for a better solution.
- zrm 7y ago
  It'd be nice if we could settle on DNSCurve for authoritative servers even now. It's significantly simpler and more efficient than DoH and the only real advantage DoH has over it (less interference from quarrelsome middleboxes) isn't nearly the problem between recursive and authoritative resolvers as it is between clients and recursive resolvers, because recursive resolvers are almost always operated from networks that are responsive to their administrators.
  - bluejekyll 7y ago
    Why do you say DNSCurve is simpler? Having implemented DoH and DoT, it's pretty much as simple as adding TLS to the connection...
    - zrm 7y ago
      It's simple if you pull in a dependency on a library that does it for you, but that's just putting the complexity in the library. HTTP is a complex protocol, TLS is a complex protocol, even just using TCP isn't exactly simple or advantageous to response latency.
      - 7y ago
tptacek 7y ago
The entire premise of DoH and DoT are that you don't want to use your ISP's DNS. Nobody needs to "come out and say that"; it's whole point. They're both mechanisms to tunnel DNS out of your network to somewhere safer. The difference between the two is that DoT has a network-operator kill switch, and DoH doesn't.
- cryptonector 7y ago
  Using someone's resolver other than your own is sensible: it serves to hide from authoritative servers the IP addresses of each query's requestor, both because the resolver aggregates many clients' lookups, and because of caching. But whoever runs the resolver you use gets to see what domainnames you're resolving. Your resolver's operator will be sorely tempted to monetize that metadata. Your only choice is which resolver operator you'll allow to monetize your metadata. So you lose no matter what, unless you have a contract with the operator, and then you'd better be giving them something of value if you want to be able to enforce the contract's confidentiality requirements. ISPs mostly don't even support DoH/DoT, which is a reason to not want to use their resolvers. But using public resolvers helps centralize the DNS, which is not good.
  - tptacek 7y ago
    Yes. If you're concerned that your third-party resolver is monetizing or otherwise monitoring your DNS, you can run your own DoH recursor, semi-anonymously, from a public cloud account. In the long run, presumably trustworthy organizations will stand up DoH resolvers that people can trust. I preemptively agree that Cloud Flare is not one of those organizations. It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.
    - cryptonector 7y ago
      We all should be worried about loss of privacy, but we can't all run our own resolvers on the cloud. The choice of DoT vs DoH will mostly be about what is supported by one's choice of resolver. Of course, choosing DoH first will narrow the choice of resolvers. Then there's captive portal situations.
deleted 7y ago
[deleted]

josteink 7y ago

Great point. I don’t mind improved DNS security. DoH the protocol, being based on HTTP feels wrong, but I guess that’s how the kids these days writes protocols. So be it. DoH, the resolver, being chosen for me, without my consent... that’s an absolute no go. That’s what malware does.

shawnz 7y ago
Did you choose your DNS resolver?
- josteink 7y ago
  Yes. Through lots of actions: By choosing ISP. By setting up my own router. By implementing a pihole. By configuring my OS. No application has any business overriding any of those choices unasked, but should use what the OS provides. Like every application does, except modern browsers which for some reason think they are special. Here’s news for you: they’re not.
  - shawnz 7y ago
    I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser. Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites?
    - josteink 7y ago
      > I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser. That's not a reasonable position. Never before in the history of computing has a regular end-user application actively tried to subvert the operating-system's network defaults. Why should anyone expect that to be the position now? Should I expect Thunderbird too to bypass my DNS-settings? What about Rust's cargo? It's from Mozilla too. Will I need to manually go configure all those tools to do what is the reasonable default, namely following what the OS tells it to do? When Firefox fails to resolve a domain, but nslookup resolves it just fine... What should I as an end-user believe? (Besides that we have an orderly world turning into chaos) Do you really think every application choosing, managing and implementing its own resolver is a scalable way of managing applications and networking? Really? Yeah no. So why should browsers get a free pass do things differently? > Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites? No. But that's not what we're talking about here. What has always been a clear expectation is that if I sign up for an ISP and I use that ISP's default network setup, that I will be using that ISP's DNS. Never in the history of ISPs has there been any other default. So if I may rephrase your question: > Was it explicitly clear to you that by using an ISP as an ISP, you will also by default use their DNS services? Obviously. That's how the internet works and has always worked. In fact, anything else would be strange. Unless I explicitly implement something differently, I have no reason to expect anyone besides my ISP (which I do trust, I'm not from the US) is handling my DNS. Unlike my ISP (which I trust), anyone who deviates from this contract will be someone I actively distrust. I'm looking at you, Mozilla.
      - 7y ago

cryptonector 7y ago

There's a tension between using private, semi-public (ISP-run), and public resolvers. The more clients a resolver has, the better the privacy protection it offers vis-a-vis authoritative servers, so there's some reason to want to use one's ISP's resolver, or even a public resolver. On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data. Regardless, ISPs need to adopt support for DoT and DoH. Lastly, it'd be nice if we could get authoritative servers to support DoT/DoH, but that will take a long time. It'd have been nice to have settled on DNSCurve for confidentiality a decade ago... Even assuming Curve25519's eventual obsolescence, it would have served us well while waiting for a better solution.

zrm 7y ago
It'd be nice if we could settle on DNSCurve for authoritative servers even now. It's significantly simpler and more efficient than DoH and the only real advantage DoH has over it (less interference from quarrelsome middleboxes) isn't nearly the problem between recursive and authoritative resolvers as it is between clients and recursive resolvers, because recursive resolvers are almost always operated from networks that are responsive to their administrators.
- bluejekyll 7y ago
  Why do you say DNSCurve is simpler? Having implemented DoH and DoT, it's pretty much as simple as adding TLS to the connection...
  - zrm 7y ago
    It's simple if you pull in a dependency on a library that does it for you, but that's just putting the complexity in the library. HTTP is a complex protocol, TLS is a complex protocol, even just using TCP isn't exactly simple or advantageous to response latency.
    - 7y ago

tptacek 7y ago

The entire premise of DoH and DoT are that you don't want to use your ISP's DNS. Nobody needs to "come out and say that"; it's whole point. They're both mechanisms to tunnel DNS out of your network to somewhere safer. The difference between the two is that DoT has a network-operator kill switch, and DoH doesn't.

cryptonector 7y ago
Using someone's resolver other than your own is sensible: it serves to hide from authoritative servers the IP addresses of each query's requestor, both because the resolver aggregates many clients' lookups, and because of caching. But whoever runs the resolver you use gets to see what domainnames you're resolving. Your resolver's operator will be sorely tempted to monetize that metadata. Your only choice is which resolver operator you'll allow to monetize your metadata. So you lose no matter what, unless you have a contract with the operator, and then you'd better be giving them something of value if you want to be able to enforce the contract's confidentiality requirements. ISPs mostly don't even support DoH/DoT, which is a reason to not want to use their resolvers. But using public resolvers helps centralize the DNS, which is not good.
- tptacek 7y ago
  Yes. If you're concerned that your third-party resolver is monetizing or otherwise monitoring your DNS, you can run your own DoH recursor, semi-anonymously, from a public cloud account. In the long run, presumably trustworthy organizations will stand up DoH resolvers that people can trust. I preemptively agree that Cloud Flare is not one of those organizations. It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.
  - cryptonector 7y ago
    We all should be worried about loss of privacy, but we can't all run our own resolvers on the cloud. The choice of DoT vs DoH will mostly be about what is supported by one's choice of resolver. Of course, choosing DoH first will narrow the choice of resolvers. Then there's captive portal situations.

deleted 7y ago

[deleted]