> 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.
> With DoH you can pick a privacy focused endpoint and nobody between you or that endpoint can trivially monitor your DNS.
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.
> 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."
"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.
It's a draft, which means it's being pushed towards being standardized. Currently you can enable it in Firefox and Cloudflare will negotiate with eSNI. Chances are this will break some middleboxes once Chrome rolls out the standard [after the standard is finalized].
I don’t know why you say “DoT never gained widespread adoption” - it is a very new protocol so it is way too early to assess. But it is supported in recent android and works fine.
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.
> 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?
Sorta. Not all IP addresses have a domain name associated with them. And if malicious software is actually using raw IP addresses rather than domain names, that makes it easier to stop them because you could just block those IP addresses. This is why that approach is rarely taken -- with domain names, if the IP address is blocked, you can just associate the domain name with a different one.
If malware are already utilizing channels such as Youtube, the ability to block Google will be exponentially more difficult than attempt to cycle through domains.
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.
k-Anonymity doesn't really work with non-uniform distributions. E.g. if x is your hash prefix and d is a particular domain that matches that prefix, then we can apply Bayes rule:
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...
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.
> it reveals to eavesdroppers what DNS servers you're talking to
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.
For almost every service this genuinely doesn't matter, becasue the authorative DNS server for a given domain will most likely be run by the same entity that runs the server you want to talk to. I wanna point out that a recursive resolver normally caches everything it is allowed to cache, so visting the same site a few times will not, in general, produce any extra DNS requests.
The first steps of the chain are so generic there will be no useful data in there and the TTL is normally high (~a day). The last one or two steps are pretty directly connected to the service you are connecting to anyway. I don't really see an argument how caching RR is worse than centralized DNS at Google or Cloudflare or whomever, from a privacy perspective.
They do contain useful data. You are telling the root servers what tlds you are talking to and telling the tld operator what 2nd level domain you are talking to.
Yes, you hae to ask the tld's server for the NS record - the delegated domain's authoritative server. That's one request that usually has a much longer TTL. I've seen TTLs of multiple days or even weeks for NS records, compared to 5 minute TTLs (or less!) for A records.
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).
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.
It sounds like in this early milestone they will NOT fallback to unencrypted DNS to do a sort of 'scream test'.
> 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.
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, I don't see how DoH prevents you from being in control of your infrastructure. You can run your own DoH server and set it as DoH Server in Firefox without much issue and I doubt Windows will be different.
A DHCP option, e.g., "DoH server", could be added to the DHCP spec to tell clients which DoH servers to use (just like happens now with "regular DNS").
And why not just use the DNS server itself for this? Like negotiate with the DNS if it supports DoH? Why does it need to influence other standards like DHCP?
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 ...)
The first thing that comes to mind is that DHCP option 6 specifices (one or more) IP addresses, whereas with DoH you probably want to specify (ideally, multiple) hostnames, for various reasons.
The DoH server needs to be identified using a URL (a target for POST requests) or template (for GET requests). There isn’t a standard way to get from a server name to a DoH URL and DoH servers differ in their choice of path name.
We pretty much already have this exact thing with options 66 (hostname) and 67 (filename) for clients booting via TFTP.
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.
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.
You can set up a DoH server today. You can then configure Firefox to use that server by configuring it as a "custom provider" (Chrome is even simpler, and never defaulted you to an alternate DNS server to begin with).
I realize I can configure Firefox, but I am against my browser not using what the OS provides. Since no OS currently uses DoH, I have no real incentive to set one up. Plus, the number of DNS software that has added DoH is pretty small.
Its really not that hard. I've got /etc/resolv.conf pointed at 127.0.0.1 and a local stub resolver forwarding to an upstream DOH server. Boom! everything using gethostbyname is now using DOH.
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 problem has nothing to do with DoH; it only seems that way because DoH makes it clear that you lack this control and that systems that tried to exert this control using DNS were hacks to begin with.
I get that; I think everyone gets that. Before, with cooperative hostile programs, you could block their access to the Internet by managing DNS. Now you can't. But cooperative hostile programs are a very strange threat model! Hostile code that can talk to the network --- which has to be your threat model regardless! --- doesn't have to use RFC1035-style DNS to look up names at all.
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?
> But cooperative hostile programs are a very strange threat model!
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 runs on your computer, your computer gives you better information about what it is than the network possibly can.
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.
> If it runs on your computer, your computer gives you better information about what it is than the network possibly can.
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...
>Except if that computer is in your TV, or is in an iOS-based device, or in another piece of hardware.
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.
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".
Why? Because your data is valuable enough to harvest so long as they don't have to task a single developer to spend 3 days building a DNS tunneling feature?
Yes? I was under the impression that most Android apps make money by slapping a random ad SDK and watching the money roll in. I haven't heard of SDK vendors running their own name resolution schemes in order to avoid DNS-based content blocking. DoH will give them this feature by default.
Which is it? Is the problem that browsers and operating systems are now doing DoH on your desktop, or that you can install an app on your Android phone that could itself DoH out to an untrusted DoH resolver the same way it could have TLS'd out to a C&C server?
cooperative as in devices that users have elected to use? Additionally, it isn't clear as to why DoH presents a challenge when malware can already communicate to Youtube for example to download its payload. The chances of blocking Youtube are negligible.
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.
> it's always been possible for software that wants to circumvent hosts file / DNS filters to use an alternate name resolver.
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.
> 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.
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.
True. DoH just makes it much cheaper and easier to do in a robust way. Which means it will be done much more often -- probably commonly, because of advertisers.
> 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.
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 mean, how does a browser distinguish the two. How does it know that it's running on a device owned by the network operator, as opposed to the (probably more common) case that the device owner distrusts the network operator.
It can't, but it is a strange reality in which we absolve users of responsibility to manage their own network in order to protect them, in a way that exposes the users to new threats that even responsible ones can do very little about.
So it's irresponsible to connect to public Wi-Fi? Or, for that matter, to directly connect to a cellular network or any commercial ISP's service, without a router in the middle?
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.
> 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.
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.
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.
>But when it enables the delivery of hard-to-block ads, that's too far?
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.
Possibly contrarian opinion: I only support "strongly widely available encryption" that gives the user freedom. I don't support using encryption to create authoritarian "walled garden" prisons or as a "security" excuse to take away freedoms of the user (this includes, among other things, DRM.)
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.
The Chromecast has always been a locked-down device. I suppose it's frustrating if unsecured DNS was the one way that you could exert some control over a device that isn't truly yours, but that's just not a battle than can be won. Your beef should be with the Chromecast, not DoH.
Chromecast could also switch to using a new custom encrypted protocol that no one else understands or can decrypt to communicate with Google servers and funnel IP lookups through it, regardless of DNS or DoH. You cannot fight and circumvent such malware already present in software and hardware that you bought or installed.
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 run a local DNS server (e.g. AdGuard Home or Pi-Hole) you can set them up as a DoH system and still block requests.
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.
One possible problem is when devices start to use their own hardcoded DoH resolver. Today, Chromecast devices use their own resolver (still standard DNS), tomorrow, they might use DoH resolver. Worse, think about apps starting to do that on your mobile phone...
Now, you need MITN on your home network or you block everything to google.dns:443... but what if they rotate their DoH resolvers?
Ah, yes, didn't think of that. Though, I'm not sure if it's a problem.
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.
As you said companies are already doing this without DoH so really DoH neither solves this issue nor creates it. It is an issue that will exist no matter what underlying protocol is used for DNS (raw UDP/TCP, DoT, DoH, etc).
Why not? Software that hardcodes DNS servers usually fallback to DHCP, so you can simply block all requests to well known DNS servers, and they will automatically go through the DNS server you've served using DHCP.
Because you have no visibility that the lookup is happening.
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.
If you're in the US, your ISP is right now actively recording and monetizing your DNS requests by passive collection. DoH immediately exempts you from this surveillance.
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.
There are security benefits of TLS. Now, if you're asking what benefits it has over DNS-over-TLS, making DNS requests indistinguishable from other HTTP requests has privacy/shaping benefits.
Describe the entity that is making DNS lookups via DoH that you would want to block, that cannot already just directly make privacy-violating requests via HTTPS directly.
Before the DoH RFC, a malicious entity could certainly do such a thing, but to do it would require them to develop and deploy their own resolver. This means two things -- it increases the cost for the malicious actor to deploy this, and it makes it possible to block access to their resolver through firewall rules.
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.
You're exactly right, insofar as that DoH removes the "speedbumps".
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 seriously don't understand this argument. It really reads to me that you're saying "because of DoH, entities that can run arbitrary code on my machine where that code can talk to the network can now look up hostnames whether I want them to or not". But entities that can run arbitrary network-connected code on your machine have always been able to do that, and if you have that problem, you have bigger problems than name lookups.
I don't have an argument. You're absolutely right in everything you're saying.
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.
> 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.
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.
Can you give me a more specific example of what this thing is that you're referring to, that we could prevent from existing so long as we made sure it had to implement its own DNS resolver code? Or is "speed bump" really the right word to use here?
I'm not quite sure what you're asking for here, so please forgive me if my answer misses the mark -- which I think it does, since my answer is essentially repeating myself.
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.
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.
It could also be that it was looking like a nightmare world where every app had its own independent DNS configuration and they didn't want to have to deal with that.
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 [...]
I don't see how on-path devices could distinguish between DNS-over-HTTPS and DNS-over-TLS, provided they were run on the same port. It's just an encrypted socketed connection.
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.
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.
Okay, but if that's the reason... why not just run DoT on port 443? It's still less complicated than layering an entire protocol, which the network operators never get to see because it's encrypted...
> 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...
Well, it's at least different than sending it to your ISP, which I'm sure most users do by default. The question is, do you trust CloudFlare or your ISP more?
I hope more DNS servers support DNS over HTTPS soon because my options for using it are:
I am in Germany, so I trust my ISP more than I do cloudflare. If mozilla ran their own DNS servers and made Firefox use those, that would be better, but I'd still trust my German ISP, with which I got a contract and which is regulated by German and European law, in particular privacy law. The only thing in favor of mozilla and cloudflare from my particular point of view is that I trust them slightly more not to get massively breached.
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.
The Cloudflare privacy policy for 1.1.1.1 actually seems entirely reasonable, and the service just isn't that big so I can actually understand it: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv.... Cloudflare does have sales offices and, obviously, servers in Europe, so GDPR should apply.
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?
The UK for starters, I have a large choice, from A&A to Zen.
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
The parts of Australia with NBN (read: about 90% of houses in the country) have choice in ISP. I'm not sure of the split between all the FTTx options, so they may not all count as "high speed".
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.
With Cloudflare, you also have to realize that any site that uses them that you are visiting could possibly already be being tracked.
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 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.
> Silently changing the DNS servers trusted to do Windows resolutions could inadvertently bypass these controls and frustrate our users. We believe device administrators have the right to control where their DNS traffic goes.
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.
Mozilla is being more aggressive here than Google. My understanding about how Chrome will work, if the DNS servers configured on your machine support DoH, they will silently upgrade to use DoH. But it is entirely based on what your system DNS server is set to.
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.
Additionally (for Mozilla, not sure about chrome) there are a couple of checks to allow system administrators to force Firefox to fall back to the system DNS if desired. Either they can return NXDOMAIN (or some other options) to queries for use-application-dns.net, or they can use the usual group policy/active directory/policies.json methods to configure users' Firefox to not use DoH or use their internal DNS server with DoH if supported.
They don't have to, that's one of the options. If they're corporate admins they likely have Active Directory or the ability to require the profiles.json, which also disables it.
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.
I believe you meant Group Policies, as Active Directory in itself won't solve any Firefox configuration problems. With policies.json, we have such experience that random Firefox updates wipe it out and we have to redeploy.
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.
The whole point of this feature is to ensure DNS filtering keeps working. Since DNS filtering already conflicts with DNSSEC, what does it matter that one of Firefox's mechanisms for signaling that you want DNS filtering also conflicts with DNSSEC?
No, the point of this feature is to use the resolver configured by the network administrator. DNS filtering might be one of the reasons, but there might be others, like resolving zones behind ACL, which by definition won't be resolvable by public resolvers.
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.
Not really, Windows is handling DoH as a system service, which is great
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.
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