> There is an assumption by many that DNS encryption requires DNS centralization.
A lot of the discussion recently, like this statement, conflates "DNS encryption" with "DoH". Encrypting DNS does not require centralization, but DoH does require[1] centralization in in the RFC. DoH doesn't even "improve user privacy"; it simply changes who can record your DNS queries. Instead of the ISP, Cloudflare/Microsoft/etc gets to see your unencrypted DNS queries.
The way to actually improve privacy is to perform the recursive resolution locally[2]. The actual communication with each individual DNS server needs to be encrypted, which is where work needs to be done. DNS servers need to support DNS over TLS (DoT) or some other type of encrypted transport. Hypothetically, DoH could be modified to support this, although that seems more complicated than simply wrapping the DNS protocol in TLS.
You don't get privacy by centralizing all of your requests onto one server. To protect privacy, you limit the data that any one party can see. DNS was designed for this purpose: only the NS record of a domain needs to be sent to a centralized server, which is easy to cache for a long time. Most requests then go to domain-specified authoritative server[4].
It's good to see Microsoft at least trying to address this at the OS level. App doing DNS without involving the OS seems to be more about taking away control from the user. I'm sure Google would love to be able top bypass DNS based adblocking.
> Encrypting DNS does not require centralization, but DoH does require centralization in in the RFC.
This isn't a problem that DoH was designed to solve. It is designed to be a highly compatible, secure, endpoint DNS solution. Which it is. So while this criticism is accurate, it is also irrelevant, DoH replaces one "hop" on DNS and that's all it was ever designed to do.
> DoH doesn't even "improve user privacy"; it simply changes who can record your DNS queries. I
It stops passive eavesdropping. Right now you can change who you use for DNS and your ISP can still monitor your DNS to profile you and invade your privacy. With DoH you can pick a privacy focused endpoint and nobody between you or that endpoint can trivially monitor your DNS.
DoT solves this too but has issues (see next response).
> DNS servers need to support DNS over TLS (DoT) or some other type of encrypted transport.
DoT and even unencrypted DNS is blocked on a lot of free WiFi. Now what? DoH solves this issue, as it was designed to. DoH can traverse even the most locked down network over the same HTTPS channel as any other web traffic.
> You don't get privacy by centralizing all of your requests onto one server.
Perhaps, but it scales really well and is the basis for all current DNS resolution. If everyone on the internet did as you suggested core internet infrastructure would fail under the load. You've essentially killed almost all caching.
> I'm sure Google would love to be able top bypass DNS based adblocking.
Google already does this with their Chromecast line of products.
Chromecasts will not adhere to your network's DNS servers, and will use Google's DNS servers. Chromecasts will fail to work at all if they cannot communicate with Google's DNS servers. If you try to redirect DNS traffic to the DNS servers of your choice, Chromecasts will not function. They won't work if you block Google's DNS servers, and you cannot change the DNS settings on the device itself.
DoH does not require centralization; rather, your linked argument redefines the term to include DNS servers that end-users run for themselves (they're "centralized" I suppose compared to a blockchain protocol?), which it obviously has to, because DoH obviously supports configurations where you run your own DoH resolvers that never speak to Cloud Flare.
I understand the approaches of DoT and DoH but people keep talking about privacy and tracking but it just seems like you can just run your own un-DNS server and get the same info by looking up the IP to get the DNS. You can still be monitored and controlled by IP, right?
You could use k-Anonymity to request a handful of results, without the dns server knowing which result you were looking for. hash the hostname, return all results that have the same x letters as the beginning of the hash. at no point, would the actual site you are requesting leave your lan. your dns resolver would know within 1/400th (how every many results it replies with) which site you were asking for. After time, and recording patterns, they might be able to make educated guesses of which site you were requesting, but it would not be concrete evidence.
Running your own recursive resolver at home isn't the solution, because it reveals to eavesdroppers what DNS servers you're talking to and it reveals to DNS operators what your IP is.
Maybe it's the best current compromise, but it would be better to have a shared and trusted remote recursive resolver which many people talk to.
The reason why the ISPA did not like DoH is because UK law said they had to block/filter traffic. Per court order, a UK ISP would be obliged to block things, and if DNS was no longer an option, they would potentially start having to do IP blocking and BGP sink holing (PDF warning):
While I'm sure the ISP techs may have had some misgivings about DoH (plenty of tech-mind folks like Paul Vixie do), the strong response from the ISPA may have been guided by the lawyers.
Read the article. Unlike Mozilla's approach, Microsoft's DoH rollout is intentionally designed to not bypass DNS-based filtering. ISPA shouldn't have any problem with what Microsoft is doing.
I guess that is the end of the naysaying really; if the underlying OS supports DoH then browsers can use the settings of that resolver if present and rely on them instead of having to manually do it.
On another note; I like the principles laid out in the article, they do reflect how I'd want a system to act in the presence of DoH servers.
I bet the steps forward will be to test if the DHCP Server configured is capable of DoH and if it is, then using it only over DoH on that network. A second thing might be if DHCP or RA's learn a new flag that indicate the resolver uses DoH upstream or supports DoH itself.
The whole “naysaying” (as you so insultingly put it) was never against encryption.
It was always about putting the user, the OS and network-operator in control of their own infrastructure, something the DoH-crowd dismissed entirely as a valid concern.
So now that Microsoft has just provided that control, sure we’re happy.
But don’t act like the complaints made by the “naysayers” weren’t 100% valid. The DoH-crowd was short-sighted, enclosed in their own echo-chamber and didn’t listen to feedback or criticism.
This probably hurt DoH long term more than anything else.
Now it’s by default “tainted” technology and people have already created and deployed firewalling solutions to block it. Those solutions are probably going to stay in place.
Well, it certainly changes the equation from being a rogue element on a network to something that is just another management setting. I won't be truly happy until I can setup a DoH server of my own. Does anyone know if there is any value to adding DoH to the external servers that are only used by other name servers? Will anyone's name servers do their lookup with DoH?
The less the outside world knows about what's on a private network the better. Information leaking be it the processor or to someone's servers is just another problem waiting to happen.
Currently DNS filters and hosts files are a good way to block trackers and telemetry.
By securing this using HTTPS, we are not far from closing another loophole for user freedom: What if Chrome does not allow self signed PKI roots anymore? On Android one already gets a scary message each day when installing a root certificate
The other scary consequence of these changes that you have even less control over your network than before. You can bring devices into your home and have absolutely no control or knowledge of what they are connecting to or what they are doing.
It's also a problem for obsolesce of cloud connected devices; I'm not able to, even if technically possible, to replace the cloud services some of my devices connect to because of certificate validation and encryption.
This is software running on a users' computer. They will always have the opportunity to modify their configuration (or patch the running software if needed). The argument that DoH is a step backwards doesn't make sense, since it's always been possible for software that wants to circumvent hosts file / DNS filters to use an alternate name resolver.
I agree that we should push for more configuration options, but the fact remains that it's the users decision to run software that doesn't respect their freedom of choice, and ultimately they control the code that runs on their machine.
DoH is overall a huge benefit to preventing in-flight tampering and protecting user privacy. The net-benefits far outweigh the downside that "good" network providers can no longer tamper with DNS results.
We support strong widely available encryption even though it enables terrorism, weapons dealing, human trafficking, etc. But when it enables the delivery of hard-to-block ads, that's too far?
In my opinion it was wrong to go down the path of using DNS for content blocking in the first place. Even without widely available DoH, bypassing dns-based content blocking is trivial.
You'll still be able to run your own resolver that applies DNS filters and configure your client to use it, just like today. The difference will be that connections between the client and the resolver will be secured with HTTPS, so your DNS can only be tampered with and surveilled if you give consent. That seems like a win for user freedom to me.
DoH provides a way for programs to do DNS lookups while evading any attempts at blocking certain DNS lookups.
This is a dream situation for advertisers and enforced telemetry. This is also why the existence of DoH has made it necessary for me to install a MITM HTTPS proxy in my network, so that I can regain control.
DoH brings some privacy benefits, but it also brings privacy costs. It is not an unambiguous win -- it is a tradeoff.
If you are a stubborn troglodyte like me and have your own secure DNS solution in place, then you can add the following domain to your local DNS to always NXDOMAIN: use-application-dns.net to tell the resolver to use local network DNS settings. And then of course, null route all the DoH resolvers.
I am somewhat curious what the fallout would be if ISP's decided to NXDOMAIN that domain. Would they get in any trouble?
If your DNS server doesn't easily allow you to return an NXDOMAIN (the DNS server in Windows Server is this way, for example) you can also just create an empty zone for "use-application-dns.net". As long as no "A" or "AAAA" records are returned the conditions for the canary will be satisfied.
I added that after I read about it from mozilla. Is there cross-vendor support for that same canary? It would be nice if implementers standardize on that.
Mozilla stated previously that if the bypassing was "abused" (such as by ISPs), they'd effectively just ignore it (paraphrasing) and continue to use DoH anyways.
Why are Microsoft doing this? One explanation is morality - they are doing it for the greater good. Another explaination is branding - they want to look like the new "no evil company" which ties in with their open source initiatives. It could also be a way to prevent Google having too much power which is a good thing for Microsoft. It also might be to sell more Windows licences, but I doubt this would factor into the decision about what OS to use. Or it is just that technical people got to make the decision unhampered by management, and technical people value privacy.
Can anyone expand on what advantage HTTPS has over raw SSL/TLS? Why tunnel over another application-level protocol? What's the value-add of throwing GET and POST etc into the mix?
Truth be told, I don't even really understand why we didn't adopt "DNSs" decades ago along with HTTPS. Encrypt at socket level, done. What's the catch?
>Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing [...]
It's actually quite simple: DoT runs over a separate TCP port and is trivial for network operators to filter, and DoH is deliberately more tricky to filter; it's designed to provide a measure of DNS privacy even on networks that users don't totally trust.
DoT is DoH with a kill switch for network operators.
> However, since these servers and their DoH configurations are well known, Windows can automatically upgrade to DoH while using the same server.
They are not well known. How do they know my DNS server is DoH? It's good that, like Chrome and unlike FF, they plan on using the existing DNS servers but are they also using a known whitelist of DoH servers? How can I get on there?
We need an HSTS/Alt-Svc for DoH...can't I return an EDNS response or something w/ my standard DNS response that says I support DoH and the clients use it henceforth while it remains the same configured server? Maybe even a default domain to check DoH support even on NXDOMAIN so it doesn't leak the first domain requested in clear UDP.
I suppose with DNS level blocking of ads now impossible that means I will need to crawl my DNS blocklist and resolve those domains, then block those IP addresses at the network gateway... Even if clients punch out through a secret DoH ip those resolved advertiser domains will still be null routed.
>DNS traffic represents a snapshot of the user’s browsing history
This is what the Mozilla Corporation didn't get when they decided to send by default all the DNS traffic to Cloudflare. Or, perhaps, they did get it right...
I have a few VMs that run all my networking services. One of them runs cloudflared and Pihole. Cloudflared is a DNS server that routs all DNS queries to 1.1.1.1 using DoH. I have Pihole configured to use cloudflared as its upstream DNS. So in addition to the Pihole's ad/tracker blocking, all DNS requests leaving my network are done over DoH regardless if clients actually support it.
If taking safest in the most literal sense, and you trust PCH/IBM, then Quad9 is a pretty good choice for most people.
Unlike normal DNS, Quad9 purposely does not resolve threatening results. If you view "safest" more to mean "prevents the spread of malware, keeping everyone safer" than "gives me absolute privacy I can audit" then it's hard to beat. They do log data at the city/metropolitan level for threat analysis. It's one of the few services that supports DoH, and Chrome already automatically upgrades requests when it detects you using Quad9.
This is the correct approach, and I'm glad to see Microsoft is taking the lead here.
The operating system should support DoH. Any browser not respecting the operating system's DNS configuration should rollback their plans to hijack DNS requests (particularly Firefox) and entrust the network stack to the OS, as is intended.
[+] [-] pdkl95|6 years ago|reply
A lot of the discussion recently, like this statement, conflates "DNS encryption" with "DoH". Encrypting DNS does not require centralization, but DoH does require[1] centralization in in the RFC. DoH doesn't even "improve user privacy"; it simply changes who can record your DNS queries. Instead of the ISP, Cloudflare/Microsoft/etc gets to see your unencrypted DNS queries.
The way to actually improve privacy is to perform the recursive resolution locally[2]. The actual communication with each individual DNS server needs to be encrypted, which is where work needs to be done. DNS servers need to support DNS over TLS (DoT) or some other type of encrypted transport. Hypothetically, DoH could be modified to support this, although that seems more complicated than simply wrapping the DNS protocol in TLS.
You don't get privacy by centralizing all of your requests onto one server. To protect privacy, you limit the data that any one party can see. DNS was designed for this purpose: only the NS record of a domain needs to be sent to a centralized server, which is easy to cache for a long time. Most requests then go to domain-specified authoritative server[4].
It's good to see Microsoft at least trying to address this at the OS level. App doing DNS without involving the OS seems to be more about taking away control from the user. I'm sure Google would love to be able top bypass DNS based adblocking.
[1] https://news.ycombinator.com/item?id=21110296
[2] Which is easy: follow NS records until you get to the server that has your authoritative answer.
[3] https://news.ycombinator.com/item?id=21348328
[+] [-] Someone1234|6 years ago|reply
This isn't a problem that DoH was designed to solve. It is designed to be a highly compatible, secure, endpoint DNS solution. Which it is. So while this criticism is accurate, it is also irrelevant, DoH replaces one "hop" on DNS and that's all it was ever designed to do.
> DoH doesn't even "improve user privacy"; it simply changes who can record your DNS queries. I
It stops passive eavesdropping. Right now you can change who you use for DNS and your ISP can still monitor your DNS to profile you and invade your privacy. With DoH you can pick a privacy focused endpoint and nobody between you or that endpoint can trivially monitor your DNS.
DoT solves this too but has issues (see next response).
> DNS servers need to support DNS over TLS (DoT) or some other type of encrypted transport.
DoT and even unencrypted DNS is blocked on a lot of free WiFi. Now what? DoH solves this issue, as it was designed to. DoH can traverse even the most locked down network over the same HTTPS channel as any other web traffic.
> You don't get privacy by centralizing all of your requests onto one server.
Perhaps, but it scales really well and is the basis for all current DNS resolution. If everyone on the internet did as you suggested core internet infrastructure would fail under the load. You've essentially killed almost all caching.
[+] [-] heavyset_go|6 years ago|reply
Google already does this with their Chromecast line of products.
Chromecasts will not adhere to your network's DNS servers, and will use Google's DNS servers. Chromecasts will fail to work at all if they cannot communicate with Google's DNS servers. If you try to redirect DNS traffic to the DNS servers of your choice, Chromecasts will not function. They won't work if you block Google's DNS servers, and you cannot change the DNS settings on the device itself.
[+] [-] tptacek|6 years ago|reply
[+] [-] ryan_hallinger|6 years ago|reply
[+] [-] snarf21|6 years ago|reply
[+] [-] basch|6 years ago|reply
https://blog.cloudflare.com/validating-leaked-passwords-with...
[+] [-] akvadrako|6 years ago|reply
Maybe it's the best current compromise, but it would be better to have a shared and trusted remote recursive resolver which many people talk to.
[+] [-] sb057|6 years ago|reply
https://www.ispa.org.uk/ispa-announces-finalists-for-2019-in...
[+] [-] throw0101a|6 years ago|reply
* https://www.icann.org/sites/default/files/packages/ids-2019/...
That law now seems to be dead, which may reduce their worries on the matter:
* https://arstechnica.com/tech-policy/2019/10/uk-government-ab...
While I'm sure the ISP techs may have had some misgivings about DoH (plenty of tech-mind folks like Paul Vixie do), the strong response from the ISPA may have been guided by the lawyers.
[+] [-] agwa|6 years ago|reply
[+] [-] ryan_hallinger|6 years ago|reply
[+] [-] zaarn|6 years ago|reply
On another note; I like the principles laid out in the article, they do reflect how I'd want a system to act in the presence of DoH servers.
I bet the steps forward will be to test if the DHCP Server configured is capable of DoH and if it is, then using it only over DoH on that network. A second thing might be if DHCP or RA's learn a new flag that indicate the resolver uses DoH upstream or supports DoH itself.
[+] [-] josteink|6 years ago|reply
The whole “naysaying” (as you so insultingly put it) was never against encryption.
It was always about putting the user, the OS and network-operator in control of their own infrastructure, something the DoH-crowd dismissed entirely as a valid concern.
So now that Microsoft has just provided that control, sure we’re happy.
But don’t act like the complaints made by the “naysayers” weren’t 100% valid. The DoH-crowd was short-sighted, enclosed in their own echo-chamber and didn’t listen to feedback or criticism.
This probably hurt DoH long term more than anything else.
Now it’s by default “tainted” technology and people have already created and deployed firewalling solutions to block it. Those solutions are probably going to stay in place.
[+] [-] numlock86|6 years ago|reply
[+] [-] protomyth|6 years ago|reply
The less the outside world knows about what's on a private network the better. Information leaking be it the processor or to someone's servers is just another problem waiting to happen.
[+] [-] atesti|6 years ago|reply
[+] [-] wvenable|6 years ago|reply
It's also a problem for obsolesce of cloud connected devices; I'm not able to, even if technically possible, to replace the cloud services some of my devices connect to because of certificate validation and encryption.
[+] [-] jbott|6 years ago|reply
I agree that we should push for more configuration options, but the fact remains that it's the users decision to run software that doesn't respect their freedom of choice, and ultimately they control the code that runs on their machine.
DoH is overall a huge benefit to preventing in-flight tampering and protecting user privacy. The net-benefits far outweigh the downside that "good" network providers can no longer tamper with DNS results.
[+] [-] shawnz|6 years ago|reply
In my opinion it was wrong to go down the path of using DNS for content blocking in the first place. Even without widely available DoH, bypassing dns-based content blocking is trivial.
[+] [-] agwa|6 years ago|reply
[+] [-] chopin|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] JohnFen|6 years ago|reply
This is a dream situation for advertisers and enforced telemetry. This is also why the existence of DoH has made it necessary for me to install a MITM HTTPS proxy in my network, so that I can regain control.
DoH brings some privacy benefits, but it also brings privacy costs. It is not an unambiguous win -- it is a tradeoff.
[+] [-] LinuxBender|6 years ago|reply
I am somewhat curious what the fallout would be if ISP's decided to NXDOMAIN that domain. Would they get in any trouble?
[+] [-] EvanAnderson|6 years ago|reply
[+] [-] asveikau|6 years ago|reply
[+] [-] jlgaddis|6 years ago|reply
[+] [-] mc3|6 years ago|reply
[+] [-] zeruch|6 years ago|reply
[+] [-] dTal|6 years ago|reply
Truth be told, I don't even really understand why we didn't adopt "DNSs" decades ago along with HTTPS. Encrypt at socket level, done. What's the catch?
[+] [-] dqv|6 years ago|reply
>Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing [...]
[0]: https://tools.ietf.org/html/rfc8484#page-3
[+] [-] tptacek|6 years ago|reply
DoT is DoH with a kill switch for network operators.
[+] [-] zokier|6 years ago|reply
https://tools.ietf.org/html/rfc7858
[+] [-] jlgaddis|6 years ago|reply
I'd prefer DNS-over-TLS myself but apparently DNS-over-HTTPS has more backing and is "winning".
One big advantage that is argued is that DoH is much harder to block.
[+] [-] kodablah|6 years ago|reply
They are not well known. How do they know my DNS server is DoH? It's good that, like Chrome and unlike FF, they plan on using the existing DNS servers but are they also using a known whitelist of DoH servers? How can I get on there?
We need an HSTS/Alt-Svc for DoH...can't I return an EDNS response or something w/ my standard DNS response that says I support DoH and the clients use it henceforth while it remains the same configured server? Maybe even a default domain to check DoH support even on NXDOMAIN so it doesn't leak the first domain requested in clear UDP.
[+] [-] judge2020|6 years ago|reply
0: https://github.com/chromium/chromium/blob/711b1ba2735f8af4bd...
[+] [-] cm2187|6 years ago|reply
[+] [-] hiccuphippo|6 years ago|reply
[+] [-] iramiller|6 years ago|reply
Not as easy but just as effective.
[+] [-] ggzgd|6 years ago|reply
This is what the Mozilla Corporation didn't get when they decided to send by default all the DNS traffic to Cloudflare. Or, perhaps, they did get it right...
[+] [-] 2bitencryption|6 years ago|reply
I.e. what's the best I can do, short of hosting my own DNS?
[+] [-] babypuncher|6 years ago|reply
[+] [-] basch|6 years ago|reply
Unlike normal DNS, Quad9 purposely does not resolve threatening results. If you view "safest" more to mean "prevents the spread of malware, keeping everyone safer" than "gives me absolute privacy I can audit" then it's hard to beat. They do log data at the city/metropolitan level for threat analysis. It's one of the few services that supports DoH, and Chrome already automatically upgrades requests when it detects you using Quad9.
https://www.quad9.net/policy/
[+] [-] josteink|6 years ago|reply
[+] [-] ocdtrekkie|6 years ago|reply
The operating system should support DoH. Any browser not respecting the operating system's DNS configuration should rollback their plans to hijack DNS requests (particularly Firefox) and entrust the network stack to the OS, as is intended.
[+] [-] m0xte|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] andrewstuart|6 years ago|reply
Long awaited and MUCH needed for privacy.
This is the primary way in which your privacy is invaded.
Where is Apple on this?
[+] [-] auslander|6 years ago|reply
[deleted]