5 ms·

No, you wanted encryption for DNS transport, and I completely agree with that desire. This is a terrible half-measure that bypasses many existing security prec

No, you wanted encryption for DNS transport, and I completely agree with that desire. This is a terrible half-measure that bypasses many existing security precautions people have intentionally taken by default, and moreover exposes private data to a company with a history of handling such poorly.

geofft 8y ago
I specifically want DNS over HTTPS - except for specialized use cases over known networks where every device in between is tested as behaving properly, protocols that aren't TLS (over TCP) are a hassle to me both as an end user and as a developer, because someone is going to break them. And once you have TLS, there's little benefit in using something other than HTTP inside, and a lot of benefit in using something where everyone already has standard command-line tools and libraries and debugging tools for it. And I trust Cloudflare, and more specifically Mozilla legal's ability to negotiate with Cloudflare, more than I trust approximately any ISP.
- peterwwillis 8y ago
  Why did you want this complicated hack when you could just use a SOCKS5 proxy to tunnel both your DNS and HTTP requests over a plain ssh connection on port 443? Or a TLS VPN on port 443 to properly tunnel all traffic (though admittedly it takes marginally more effort than ssh) ?
  - geofft 8y ago
    One, SSH on port 443 is not the same thing as HTTPS on port 443 (I've seen systems that block the former and not the latter). Two, running a proxy to move all my browsing elsewhere seems like the hack. Changing the internet's norms so normal DNS is HTTPS-based, and everything just works everywhere for everyone, seems like a stable long-term solution.
    - peterwwillis 8y ago
      Everything already works everywhere for everyone with regular DNS. The only thing that is broken is firewalls. Specifically, nobody wants to force network administrators to fix them, so instead they're trying to work around them. Not only is this unnecessary, it's stupid, and just a cheap workaround for something which should have been solved by the industry 18 years ago, but is now left to be wrangled by 3 companies with leverage over users. So I had a DNS server that used UDP. Now I need a DNS server and an HTTPS server that uses TCP. Now I'm encapsulating DNS in HTTPS. So now the packets are bigger and there's extra latency, increasing traffic and slowing things down. (These kind of "fixes" must be common, because I seem to notice how technology is constantly getting slower and crappier rather than the opposite) Then there's security concerns, because you're running twice the software with greater complexity, yet it's subject to the same attack methods as everything else, meaning one exploit could impact DNS just as much as every other HTTPS service. Among these are attacks on the PKI system, which is fragile to say the least - an expired or revoked cert kills your DNS, and any CA can generate a cert (which apparently isn't hard to do using a BGP exploit) which can be used to circumvent the encryption. Since you need DNS to do anything on the net, it will be trivial to simply kill all DNS-over-HTTPS queries going over a network and force people to use a downgraded, insecure version of DNS. And you've got to handle encryption in a way that is normally for streams rather than datagrams - unnecessary for data which only really needs authenticity and integrity assurances (which is, again, already provided by DNSSEC) Then there's reliability. You're tunneling DNS over a connection to one server. We already know this is slower, and we already know DNS is one of the factors that slows down page connections. So you had better hope that the one HTTPS endpoint you have a persistent pipelined connection to doesn't go down, or wait and wait for what you hope is an independent 3rd party's service that is also in your list of DNS-over-HTTPS resolvers to pick up the slack. As a DNS admin, I had software that communicated with DNS servers. But now I have to rewrite everything to use DNS-over-HTTPS, because if a query fails in DNS-over-HTTPS, you have to troubleshoot the actual connection and not what you think is in DNS, or what you think DNS should be sending back to the client. So now I have to reinvent every DNS tool. And of course, for the enterprise DNS solutions that can't just magically sprout a new protocol extension, I'll need some sort of middleware software to map the DNS-over-HTTPS queries to the real DNS server. All of this because someone wanted "privacy" of their DNS queries, and was too lazy to allow UDP packets greater than 512 bytes over their network.
- vetinari 8y ago
  I specifically do not want each application having it's own resolver. That's something operating system has to provide and is configured by administrator, for everything. Some systems go even further and do not allow outcoming traffic on port 53 for proces other than system resolver. Masquerading that as 443 opens a new problem. You don't have to trust anyone, you can run a recursive resolver too. Even some home routers do that already.
  - greglindahl 8y ago
    You might have noticed that Firefox runs in a lot of messed up environments, where, for example, bad installers downloaded by the user have done many bad things to the OS, including installing bogus hosts files which block known anti-virus and anti-malware websites. Firefox had a huge crackdown on malicious toolbars and extensions, and that was a good thing for most people. Do you have a clever suggestion for how Firefox might take your concept of trusting the OS and some administrator, which doesn't exist for most home users, and make it secure against malicious installers?
    - vetinari 8y ago
      The fun with malware will only start, once it starts finding it's command and control centers using DNS-over-HTTPS to a shadow DNS served by botnet and you won't be able to filter out it's traffic.
    - kiriakasis 8y ago
      Also as other have pointed out you can run you own TRR locally as a daemon and have it look to /etc/hosts
      - vetinari 8y ago
        Yes, and configure each app on each computer separately, instead of DHCP or RA, and if you miss some app, it will masquerade it's resolving among the rest of https traffic. Great. That's progress /s.
    - watermelon0 8y ago
- wahern 8y ago
  You trust CloudFlare today. Tomorrow CloudFlare could become a Comcast subsidiary. The willingness of people to put all their stock in a corporation with a promise of benign benevolence boggles my mind. I'm not particularly cynical, but I recoil at the notion that you'll now need an entire HTTP+TLS stack just to do DNS "properly", and that 99% of people will be using a single DNS provider. EDIT: It's not even benign benevolence. I see that DOH includes server push. So now it's obvious how CloudFlare will monetize this--they're positioned to be able to push DNS updates directly to clients, reducing latencies when domain names change, particularly automated DNS topologies for load balancing, failover, etc. Reducing latencies, that is, if you're a paid CloudFlare customer.

geofft 8y ago

I specifically want DNS over HTTPS - except for specialized use cases over known networks where every device in between is tested as behaving properly, protocols that aren't TLS (over TCP) are a hassle to me both as an end user and as a developer, because someone is going to break them. And once you have TLS, there's little benefit in using something other than HTTP inside, and a lot of benefit in using something where everyone already has standard command-line tools and libraries and debugging tools for it. And I trust Cloudflare, and more specifically Mozilla legal's ability to negotiate with Cloudflare, more than I trust approximately any ISP.

peterwwillis 8y ago
Why did you want this complicated hack when you could just use a SOCKS5 proxy to tunnel both your DNS and HTTP requests over a plain ssh connection on port 443? Or a TLS VPN on port 443 to properly tunnel all traffic (though admittedly it takes marginally more effort than ssh) ?
- geofft 8y ago
  One, SSH on port 443 is not the same thing as HTTPS on port 443 (I've seen systems that block the former and not the latter). Two, running a proxy to move all my browsing elsewhere seems like the hack. Changing the internet's norms so normal DNS is HTTPS-based, and everything just works everywhere for everyone, seems like a stable long-term solution.
  - peterwwillis 8y ago
    Everything already works everywhere for everyone with regular DNS. The only thing that is broken is firewalls. Specifically, nobody wants to force network administrators to fix them, so instead they're trying to work around them. Not only is this unnecessary, it's stupid, and just a cheap workaround for something which should have been solved by the industry 18 years ago, but is now left to be wrangled by 3 companies with leverage over users. So I had a DNS server that used UDP. Now I need a DNS server and an HTTPS server that uses TCP. Now I'm encapsulating DNS in HTTPS. So now the packets are bigger and there's extra latency, increasing traffic and slowing things down. (These kind of "fixes" must be common, because I seem to notice how technology is constantly getting slower and crappier rather than the opposite) Then there's security concerns, because you're running twice the software with greater complexity, yet it's subject to the same attack methods as everything else, meaning one exploit could impact DNS just as much as every other HTTPS service. Among these are attacks on the PKI system, which is fragile to say the least - an expired or revoked cert kills your DNS, and any CA can generate a cert (which apparently isn't hard to do using a BGP exploit) which can be used to circumvent the encryption. Since you need DNS to do anything on the net, it will be trivial to simply kill all DNS-over-HTTPS queries going over a network and force people to use a downgraded, insecure version of DNS. And you've got to handle encryption in a way that is normally for streams rather than datagrams - unnecessary for data which only really needs authenticity and integrity assurances (which is, again, already provided by DNSSEC) Then there's reliability. You're tunneling DNS over a connection to one server. We already know this is slower, and we already know DNS is one of the factors that slows down page connections. So you had better hope that the one HTTPS endpoint you have a persistent pipelined connection to doesn't go down, or wait and wait for what you hope is an independent 3rd party's service that is also in your list of DNS-over-HTTPS resolvers to pick up the slack. As a DNS admin, I had software that communicated with DNS servers. But now I have to rewrite everything to use DNS-over-HTTPS, because if a query fails in DNS-over-HTTPS, you have to troubleshoot the actual connection and not what you think is in DNS, or what you think DNS should be sending back to the client. So now I have to reinvent every DNS tool. And of course, for the enterprise DNS solutions that can't just magically sprout a new protocol extension, I'll need some sort of middleware software to map the DNS-over-HTTPS queries to the real DNS server. All of this because someone wanted "privacy" of their DNS queries, and was too lazy to allow UDP packets greater than 512 bytes over their network.
vetinari 8y ago
I specifically do not want each application having it's own resolver. That's something operating system has to provide and is configured by administrator, for everything. Some systems go even further and do not allow outcoming traffic on port 53 for proces other than system resolver. Masquerading that as 443 opens a new problem. You don't have to trust anyone, you can run a recursive resolver too. Even some home routers do that already.
- greglindahl 8y ago
  You might have noticed that Firefox runs in a lot of messed up environments, where, for example, bad installers downloaded by the user have done many bad things to the OS, including installing bogus hosts files which block known anti-virus and anti-malware websites. Firefox had a huge crackdown on malicious toolbars and extensions, and that was a good thing for most people. Do you have a clever suggestion for how Firefox might take your concept of trusting the OS and some administrator, which doesn't exist for most home users, and make it secure against malicious installers?
  - vetinari 8y ago
    The fun with malware will only start, once it starts finding it's command and control centers using DNS-over-HTTPS to a shadow DNS served by botnet and you won't be able to filter out it's traffic.
  - kiriakasis 8y ago
    Also as other have pointed out you can run you own TRR locally as a daemon and have it look to /etc/hosts
    - vetinari 8y ago
      Yes, and configure each app on each computer separately, instead of DHCP or RA, and if you miss some app, it will masquerade it's resolving among the rest of https traffic. Great. That's progress /s.
  - watermelon0 8y ago
wahern 8y ago
You trust CloudFlare today. Tomorrow CloudFlare could become a Comcast subsidiary. The willingness of people to put all their stock in a corporation with a promise of benign benevolence boggles my mind. I'm not particularly cynical, but I recoil at the notion that you'll now need an entire HTTP+TLS stack just to do DNS "properly", and that 99% of people will be using a single DNS provider. EDIT: It's not even benign benevolence. I see that DOH includes server push. So now it's obvious how CloudFlare will monetize this--they're positioned to be able to push DNS updates directly to clients, reducing latencies when domain names change, particularly automated DNS topologies for load balancing, failover, etc. Reducing latencies, that is, if you're a paid CloudFlare customer.