14 ms·

DoH: Anti-Competitive and Network Neutrality Aspects

57 points by stock_toaster 7y ago

iofiiiiiiiii 7y ago
The article claims that there is some push towards centralized DNS. I do not see the evidence to support this - the only reason Cloudflare is the default in Firefox is that DoH implementations are still rare. PowerDNS is free to implement DoH themselves if they want their customers to be competitive, and so is every ISP.
- deleted 7y ago
  [deleted]
- sp332 7y ago
  CF was chosen because they signed a contract with Mozilla to reduce the amount of data they collect to the bare minimum.
  - throw0101a 7y ago
    Can (US) National Security Letters override such contracts? One nice thing about 'plain' DNS(-over-54; Do53) is that it is distributed in nature, so to get any kind of massive surveillance you have to visit multiple ISPs.
    - sp332 7y ago
      That's not in most people's threat model. If it is in your threat model, you can change the DoH provider to any such service you want. CF with the additional privacy policy is an excellent default choice.
    - heavyset_go 7y ago
      > Can (US) National Security Letters override such contracts? Yes, and normal, everyday courts can compel companies to siphon their customers' data and keep it secret that they're doing so, despite any claims that the companies make in their privacy policies.
skissane 7y ago
Why can't I, as an end-user, have the choice of who I want to trust? My ISP, Cloudflare, Google, somebody else? Give me a dialog box in which I can choose whether to use DoH and if so which provider to use, and then I can make up my own mind over which of those parties I trust the most.
- saurik 7y ago
  I would argue that the original way to do this--where applications used the system resolver--gave you that option, as the system resolver could trivially be modified to do whatever you wanted (well, unless you are on iOS; on iOS you are effectively just screwed, because Apple wants to control the entire software experience... more on this in a later paragraph <- edit: and also, I realized you can also do this on iOS!). glibc, for example, allows you to just give it arbitrary software plugins to implement the resolver, and so you--the person who configures your computer--have complete control over not just "who" you want to trust, but exactly "how" you trust them: you can decide to talk to Google, Cloudflare, or your ISP, and you can use DNS over HTTPS, DNS over TLS, unencrypted DNS, or something insane like Active Directory for all anyone cared. However, at some point, web browsers decided that they didn't like end users being able to have this control, as, in practice, no one ever took advantage of it and they always allowed the operating system to select, by default, "use unencrypted DNS to the current ISP", which was slow, insecure, and often just wrong (as ISPs--for at least four reasons I can think of, all but maybe one of which I will assert are "bad"--would sometimes return incorrect answers on purpose); and so, now, the new reality is that software is coming with embedded DNS resolvers that do exactly and only what the software developer wanted (which, in a world of not just codesigning but notarization, increasingly means the user has no ability to have any say in the matter what-so-ever), because "developers know better than everyone else" (originally, this was just for performance reasons or to avoid strange behavior from ISPs, reimplementing the logic, but not the protocol, though now they are using that control to take it further). For clarity, I will restate "the premise": if software uses the system resolver (the one that people erroneously like to claim is somehow synonymous with "unencrypted DNS to your ISP"), anyone who wants to use DNS over HTTPS can, AFAIK on any non-iOS operating system (if nothing else, by simply setting their DNS server to 127.0.0.1, if for some reason you can't just plug in your own resolver backend; edit: oh, actually, even on iOS, by using a local Network Extension, which is how Cloudflare's 1.1.1.1 app works), do that for not just their web browser but for all software on their entire system at once; and, when some new protocol comes out that is even better than DNS over HTTPS (maybe by solving some latency issue, or by using a decentralized resolver, or adding cryptographic verification), it would be equally easy to change your system resolver, and by extension all software on your entire computer, at once, to use that protocol. And now, again, for clarity, I will restate "what happened": that this was deemed not something that either users or, interestingly, operating systems should be in control over (though it would be hilarious to see Apple try to fight this one out from their fortress of iOS, claiming you don't get to be in the App Store unless you use the system resolver, a similar battle to their issues with people doing HTTPS requests that don't use their App Transport Security library); and so, instead, software (possibly ever single piece of software you use: not just your web browser, but random desktop chat applications, e-mail clients, games... maybe even network-oriented command line tools such as curl!) will now embed their own DNS implementations, making it "your guess is as good as mine" as to what protocol or root of trust any specific piece of software is relying on :/.
veonik 7y ago
The EU might be doing a better job here-- but is this suggesting that I trust my US ISP's DNS servers? The ISP that injects HTML into my HTTP requests? The same ISP known to hijack DNS requests? Don't get me wrong, the issues raised by OP are valid and need to be addressed-- already we see the strangely privacy-antithetical behavior of using DoH to get around CNAME tracking in adblockers (using Cloudflare no less) --but I don't think legislation and regulation have been effective so far. Expecting that to change in the near future seems like a pipe dream.
- zrm 7y ago
  > The EU might be doing a better job here-- but is this suggesting that I trust my US ISP's DNS servers? That's the false dichotomy. You shouldn't use either one. The issue is that if you've already made your choice, e.g. by having your DHCP server give out the DNS you actually want to use or configuring it in your operating system, then having Mozilla default to ignoring your choice and overwriting it with Cloudflare is wrong. And it would be one thing if it was something like people selling internet gateway devices that do this by default -- that's a great idea because it gets you away from the ISP's DNS by default but still provides a single place to set it the way you want it, and still allows the owner of an individual device to override it device-wide if desired. Putting it in individual applications is the opposite. It means you have a full time job just changing it back to the way you want it in every application on every device, and even then you're liable to miss some.
  - sciurus 7y ago
    > It means you have a full time job just changing it back to the way you want it in every application on every device, and even then you're liable to miss some. Hopefully not. Firefox has some techniques for disabling DoH that rely on computer or network-wide changes. If other applications also adopt these or similar techniques, you'd only have to make the change in one place to turn it off for every application running on any computer on a network. Specifically, as I understand it, Firefox disables DoH if 1) Windows Group Policy is used to manage a computer 2) A canary domain is blocked https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-will-doh-impact-enterprises-with-custom-dns-solutions https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs... (Disclosure: I work for Mozilla, but not on the Firefox browser)
vtsingaras 7y ago
The point presented by the post is plain wrong, people were using non-ISP recursors for a long time already and this was not problem due to the fact that EDNS Client Subnet has been a thing for a while now. The problem mentioned in the post is specific to Cloudflare, as they do not support EDNS Client Subnet anyway, even over plain UDP53 more reading: https://www.samknows.com/blog/dns-over-https-performance https://www.samknows.com/blog/dns-over-https-performance
- jgrahamc 7y ago
  Mozilla did their own testing of DoH and its effect on performance in conjunction with Akamai: Test announcement: https://blog.mozilla.org/futurereleases/2018/11/27/next-steps-in-dns-over-https-testing/ https://blog.mozilla.org/futurereleases/2018/11/27/next-step... "To do that, we’re working with Akamai to help us understand more about the performance impact." First results: https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/ https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-... "The results were strong! Like our previous studies, DoH had minimal impact or clearly improved the total time it takes to get a response from the resolver and fetch a web page." Final post: https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-https-doh-update-detecting-managed-networks-and-user-choice/ https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-... "Furthermore, we found that web pages that are hosted by Akamai–a content distribution network, or “CDN”–have similar performance when DoH is enabled."
  - gsich 7y ago
    And nowhere is "TCP" mentioned. I suppose the connection just builds up itself in 0ms time. Sure if you already have <5ms latency to your DNS, the additional RTT from TCP and TLS won't matter much. For the rest: they will.
    - jrwr 7y ago
      DoH can use UDP, but most dont, Also most people's local DNS (Here in America) Provided by their ISP is pretty shit. In my experience working at a MSP, having a local DNS server is always best
souterrain 7y ago
> Note that some countries have an underdeveloped ISP market, with large fractions of the population having no choice of broadband service provider. Regulation is then of the utmost importance to keep everyone honest, but in some of these countries the regulator has been captured by industry and is no longer very effective. This mostly goes for the US. I think this is the key motivator for a move to DoH. Large US ISPs can’t be trusted.
- gsich 7y ago
  >Large US ISPs can’t be trusted. But why trust Cloudflare?
  - bepvte 7y ago
    A clear privacy policy and an third-party audit.
    - shkkmo 7y ago
      Provided in return for a competitive advantage and a reduction in network neutrality.
    - cremp 7y ago
      All ISPs have privacy policies. 99% of all privacy policies are either copy/pasted from elsewhere or written in legalese so that company can do whatever they want. 'Internal business use' is a nice fodder for 'Selling data to increase this general ledger account for later business use.' An audit is almost always under bad pretenses. If I spend $$$ on an audit company, the company itself has bias. The difference between third-party audits and government issued audits (think food safety) is that the government has nothing to gain by a positive, or negative result. IANAL, just cynical of people.
    - gsich 7y ago
      ISPs have those too (ISO 27001 is common). Again, why trust Cloudflare?
jannes 7y ago
While I disagree with Mozilla's decision to switch users to centralised DoH, I believe they are right in their assesment that the current DNS infrastructure is not very private. And something like DoH sounds pretty cool. Without encryption there are a few nefarious things ISPs can do quite easily: - transparent DNS proxies - DNS query tracking These things are pretty bad if you're affected, but I believe this shouldn't be addressed by centralisation of DNS.
- stock_toaster 7y ago
  I think Dns-over-TLS (DoT) is a much better solution. It seems super weird to me that Mozilla isn't pushing for that, and is instead pushing for DoH+cloudflare.
tptacek 7y ago
This is a disinformation campaign. DoH doesn't centralize DNS or DNS privacy. Anyone can run a DoH resolver server, and it'll do just as good a job as Cloud Flare's. The people crusading against DoH favor a different centralized DNS standard, DoT. DoT is DoH with essentially one difference, which is that it runs on its own port, so that network operators can block it. There's a sprawling cottage industry of security and analytics products that rely on passive DNS analysis to function, and people who sell those products or operate networks that use them have a strong disincentive to block DoT and require users to speak standard, plaintext DNS to servers they can monitor. Note however that once it's up and running, DoT is just as centralized as DoH is; it has to be, because it provides the exact same service model. Centralization and competition has nothing to do with their real concerns, or they'd be lobbying against DoT as well. I can't say I'm especially fond of Firefox's decision to default to Cloud Flare for its DoH resolver, because I loathe Cloud Flare. Google Chrome does something more sensible: it won't change your DNS server at all, but will upgrade you to DoH if your nameservers support DoH. You should use nameservers that do, because DoH is valuable: if you're in the US, your ISP is almost certainly passively monitoring and recording your DNS queries, and you shouldn't let them. Personal feelings about Cloud Flare aside, you are better off with them than with your US ISP's DNS servers. There's a strain of Unix sysadmin criticism against DoH that says it's wrong for browsers to co-opt DNS resolution at all, and that they should use the system's resolver. This is nonsense. First, almost no matter which browser you use, you should trust their DNS resolution code more than your operating system's; it will be more security-conscious and probably more performance-conscious code --- DNS resolution maintenance is the job you get on Microsoft or Apple's OS teams to punish you when you break the build. More importantly, as anyone who's ever had to mess around with libares will tell you, browsers have always needed better DNS resolution than libc offers, because they need fast async lookups. There's another strain of criticism against DoH that Unix nerds won't see much of but which is probably even more important to be aware of: there have been hearings in Congress about how DoH threatens law enforcement by depriving them of intelligence for investigations. Ultimately, this is of a kind with the DoT vs. DoH argument: the people lobbying against DoH simply don't believe DNS lookups should be private. Another "tell" that you're reading one of these people is when they start talking about how DNS privacy doesn't provide complete or perfect privacy --- that you shouldn't care if your DNS lookups are being monitored, because you're leaking so much information elsewhere. This is bamboozlement. DoH privacy is extraordinarily low-effort, actually modernizes the DNS protocol in some ways, and addresses a threat millions of users are directly facing right now. You should be wary of any outlet that promotes the meme that DoH is somehow shady.
fhrow4484 7y ago
I don't seem to understand the whole thing. To me the premises are: 1) we can't trust ISP with unencrypted DNS query 2) we can trust a third party with DNS query because those are encrypted. My questions are: - Why is 1 true? What are ISP doing with unencrypted DNS queries apart from knowing browsing habits? - With DoH do they not know your browsing habit anymore? - If there is a possible mitm attack with unencrypted, would it be fine if the ISP themselves ran a DoH server? - For the 3rd party: why would a 3rd party want to run a dns server for free? ISP run DNS server but customers pay a bill to them precisely to do things like this. in other words, in the long term, wouldn't it be a money sink for Cloudflare to run a DoH server? - Instead of just one DoH endpoint, could browsers take a list of DoH servers, and picking the best one in terms of p95 latency, with some round-robbin tries occasionally to verify if anything changes? This would solve the issue of one of the DoH service "having a bad day". Some amount of centralization would remain but based on an objective criteria (latency). (The article answers some of those questions and/or points out the same concerns)
musicale 7y ago
> We have to keep in mind that if a DNS lookup is slow, the entire internet feels sluggish. Slow DNS = Slow internet. Ridiculously low DNS TTL is an idiotic curse of the internet, but fortunately (and currently) one that can be (mostly) fixed locally.

57 points by stock_toaster 7y ago

The article claims that there is some push towards centralized DNS. I do not see the evidence to support this - the only reason Cloudflare is the default in Firefox is that DoH implementations are still rare. PowerDNS is free to implement DoH themselves if they want their customers to be competitive, and so is every ISP.

deleted 7y ago
[deleted]
sp332 7y ago
CF was chosen because they signed a contract with Mozilla to reduce the amount of data they collect to the bare minimum.
- throw0101a 7y ago
  Can (US) National Security Letters override such contracts? One nice thing about 'plain' DNS(-over-54; Do53) is that it is distributed in nature, so to get any kind of massive surveillance you have to visit multiple ISPs.
  - sp332 7y ago
    That's not in most people's threat model. If it is in your threat model, you can change the DoH provider to any such service you want. CF with the additional privacy policy is an excellent default choice.
  - heavyset_go 7y ago
    > Can (US) National Security Letters override such contracts? Yes, and normal, everyday courts can compel companies to siphon their customers' data and keep it secret that they're doing so, despite any claims that the companies make in their privacy policies.

skissane 7y ago

Why can't I, as an end-user, have the choice of who I want to trust? My ISP, Cloudflare, Google, somebody else? Give me a dialog box in which I can choose whether to use DoH and if so which provider to use, and then I can make up my own mind over which of those parties I trust the most.

saurik 7y ago
I would argue that the original way to do this--where applications used the system resolver--gave you that option, as the system resolver could trivially be modified to do whatever you wanted (well, unless you are on iOS; on iOS you are effectively just screwed, because Apple wants to control the entire software experience... more on this in a later paragraph <- edit: and also, I realized you can also do this on iOS!). glibc, for example, allows you to just give it arbitrary software plugins to implement the resolver, and so you--the person who configures your computer--have complete control over not just "who" you want to trust, but exactly "how" you trust them: you can decide to talk to Google, Cloudflare, or your ISP, and you can use DNS over HTTPS, DNS over TLS, unencrypted DNS, or something insane like Active Directory for all anyone cared. However, at some point, web browsers decided that they didn't like end users being able to have this control, as, in practice, no one ever took advantage of it and they always allowed the operating system to select, by default, "use unencrypted DNS to the current ISP", which was slow, insecure, and often just wrong (as ISPs--for at least four reasons I can think of, all but maybe one of which I will assert are "bad"--would sometimes return incorrect answers on purpose); and so, now, the new reality is that software is coming with embedded DNS resolvers that do exactly and only what the software developer wanted (which, in a world of not just codesigning but notarization, increasingly means the user has no ability to have any say in the matter what-so-ever), because "developers know better than everyone else" (originally, this was just for performance reasons or to avoid strange behavior from ISPs, reimplementing the logic, but not the protocol, though now they are using that control to take it further). For clarity, I will restate "the premise": if software uses the system resolver (the one that people erroneously like to claim is somehow synonymous with "unencrypted DNS to your ISP"), anyone who wants to use DNS over HTTPS can, AFAIK on any non-iOS operating system (if nothing else, by simply setting their DNS server to 127.0.0.1, if for some reason you can't just plug in your own resolver backend; edit: oh, actually, even on iOS, by using a local Network Extension, which is how Cloudflare's 1.1.1.1 app works), do that for not just their web browser but for all software on their entire system at once; and, when some new protocol comes out that is even better than DNS over HTTPS (maybe by solving some latency issue, or by using a decentralized resolver, or adding cryptographic verification), it would be equally easy to change your system resolver, and by extension all software on your entire computer, at once, to use that protocol. And now, again, for clarity, I will restate "what happened": that this was deemed not something that either users or, interestingly, operating systems should be in control over (though it would be hilarious to see Apple try to fight this one out from their fortress of iOS, claiming you don't get to be in the App Store unless you use the system resolver, a similar battle to their issues with people doing HTTPS requests that don't use their App Transport Security library); and so, instead, software (possibly ever single piece of software you use: not just your web browser, but random desktop chat applications, e-mail clients, games... maybe even network-oriented command line tools such as curl!) will now embed their own DNS implementations, making it "your guess is as good as mine" as to what protocol or root of trust any specific piece of software is relying on :/.

veonik 7y ago

The EU might be doing a better job here-- but is this suggesting that I trust my US ISP's DNS servers? The ISP that injects HTML into my HTTP requests? The same ISP known to hijack DNS requests? Don't get me wrong, the issues raised by OP are valid and need to be addressed-- already we see the strangely privacy-antithetical behavior of using DoH to get around CNAME tracking in adblockers (using Cloudflare no less) --but I don't think legislation and regulation have been effective so far. Expecting that to change in the near future seems like a pipe dream.

zrm 7y ago
> The EU might be doing a better job here-- but is this suggesting that I trust my US ISP's DNS servers? That's the false dichotomy. You shouldn't use either one. The issue is that if you've already made your choice, e.g. by having your DHCP server give out the DNS you actually want to use or configuring it in your operating system, then having Mozilla default to ignoring your choice and overwriting it with Cloudflare is wrong. And it would be one thing if it was something like people selling internet gateway devices that do this by default -- that's a great idea because it gets you away from the ISP's DNS by default but still provides a single place to set it the way you want it, and still allows the owner of an individual device to override it device-wide if desired. Putting it in individual applications is the opposite. It means you have a full time job just changing it back to the way you want it in every application on every device, and even then you're liable to miss some.
- sciurus 7y ago
  > It means you have a full time job just changing it back to the way you want it in every application on every device, and even then you're liable to miss some. Hopefully not. Firefox has some techniques for disabling DoH that rely on computer or network-wide changes. If other applications also adopt these or similar techniques, you'd only have to make the change in one place to turn it off for every application running on any computer on a network. Specifically, as I understand it, Firefox disables DoH if 1) Windows Group Policy is used to manage a computer 2) A canary domain is blocked https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-will-doh-impact-enterprises-with-custom-dns-solutions https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs... (Disclosure: I work for Mozilla, but not on the Firefox browser)

vtsingaras 7y ago

The point presented by the post is plain wrong, people were using non-ISP recursors for a long time already and this was not problem due to the fact that EDNS Client Subnet has been a thing for a while now. The problem mentioned in the post is specific to Cloudflare, as they do not support EDNS Client Subnet anyway, even over plain UDP53 more reading: https://www.samknows.com/blog/dns-over-https-performance https://www.samknows.com/blog/dns-over-https-performance

jgrahamc 7y ago
Mozilla did their own testing of DoH and its effect on performance in conjunction with Akamai: Test announcement: https://blog.mozilla.org/futurereleases/2018/11/27/next-steps-in-dns-over-https-testing/ https://blog.mozilla.org/futurereleases/2018/11/27/next-step... "To do that, we’re working with Akamai to help us understand more about the performance impact." First results: https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/ https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-... "The results were strong! Like our previous studies, DoH had minimal impact or clearly improved the total time it takes to get a response from the resolver and fetch a web page." Final post: https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-https-doh-update-detecting-managed-networks-and-user-choice/ https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-... "Furthermore, we found that web pages that are hosted by Akamai–a content distribution network, or “CDN”–have similar performance when DoH is enabled."
- gsich 7y ago
  And nowhere is "TCP" mentioned. I suppose the connection just builds up itself in 0ms time. Sure if you already have <5ms latency to your DNS, the additional RTT from TCP and TLS won't matter much. For the rest: they will.
  - jrwr 7y ago
    DoH can use UDP, but most dont, Also most people's local DNS (Here in America) Provided by their ISP is pretty shit. In my experience working at a MSP, having a local DNS server is always best

souterrain 7y ago

> Note that some countries have an underdeveloped ISP market, with large fractions of the population having no choice of broadband service provider. Regulation is then of the utmost importance to keep everyone honest, but in some of these countries the regulator has been captured by industry and is no longer very effective. This mostly goes for the US. I think this is the key motivator for a move to DoH. Large US ISPs can’t be trusted.

gsich 7y ago
>Large US ISPs can’t be trusted. But why trust Cloudflare?
- bepvte 7y ago
  A clear privacy policy and an third-party audit.
  - shkkmo 7y ago
    Provided in return for a competitive advantage and a reduction in network neutrality.
  - cremp 7y ago
    All ISPs have privacy policies. 99% of all privacy policies are either copy/pasted from elsewhere or written in legalese so that company can do whatever they want. 'Internal business use' is a nice fodder for 'Selling data to increase this general ledger account for later business use.' An audit is almost always under bad pretenses. If I spend $$$ on an audit company, the company itself has bias. The difference between third-party audits and government issued audits (think food safety) is that the government has nothing to gain by a positive, or negative result. IANAL, just cynical of people.
  - gsich 7y ago
    ISPs have those too (ISO 27001 is common). Again, why trust Cloudflare?

jannes 7y ago

While I disagree with Mozilla's decision to switch users to centralised DoH, I believe they are right in their assesment that the current DNS infrastructure is not very private. And something like DoH sounds pretty cool. Without encryption there are a few nefarious things ISPs can do quite easily: - transparent DNS proxies - DNS query tracking These things are pretty bad if you're affected, but I believe this shouldn't be addressed by centralisation of DNS.

stock_toaster 7y ago
I think Dns-over-TLS (DoT) is a much better solution. It seems super weird to me that Mozilla isn't pushing for that, and is instead pushing for DoH+cloudflare.

tptacek 7y ago

This is a disinformation campaign. DoH doesn't centralize DNS or DNS privacy. Anyone can run a DoH resolver server, and it'll do just as good a job as Cloud Flare's. The people crusading against DoH favor a different centralized DNS standard, DoT. DoT is DoH with essentially one difference, which is that it runs on its own port, so that network operators can block it. There's a sprawling cottage industry of security and analytics products that rely on passive DNS analysis to function, and people who sell those products or operate networks that use them have a strong disincentive to block DoT and require users to speak standard, plaintext DNS to servers they can monitor. Note however that once it's up and running, DoT is just as centralized as DoH is; it has to be, because it provides the exact same service model. Centralization and competition has nothing to do with their real concerns, or they'd be lobbying against DoT as well. I can't say I'm especially fond of Firefox's decision to default to Cloud Flare for its DoH resolver, because I loathe Cloud Flare. Google Chrome does something more sensible: it won't change your DNS server at all, but will upgrade you to DoH if your nameservers support DoH. You should use nameservers that do, because DoH is valuable: if you're in the US, your ISP is almost certainly passively monitoring and recording your DNS queries, and you shouldn't let them. Personal feelings about Cloud Flare aside, you are better off with them than with your US ISP's DNS servers. There's a strain of Unix sysadmin criticism against DoH that says it's wrong for browsers to co-opt DNS resolution at all, and that they should use the system's resolver. This is nonsense. First, almost no matter which browser you use, you should trust their DNS resolution code more than your operating system's; it will be more security-conscious and probably more performance-conscious code --- DNS resolution maintenance is the job you get on Microsoft or Apple's OS teams to punish you when you break the build. More importantly, as anyone who's ever had to mess around with libares will tell you, browsers have always needed better DNS resolution than libc offers, because they need fast async lookups. There's another strain of criticism against DoH that Unix nerds won't see much of but which is probably even more important to be aware of: there have been hearings in Congress about how DoH threatens law enforcement by depriving them of intelligence for investigations. Ultimately, this is of a kind with the DoT vs. DoH argument: the people lobbying against DoH simply don't believe DNS lookups should be private. Another "tell" that you're reading one of these people is when they start talking about how DNS privacy doesn't provide complete or perfect privacy --- that you shouldn't care if your DNS lookups are being monitored, because you're leaking so much information elsewhere. This is bamboozlement. DoH privacy is extraordinarily low-effort, actually modernizes the DNS protocol in some ways, and addresses a threat millions of users are directly facing right now. You should be wary of any outlet that promotes the meme that DoH is somehow shady.

fhrow4484 7y ago

I don't seem to understand the whole thing. To me the premises are: 1) we can't trust ISP with unencrypted DNS query 2) we can trust a third party with DNS query because those are encrypted. My questions are: - Why is 1 true? What are ISP doing with unencrypted DNS queries apart from knowing browsing habits? - With DoH do they not know your browsing habit anymore? - If there is a possible mitm attack with unencrypted, would it be fine if the ISP themselves ran a DoH server? - For the 3rd party: why would a 3rd party want to run a dns server for free? ISP run DNS server but customers pay a bill to them precisely to do things like this. in other words, in the long term, wouldn't it be a money sink for Cloudflare to run a DoH server? - Instead of just one DoH endpoint, could browsers take a list of DoH servers, and picking the best one in terms of p95 latency, with some round-robbin tries occasionally to verify if anything changes? This would solve the issue of one of the DoH service "having a bad day". Some amount of centralization would remain but based on an objective criteria (latency). (The article answers some of those questions and/or points out the same concerns)

musicale 7y ago

> We have to keep in mind that if a DNS lookup is slow, the entire internet feels sluggish. Slow DNS = Slow internet. Ridiculously low DNS TTL is an idiotic curse of the internet, but fortunately (and currently) one that can be (mostly) fixed locally.