Windows will improve user privacy with DNS over HTTPS
techcommunity.microsoft.com
techcommunity.microsoft.com
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.
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.
Even with the DoH which site you access is still trivially to track by your ISP and anybody along the wire as the site name is still not encrypted in the TLS connection traffic.
Encrypted SNI is solves exactly that and is becoming increasingly common.
None of these solutions work individually to solve privacy problems but all of them together are substantially increasing the cost and decreasing the accuracy of profiling users on-mass.
DoT never gained widespread adoption as an endpoint solution due to compatibility problems. It is technically the superior choice (Vs. DoH), but what good is superior if it breaks all the time? DoH is more imperfect but actually works reliably across different network configurations and client devices, which means it "wins" even if it is "worse."
Can you please elaborate? I know only this:
https://serverfault.com/questions/976377/how-can-i-set-up-en...
"Encrypted Server Name Indication (ESNI) is still an Internet Draft, you will not find it in any major server implementation as it is subject to change. In fact, the draft version implemented by Firefox supports draft-ietf-tls-esni-01 which is incompatible with newer draft versions."
Edit: I see Firefox Nightly is mentioned, it is the version that normal users who use Firefox (Firefox has at the moment less than 5% worldwide marker share) just don't use (it annoyingly updates every night).
That means over 10% of the internet's traffic supports ESNI (even if <1% of clients consume it regularly). We're also seeing additional vendors explore ESNI, including Chrome's team who have said they will look into implementing it when the spec is finalized.
I have not heard of any compatibility problems with DoT. Do you have any references?
I have written a DoH + DoT server https://github.com/fanf2/doh101 which I am running in production. DoT is popular, DoH is basically only used by me.
Do you know why Tor exists? Because things like DoH don't stop passive eavesdropping, and DoH in particular only leaks information to more parties, without stopping any eavesdropping whatsoever. I guess it's easy to confuse, thinking that DNS is some private data, but DNS is not even data, it's metadata and other sources of metadata leak much more information than DNS and let build much more detailed profile on you. For example, almost all of the top million websites are uniquely identifiable just by looking at IP addressed in IP packets, as page loads force browsers to make requests to many different IPs and give sort of fingerprints of visits. Nothing short from decentralized overlay network can help with that.
> DoT and even unencrypted DNS is blocked on a lot of free WiFi. Now what? DoH solves this issue, as it was designed to.
No, it was not designed to solve that issue. It was designed to tunnel and control DNS traffic by a corporation. Mozilla eventually agreed to provide a convenient way to block DoH as well as DoH providers agreed to be blockable. So you should expect DoH to be equally or even more blocked everywhere, where DoT is blocked.
You know there are plenty of papers on privacy. No need to repeat all that false propaganda from corporations.
Given there is a virtually unlimited number of DoH servers you can trust available. With only a couple of servers available it is easy to block them.
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.
I don’t know enough about DNS, but I’m wondering if we could somehow fit BitTorrent into the mix for the home resolver?
Yes, they (probably the ISP) can do traffic analysis - which is a significant risk - but they are prevented from learning the contents fo the query which puts a limit on what they can learn. Also, the same eavesdroppers can see the TCP connection to the HTTPS server that follows he DNS request.
Also, I should have mentioned that while performing recursive resolution locally does provide some actual privacy protections, it is not perfect. Name resolution as a distributed database fundamentally requires leaking some information to the servers that have the information. As long as we resolve names with anything similar to existing DNS, the best we can do is try to limit the damage to privacy. In a perfect world, we would probably use something similar to TOR to perform name resolution. Lots of inputs that onion-route queries to the actual nameservers.
> it reveals to DNS operators what your IP is.
Revealing my IP to ns.example.com is redundant when I'm almost certainly following the DNS request with a connection to www.example.com; the authoritative server for a domain is controlled (directly or indirectly) by the same org that controls the domain's HTTPS/etc servers.
Every few days/weeks the tld gets a single query that tells them you were making some sort of request so an unknown domain anywhere in queried delegation. That query only includes the 2nd level domain and a request for that domain's nameserver(s). The rest of the recursive resolution and most future queries only need to involve the domain's nameserver.
Yes, some information is leaked. This is unfortunate, but there is a huge difference between leaking that you occasionally visit something at exsmple.com and leaking your pattern of life (the exact subdomains you visit with ~minute-ish granularity).
https://blog.cloudflare.com/validating-leaked-passwords-with...
P(d|x) = P(x|d) * P(d) / P(x)
P(x|d) is 1 in this case (the hash is deterministic), so the probability is just P(d)/P(x). E.g. if "facebook.com" doesn't have a hash collision with another similarly popular site, then you can be pretty sure that a request for hash("facebook.com") is a request for "facebook.com" for a high proportion of requests.
This also adds some overhead. E.g. 400 IPs+TTLs probably wouldn't fit in a 1500 MTU packet, so it might have to be split up or k reduced to fit.
From the ISP perspective, they can also tell which of the k you were interested in because you will probably send a SYN packet to that IP address. Unless you also send 400 SYN packets...
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.
* https://mailarchive.ietf.org/arch/msg/dnsop/WCVv57IizUSjNb2R...
https://www.ispa.org.uk/ispa-announces-finalists-for-2019-in...
> We can start seeing the challenges in enforcing the line on preferring resolution failure to unencrypted fallback. In line with principle 4, this DoH use will be enforced so that a server confirmed by Windows to support DoH will not be consulted via classic DNS. If this preference for privacy over functionality causes any disruption in common web scenarios, we’ll find out early.
* 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.
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.
It's the same with deal with HTTP and HTTPS basically: The server tells me if HTTPS is supported or not. (Yes, there is HSTS but that's a different story ...)
Most DoH servers, AIUI, use the same well-known path, so we'd simply need two more DHCP options: one for the DoH server's hostname and another for the path.
There's no reason something like this couldn't easily be added to the DHCP specification and, at some point, I expect it will... everyone will come together to agree on the details and we'll end up with a new/updated RFC.
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.
DoH is only focusing to encrypt the first hop for now as it was easiest to hit and where the majority of the problem is.
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.
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.
If I'm aware of terrorism, weapons dealing, human trafficking, etc., traffic on my network, I'd certainly block that. That's a different issue from crypto.
Also, I'm not so interested in blocking advertising anyway. I'm interested in blocking unauthorized data leakage (tracking, telemetry, etc.)
> In my opinion it was wrong to go down the path of using DNS for content blocking in the first place.
It has never been an awesome approach, true, but it's often the only approach available.
> Even without widely available DoH, bypassing dns-based content blocking is trivial.
Possible, yes. Trivial, no.
Not really, because you have no way to enforce the use of your own resolver or filters without using a proxy to MITM your HTTPS connections.
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.
The reason we even want DoH is because we don't want others to control and filter our DNS queries at their gateway when we are on their network.
For this concern to make sense, you have to imagine threat actors determined enough to do bad things if they can look up hostnames with your standard DNS, but not determined enough to use some alternative lookup or C&C mechanism if standard DNS isn't available. Who are those threat actors? If they're browser-resident --- which they have to be if Firefox defaulting to DoH is your big concern! --- why can't they just do their own DoH regardless of what Firefox decides to do?
Any app that includes an advertising or telemetry SDK? App developers will appreciate the ease of just adding a library that from user's point of view is malicious, but neither the app developers nor the SDK vendors will likely want to bother with building and maintaining their own name resolution scheme.
If you consider advertising and telemetry to be hostile actions (as many here, myself included, do), the space of threat actors expands to encompass a large amount of "cooperative hostile programs".
Actually, I think it's the most common threat model these days. Viruses/Trojens? I haven't had one in years. I remember getting rooted on my first Linux box hours after connecting to the Internet -- that doesn't happen anymore either.
Instead, all the threats are cooperative hostile programs from my search engine, my television, my apps, etc.
> You have to imagine threat actors determined enough to do bad things if they can look up hostnames with your standard DNS, but not determined enough to use some alternative lookup.
But most of these bad actors don't believe they're doing anything bad. This is just the normal accepted operation of their software. Operating according to the normal and expected way that Internet applications are supposed to work. If a few "techie geeks" find a way around it so be it. The alternative methods you describe are just another point of failure.
--
We're moving towards a model where you have absolutely no knowledge or control of what goes through your network anymore. It used to be I could monitor and even re-write any IP traffic on my network to my hearts content through my Linux router but I can't do that anymore. DoH is just one piece -- perhaps the final piece -- that makes this transformation complete.
If it's a device on your network that you don't control, the problem is that you don't control or trust a device you've plugged into your network.
Either way: DoH is a red herring. It's making you aware of a problem you most definitely already had with untrusted devices, while mitigating another problem you had in your browser. Firefox didn't enable DoH in your Chromecast or whatever, and if DoH didn't exist, your Chromecast could (and should) have done something like DoH anyways.
Honestly, and I know I lose credibility by being intemperate enough to say this, I think people freaking out about DoH and all the low-rent control of low-rent bad-ware that it breaks need to grow up and either take the problems they're talking about seriously, or recite the Serenity Prayer and let it go.
Except if that computer is in your TV, or is in an iOS-based device, or in another piece of hardware.
> The problem is that you don't control or trust a device you've plugged into your network.
Yes. I would like to use the device and filter out any of its harmful effects -- the best of both worlds really. Same reason I run an ad-blocker on my browser.
> Either way: DoH is a red herring.
I agree. My point was not to single out DoH in this scenario. It's just one more way in which we've lost control of our local network. When it's not our network, it's a benefit. The same reason why use we SSL.
> It's making you aware of a problem you most definitely already had with untrusted devices
Oh definitely. We used to have at least this as a last line of defense. And now we won't. I think it's good to be aware of that. I'm not saying that we shouldn't use DoH or the benefits don't outweigh the costs -- but it should be noted that there are costs.
Honestly, I never considered the personal costs of all these good security practices until a cloud hardware device I own had the company go out of business. Their security was very good -- all SSL, pinned certificates, etc. There's no way to emulate the cloud services it connects to because there's no way it will connect to anything other than it's own services. It's just a black box on my network. I can see what DNS queries it uses but that's not very much help...
This is a problem, yes. We should fix that problem.
>It's just one more way in which we've lost control of our local network. When it's not our network, it's a benefit. The same reason why use we SSL.
I think part of the reason why I'm in favor of things like DoH and SSL everywhere is there are very few cases nowadays where services are running entirely on a local network. The vast majority of things that people do on networks now touch the internet.
>I would like to use the device and filter out any of its harmful effects ... We used to have at least this as a last line of defense. And now we won't.
Except that "last line of defense" was always an illusion; as tptacek mentioned, malicious devices have always been able to perform encrypted DNS lookups if their developers really wanted to. DNS filtering was never a reliable defense.
You still do have IP blocking as a last line of defense, and that _is_ reliable considering nothing's going to get routed through the internet without being in an IP packet.
>I never considered the personal costs of all these good security practices until a cloud hardware device I own had the company go out of business.
My recommendation: if it depends on someone running something out on the internet to function, avoid it like the plague. The service _will_ shut down, it's just a matter of time, and IMO it's a waste to buy something that could turn into an expensive paperweight at any time.
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.
And it's always been possible to block access to all DNS resolvers except your local one. Until now.
> the fact remains that it's the users decision to run software that doesn't respect their freedom of choice
Unless that code is malware or some Javascript an advertiser has placed on a website. There is no way to stop software from doing its own DoH requests without using browser or OS services to do it, so the controls supplied by the browser or OS are of rather limited value.
> The net-benefits far outweigh the downside that "good" network providers can no longer tamper with DNS results.
I disagree. I'm of the opinion that DoH brought with it a security problem that is difficult to resolve. It does provide additional security in another area, but that's not something that couldn't have been done using a more reasonable approach that didn't hamper my ability to control what's happening on my own machines.
This is true irrespective of DoH. If software wants to ignore the OS settings and resolve names down via its own custom protocol, that's what it's going to do. Short of auditing that software and it's connections, you can't really stop it.
The OS settings are not a control, they're a convenience.
How do you distinguish, at a technical level, your ability to control what's happening on your own machines versus someone else's machines? Assuming that you're referring to using your control over the network, and given that it's very common for people to connect to networks controlled by entities they don't trust.
I don't need to distinguish between the two because I'm talking about my own network and machines, not other people's.
I don't buy it. Even if you do route all DNS through a resolver on your router, that's hardly "protected", unless that resolver is itself using DNS over HTTPS (or TLS). Do you trust your ISP? I don't, and like most of the US I'm not in much of a position to switch. But even if I did trust my ISP, I wouldn't trust that the entire path from me to whatever DNS server the router is contacting (whether it's a recursive resolver or an authoritative one) was free of intelligence agency taps. In fact it seems much more likely that there is a tap somewhere.
The vast majority of people can't do that, if only because getting a reasonable experience from most websites today means allowing arbitrary code (Javascript) to be executed on your machine.
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.
My bigger issue with this is that Microsoft is trying to paint themselves as an angel when in reality, as part of Windows 10, they've added so much telemetry, it feels as if they're closer to an ad giant than a software giant.
Specifically, ISPs are unable to read the requests or responses of your DNS requests due to end to end encryption between the client and the DNS server.
Now, you need MITN on your home network or you block everything to google.dns:443... but what if they rotate their DoH resolvers?
DNS by nature must be static. Unless something changes you certainly can block DNS addresses, and you can block it indiscriminately on all ports. I don't care what port or protocol used if my non trusted devices contact 8.8.8.8 on any port.
If you rotate your resolvers, you'll have to push out a software update to update the DNS servers, which takes time and money.
The DNS content filtering ship has sailed. It was nice while it lasted.
Yes, but you have no way to force software to use your local DoH resolver.
If software is doing a lookup via DoH, you have no way of knowing that's happening, let alone be able to do anything about it, without MITMing your HTTPS connections.
You could, of course, block all requests to public DNS servers, but that's of limited use (do you even know all the public DNS servers in the world?), can cause unacceptable collateral damage, and the fallback of malicious code would probably be to use a private DoH resolver that you don't know about.
> they will automatically go through the DNS server you've served using DHCP.
This would only be true if the software is using the operating system or browser to do the lookups. If the software is doing the lookups itself without involving the OS or browser (which is trivial to do), then the behavior will be whatever the dev of the malicious code wants it to be.
So yes, it was always possible, but was never common.
The DoH RFC removes all of those speedbumps. A malicious actor can just use DoH resolvers run by normal, established DNS providers. That makes it cheap and easy to implement, and makes it very difficult for you to block without causing a lot of collateral damage.
I was referring to the ability of code to use HTTPS to do DNS lookups even in the absence of DoH, which is what I thought you were talking about.
"Speed bump" is the right term, because while doing something like that has always been possible, it was more expensive (in terms of development costs and server time) and brittle before the DoH RFC, which limited the number of entities that do it.
With the DoH RFC, those limitations are removed, so we can expect this to be widely done.
By "this", I mean using DoH in order to intentionally evade attempts to block lookups in order to help protect against telemetry, user tracking, and other malware communications.
Once DoH (and certificate pinning to go along with it, to prevent you MiTM'ing the requests) is pervasive you won't get to control DNS on devices where you can't execute arbitrary code. That ship has sailed. It fills me with a deep sadness and frustration, but that's the way it will be.
(I went back and forth with tptacek on this in an earlier discussion. I didn't really have an argument, per se, but he demolished it anyway.)
Get ready for browsers (that run inside your browser) implemented in WASM complete with their own DoH implementation, too. It's a publisher's dream come true...
I'm explicitly not making an argument about code running on general purpose computers that I (ostensibly) own and control. The WASM/browser comment I made was a flippant jab (though I absolutely think it will happen) and absolutely a separate issue.
I'm one of those people who think the web should have stayed more like Gopher and less like Java. I'm a nut-job who browses w/ Javascript disabled by default. I think it's ridiculous that I need to run a VM for third-parties to jam arbitrary code into so I can read articles. Yes-- third-parties could always run arbitrary code on my computer. In the past they had to convince me to install their software. Now visiting their website is, effectively, installing software.
I'd be interested to hear how you square the circle of controlling your own computing experience in the face of near-requirement of allowing websites to execute arbitrary code on your computers.
re: DoH
People are clearly used to using DNS-based filtering tools to control network traffic (the "Pi Hole", Cisco's Umbrella product, creating empty zones in self-hosted recursive resolvers to prevent unwanted domains from resolving, etc). I don't think the people who use these tools understand that DoH creates an easy standards-based way for that control to be removed.
I wholeheartedly agree that DNS filtering wasn't absolute control, but it was a degree of control. Yes-- bad actors could always have made up their own name resolution protocols, their own encrypted command-and-control channels, etc. Most of them just used DNS.
Having control of DNS to do filtering was something, clearly.
The last exchange I had w/ you set my mind straight. The control that DNS filtering provided was a comfortable illusion. It existed because Internet protocols were designed with too much trust to begin with, and because it was easier and more cost effective for developers to use standards-based protocols (at the expense of their traffic being vulnerable to tampering).
The world, as it is now, won't work w/ unscrupulous entities exploiting the trust engineered into early protocols. I don't want my ISP "monetizing" my DNS traffic, injecting content into my HTTP sessions, etc. Removing the ability of unscrupulous network operators to use my traffic against me means removing my own ability to influence that traffic to my own benefit.
This isn't entirely the case. I have regained this control on my own machines by implementing a proxy that MITMs all HTTPS connections that happen over my network.
Certificate pinning won't allow this to be evaded -- all it will do is prevent the HTTPS connection from being established.
All devices that I use, including remote ones, only connect to the internet through a VPN that I run in my network, so they are all MITMd as well.
That's not a solution that everyone can pull off, and it's not a solution that I'm happy with (because I'm introducing a weakness in the security chain), but it's the best one I could think of.
I am somewhat curious what the fallout would be if ISP's decided to NXDOMAIN that domain. Would they get in any trouble?
I for one welcome the new competitive facade of privacy and security. Minor improvements are at least improvements.
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 [...]
As for web apps... well, that's horrifying enough to be the real reason. Javascript should not be running its own DNS queries, outside of the system DNS settings - it's a layering violation that looks a lot like an end run around the "user agent" concept (i.e. the web app, rather than the browser itself, is the "trusted endpoint" and the user is considered an adversary). If web browsers actually wanted such functionality to be available, they could easily expose an API for it.
What justifications for this exist?
DoT is DoH with a kill switch for network operators.
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.
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.
0: https://github.com/chromium/chromium/blob/711b1ba2735f8af4bd...
Not as easy but just as effective.
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 hope more DNS servers support DNS over HTTPS soon because my options for using it are:
- CloudFlare - self hosted with CloudFlare's code
Not a lot of options there...
https://git.shivering-isles.com/container-library/dns-over-h...
It's not that complicated to run DoH, one just has to do it.
I have not relationship with Cloudfare. I don't want them to have data about me. I never signed a contract with them.
You must be one of the lucky few.
Depending on the regulations (this is true some of the EU)
On the other hand, Cloudflare has larger customers who also often have an interest in your privacy (the services you are using). And CloudFlare isn't a government granted monopoly, so both their customers and their users have more ability to switch.
The last mile fibre is provided by a company called OpenReach. I don't deal with them, they sell the service to the ISPs at a regulated wholesale price, it's those ISPs that add their services (like IP connectivity, transit, etc) onto the top
Now, if I were in the US, I might arrive at very different conclusions, given how lax consumer protection laws are in general, how the US ISPs have a (recent) history of collecting and selling data and using other dirty tricks (like redirecting NXDOMAIN to their own adservers), and how in many if not most places in the US you have no freedom of choice in ISPs and are essentially subject to an ISP monopoly or duopoly in your area.
Deutsche Telekom isn't exactly evil, but it just handles far more data, of far higher value, including many bespoke government and business networks, phone networks, etc. The risk of their network being compromised seems higher.
ISPs have historically been evil far more often than other types of businesses, because they often are in the strong position of being the only or one of just a few options, and because switching ISPs is far more hassle than choosing one website over another. I would consider the chance of Telekom trying to squeeze another buck out of the relationship to be far higher than Cloudflare. IIRC Telekom did at some point get into the NXDOMAIN game?
To those saying that you are paying your ISP, Cloudflare has customers with much more buying power than you that might want to guarantee this privacy -- and less government granted monopoly power than an isp.
I trust them about the same.
I.e. what's the best I can do, short of hosting my own DNS?
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.
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.
Long awaited and MUCH needed for privacy.
This is the primary way in which your privacy is invaded.
Where is Apple on this?
What Google and Mozilla seems not to get, Microsoft gets 100%.
Good on them. Thanks for sticking up for the user, MS. At least someone did.
https://9to5google.com/2019/10/28/chrome-encrypt-dns/
Mozilla (I believe) is doing rolling out DoH to users (in the US) to use CloudFlare's DoH server. This will bypass the system configured DNS servers. This can be disabled in settings. And if the DoH DNS lookup fails, it'll fallback to the system configured DNS.
https://support.mozilla.org/en-US/kb/firefox-dns-over-https
(I'm a googler, opinions are my own)
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
https://support.mozilla.org/en-US/kb/customizing-firefox-usi...
https://support.mozilla.org/en-US/kb/customizing-firefox-usi...
https://github.com/mozilla/policy-templates/blob/master/READ...
Classy move, Mozilla.
It's intended as a way to allow DNS filtering software to work when admins aren't involved with user devices. DNS filtering software breaks DNSSEC anyway. So using it doesn't break anything extra.
With the DNSSEC breackage, the issue is the scope. With a little bit of thought, they could break just .application-dns.net instead of entire .net, if they used use.application-dns.net instead of use-application-dns.net. But I guess collateral damage wasn't in the mind of whoever suggested that.
Also, it is a difference, when a single second level domain has broken DNSSEC (especially one used only by single application that won't use DNSSEC anyway), and when entire top level domain is broken (which will be used by other applications, which do validate DNSSEC).
I know that DNSSEC is not favoured by browser makers; I'm personally not a big fan either. But just ignoring it as they were all the years is something different, than actively trying to undermine it and damaging other users of it.
This is true. Nothing has shaken my faith in Mozilla more than their efforts with DoH.
Chrome (and firefox) are providing their own DNS, away form the system. This means that loading www.blah.com in chrome, firefox and opera will result in 3 different DNS lookups, and potentially 3 different results.
Windows is doing it right.