6 ms·

TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains Sigh. This is aggressively breaking normal DNS behavior (an

TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic). Applications should not contain their own encapsulated resolvers, let alone resolvers that default to sending all of my DNS traffic to for-profit companies that have previously experienced massive data leaks (and fun CF fact, they invited the then-CTO of Cambridge Analytica to talk at their Internet Summit event in SF last year).

riquito 8y ago
> will be an absurd hassle for a very large number of organizations they can disable it, any organization that modify /etc/hosts can also change Firefox's preferences file
- peterwwillis 8y ago
  This isn't an acceptable compromise. In general it's not acceptable to break functionality and then demand people invent workarounds. But it's insane to demand that every organization in the world write new portable system integration software that has to take into account 100 varying things just to disable something nobody has asked for. And it's even more insane when the software in question is the underpinning of all internet access that has existed in the same form for 40 years.
  - greglindahl 8y ago
    I wanted this feature.
    - dogecoinbase 8y ago
      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.
unethical_ban 8y ago
They're trying to improve the security of a fundamental protocol - if we waited for committees every time we wanted something new, we wouldn't have HTTP2, HTML5 or a dozen other technologies. I agree they shouldn't take away the "god-mode" /etc/hosts, which is only ever populated very intentionally by sysadmins and power users. If anything, that should be a flag just like the various modes of using TRR. And finally - it's an open protocol in development, and anyone can set it up who wants to. If you don't want to use Google or Cloudflare, you don't have to. And FWIW millions of people are already using 8.8.8.8 and 1.1.1.1 and Cisco's OpenDNS as their primary resolver. That GOOG and CF are at the forefront of another increment of Internet standards should not be surprising.
- wahern 8y ago
  What good is it? TLS SNI already exposes the domain name. Even if that is addressed in the far future, you still can't hide the IP addresses you're connecting to. The only real engineering problem with DNS is authentication, which is adequately solved (however poorly) with DNSSEC and operating systems shipping local resolvers. Moreover, whatever promises CloudFlare and others make, they're still centralization points and therefore ripe targets for infiltration and exfiltration. The moment browsers actually solve the privacy problem will be the moment 9/10ths of the internet goes poof and disappears along with their monetization strategies. As long as Google is viable then these are just tricks arguably doing more harm (increasing reliance on centralized vendors, increasing complexity of the software stack) than good.

riquito 8y ago

> will be an absurd hassle for a very large number of organizations they can disable it, any organization that modify /etc/hosts can also change Firefox's preferences file

peterwwillis 8y ago
This isn't an acceptable compromise. In general it's not acceptable to break functionality and then demand people invent workarounds. But it's insane to demand that every organization in the world write new portable system integration software that has to take into account 100 varying things just to disable something nobody has asked for. And it's even more insane when the software in question is the underpinning of all internet access that has existed in the same form for 40 years.
- greglindahl 8y ago
  I wanted this feature.
  - dogecoinbase 8y ago
    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.

unethical_ban 8y ago

They're trying to improve the security of a fundamental protocol - if we waited for committees every time we wanted something new, we wouldn't have HTTP2, HTML5 or a dozen other technologies. I agree they shouldn't take away the "god-mode" /etc/hosts, which is only ever populated very intentionally by sysadmins and power users. If anything, that should be a flag just like the various modes of using TRR. And finally - it's an open protocol in development, and anyone can set it up who wants to. If you don't want to use Google or Cloudflare, you don't have to. And FWIW millions of people are already using 8.8.8.8 and 1.1.1.1 and Cisco's OpenDNS as their primary resolver. That GOOG and CF are at the forefront of another increment of Internet standards should not be surprising.

wahern 8y ago
What good is it? TLS SNI already exposes the domain name. Even if that is addressed in the far future, you still can't hide the IP addresses you're connecting to. The only real engineering problem with DNS is authentication, which is adequately solved (however poorly) with DNSSEC and operating systems shipping local resolvers. Moreover, whatever promises CloudFlare and others make, they're still centralization points and therefore ripe targets for infiltration and exfiltration. The moment browsers actually solve the privacy problem will be the moment 9/10ths of the internet goes poof and disappears along with their monetization strategies. As long as Google is viable then these are just tricks arguably doing more harm (increasing reliance on centralized vendors, increasing complexity of the software stack) than good.