That's exactly what their plan is -- and if you have experiments enabled, they may have already started sending your DNS queries to Cloudflare.

I guess thats Mozillas new monetizing strategy, sell user data to cloudflare, and market it as privacy.

If you want privacy you better firewall everything your computer want to send to Cloudflare, Akamai, et.al.

>...sell user data to cloudflare...

Cloudflare claims they "will never sell your data or use it to target ads."

You can read their 1.1.1.1 privacy policies here:

https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...

https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...

Mozilla have a special deal with Cloudflare. According to Mozilla it will give even more privacy. It also seem that there is no money involved? So hopefully Mozilla is not selling DNS like they sell search. But I still think its a bad idea to centralize DNS and send all dns request to one actor, then it becomes very easy for anyone like the US gov to collect the data.

Then there is also performance. While Cloudflare has great coverage, using your ISP DNS will be much faster, due to it being physically closer in the network and using a more simple protocol.

That does not say they cannot use it for other purposes.

It says what they use, how they use it, how they won’t use it, who can use what (APNIC or if required by law), and how long they retain what. Your comment is misleading.

And policies never change. There is never a change of management, especially after a company goes public (which CF is planning to do). /s

Like what? Fixing bugs in their service?

Good luck with blocking Cloudflare and Akamai and still using the internet.

Which is why some people, like Paul Vixie (no DNS dummy, he), think that this is an absolutely terrible idea.

Mozilla is now basically dictating policy to organizations.

It's not that bad. Done it before. It's as if some sites are more like other paywalled sites.maybe noscript trained me well for it.

The article explicitly mentions the way to tell applications including Firefox not to disregard the OS DNS: blocking a canary domain. It even links to detailed instructions.

Frankly, given how much trouble I've had with systemd's DNS meddling, I look forward to applications taking DNS under their own control.

> blocking a canary domain

And how long will it take for most ISPs to block this domain when they realize that their DNS servers are not being used anymore? Some of them sell this data so they see it as a source of revenue.

At this point this canary domain will have the same fate as Do Not Track.

> I look forward to applications taking DNS under their own control.

I am sure I can find a hundred applications/programs resolving domains on my machine. It is unrealistic to configure all of them separately. At this point we are back to the OS providing the configuration for all of them.

They already stated in the article that if the canary domain will be abused they will disable that check.

Yeah. Sounds like another do-not-track then.

I’ll keep my firewall-rules banning all DoH-traffic to Cloudflare, just in case.

I suppose you can block the IP 1.1.1.1, but Google serves THEIR DNS at `google.com` on HTTPS port. One of the design choices of DoH to make it look like HTTPS traffic.

It's gonna be difficult to block DoH traffic.

> One of the design choices of DoH to make it look like HTTPS traffic.

Wait until encrypted SNI gets implemented everywhere was well.

Not a bad call, I guess.

It's a bad idea what it end up starting a cycle where every big application uses their own DNS. Some of them might not wven do it right

Do you mean Network manager? AFAIK systemD does not meddle with dns.

And there's a rather short conf.d stub you can create that disables NM's meddling with resolv.conf.

> Firefox decided to stop using my DNS server

In an ideal world, your probably want some sort of encrypted connection to your own DNS server (unless your LAN is 100% trusted). Maybe something like HTTPS would work... oh wait.

Most people don't have their own DNS server, so their DNS traffic is already who-knows-what server with who-knows-what monetization in place (plus its in plaintext, so the rest of the internet gets it too).

DNS over HTTPS seems like a net win for both types of users. Power users like you get way to encrypt your DNS traffic, and non-technical users get an encrypted connection to a potentially less-hostile DNS server. It sucks that there is now a second place to configure things, but hopefully seeing this work well will put pressure on the OS to adopt DNS over HTTPS natively, bringing the experiment to its final goal (at least, I assume this is the endgame).

> Most people don't have their own DNS server, so their DNS traffic is already who-knows-what server with who-knows-what monetization in place (plus its in plaintext, so the rest of the internet gets it too).

I know perfectly well who operates my DNS server: My ISP. If they are doing shady stuff, I can sue them, raise awareness or switch providers.

I can't do the same with hardwired DoH endpoints.

My ISP, at&t, sells my dns queries by default. I turned it off in the account privacy settings, but I still dont trust them and they are the only ISP that serves my house. As well, firefox lets you choose your dns over https provider in settings, its hardly "hardwired".

It's easier to switch ISPs than it is to just configure FireFox to use some other DoH provider?

So now we need to worry about making custom DNS config for every single app on a computer?! It’s absurd.

Does your OS allow you to configure global DNS-over-HTTPS settings? Then you can hardly blame apps for not importing them.

Yes, getting rid of shitty old standards means we have to live with multiple in parallel for a while and in the mean time bear additional complexity/work. Otherwise civilization will never advance.

My OS (glibc, specifically) provides a way to resolve names (gethostbyname) using various means (hosts file, mDNS, DNS, directory service) configured by nsswitch.conf. Some distributions (e.g. Ubuntu) even move this to a separate daemon (systemd-resolved) which does stuff like DNSSEC validation and DNS-over-TLS (DNS-over-HTTPS is not (yet) supported natively, you need an extra program for this). I don't think moving common functionality from the OS into individual applications is "getting rid of shitty old standards", we will end up with multiple duplicated implementations.

I agree, an common, likely OS provided API to resolve names is in the theory the best way to go. Not least because it allows OS vendors to replace the implementation with more modern and secure variants over time by pushing sane standards. Sadly they didn't do their job and most DNS is still un-encrypted. Eventually others comes along and do it by themselves. Obviously not on the OS level, since they don't have control over that.

Yes, "multiple duplicated implementations" is the natural consequence of badly maintained software. But eventually I'd hope OS maintainers get their act together and implementations will start to converge again.

I feel like that’s a slippery slope that will probably never happen. Most likely you’ll have to configure your browser(s) and that’s it.

And how the hell is split-horizon DNS supposed to work if resolve.conf is ignored?

This may be "fine" for (some) home users, but most organizations have a whole bunch of internal-only records. And even a lot of residences have things like printers and such that live under .local: how is the browser supposed to connect to those?

Who the fsck is Mozilla that they get to dictate policy in my IT organization about how DNS "should" work?

This attitude always amazes me. You have obviously mastered a set of system administration skills over several years, and you are comfortable with a particular way of doing things. When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility.

Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), but the amount of aggression in your comment suggests that something deeper is going on. Do you feel threatened?

I suspect it's fear of change. As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. This means you, the administrator, will have to learn more skills and do more work to keep things running. Things like `.local:` printers may break, and you may have to upgrade your internal DNS servers to RFC8484 so you can keep your split-horizon stuff working. Security is never free.

Or not. None of this is mandatory, and you can just switch it off (and Mozilla will automatically switch it off if they detect an environment like yours, as it says in TFA). The threat isn't Mozilla "deciding policy" for you (they aren't), the threat is that they are calling the industry out for running old & vulnerable DNS standards, and we all know deep inside that they are right.

I think the underlying issue is absolutely a power struggle.

Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration.

In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers and other DNS-consuming apps were perfectly capable of working within other networks. What a DNS name resolved to was technically a property of the network.

By now, this model is shifted towards the Web as a platform with browsers and DNS as clear parts of it - a platform that is incidentally pay-to-play and centrally controlled by the US because at the very least you need recurring payments for your domain and you need to give companies and institutions located in the US control over your machine.

This shift has been going on for a long time, but I believe HTTPS-everywhere and DoH have served to make this unignorably obvious because those bring the concept of the web platform into the technology stack itself.

To make the tired old car analogy again: In the vast majority of cases, you will drive your car on the public road network and nowhere else. However your car is technically capable of driving off-road or performing highly questionable maneuvers in your backyard because the car itself doesn't have any concept of "public roads", "private roads" or "non-roads". DoH would be adding a device that turns off the engine as soon as you're not on a public road. What exactly constitutes as a "public road" is determined by the car manufacturer.

I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change.

I also think all the heuristics, opt-outs and special rules for corporate network's don't cut it, because they relegate the current default case to an uncommon special case - and developers have a habit of ignoring uncommon special cases. I wouldn't be surprised if we see a lot of non-browser apps and devices in the future that use DoH by default and that an administrator would have to reconfigure by hand for each single installation - or that are simply hardwired to some set of DoH servers without any way to configure them at all.

Wow, I had not considered the deeper power shifts from this perspective.

The root the problem, I suppose, lies with public-key cryptography. We all know encryption is a good thing (unless you want to broadcast private information to the world), but encryption is useless unless you know who you are talking to. When someone comes to you in a ski mask and says, "It's me, your best friend", you probably want to see their face before you tell them any secrets - they could be anybody.

Online, though, how do we know who anybody is? The current answer, for better or worse, is TLS with pay-to-play domain registration and certificate authorities. Decentralized, peer-to-peer systems like PGP have never been easy for consumers to use. You can "off-road" encrypted DNS by running your own DoH server & installing self-signed certificates on your client devices, but that's not an easy option.

"My LAN is my castle" may work for some cases, but most of us conduct business with people all over the world, thanks to the internet. This is the primary use-case for most networks & computer systems.

I'm afraid individuals will continue losing the power struggle as long as decentralized identity systems remain obscure. We need something that's as easy and compelling to use as our current centralized systems. It needs to be something consumers can use it to secure their every-day communications, as easy as visiting an HTTPS web site or chatting with a friend on Facebook. I just don't know how we get from here to there.

> ... but encryption is useless unless you know who you are talking to.

False. Opportunistic encryption is useful even if you don't know the other person's identity. This is because it helps prevent wholesale surveillance and "tapping glass":

* https://en.wikipedia.org/wiki/Room_641A

* https://en.wikipedia.org/wiki/PRISM_(surveillance_program)

For the majority of the website I go to on a casual basis, I don't really care who is behind running them. Certainly I want that for my banks and webmail, but not so much for some random weblog that has an article comparing Rust and C.

I'm all for Let's Encrypt, and pushed for it to be introduced at work (both for internal and external sites), but we could have gotten encryption in more places, a lot sooner if connections over plaint-HTTP (tcp/80) could have been upgraded automatically to encryption:

* https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header

There would have been no lock icon in web browsers, but it would have scrambled a lot of bits. Yes, MITM would still have been possible, but MITM is a targeted attack that takes way more resources than simply vacuuming up everything that goes across the wire.

The insistence of providing identity, IMHO, delayed the securing (or at least 'confidentializing') of communications by many years. LE/ACME is getting us there, but we could have had a lot more encrypted traffic already but for the desire for the little lock icon.

Sorry, I don't understand why this is. Can you not just set up your own DoH server, or use your ISP's (perhaps automatically via DHCP)? How is that different from what happens now, except the traffic is now encrypted?

To my knowledge, one of the defining characteristics of DoH is that it's not configured by the network.

There is a default setting managed by Mozilla which the vast majority of users are expected to use (currently Cloudflare's resolver). You can choose to disable DoH or set your own resolver - however that has to be done manually for every installation of Firefox.

Mozilla is offering a way for networks to signal "don't use DoH here" as described in this article, but Mozilla is intending this to be used for certain specific scenarios only (parental controls and corporate networks) and reserves the right to ignore the signal if it is misused.

To my knowledge, there is no "DoH" entry in DHCP, where a network could specify a local DoH resolver. All articles I've read about it also very much treat it like an application-level protocol, as opposed to the old mechanism where resolution was done centrally by the OS. If this approach is continued, then every application would have to decide for itself which resolver it uses.

Is this by design/intention, or just because DoH hasn't caught on yet so Mozilla is setting a sane default here?

I can see how it would be a drawback if the network administrator had no way to configure the setting for all clients.

The network administrator shouldn’t be able to change any setting at all on client devices. That’s the point! If you can just direct clients to a malicious DoH server then the project has largely failed.

The device administrator should be the one making the choice about what resolvers to use.

I agree: the device administrator should be in charge. Essentially, I see this conversation as having spun into an awkward regime where there is an implicit and entirely incorrect assumption here that the options are 1) the network configures the DNS setup and 2) individual apps configure their DNS setup; what happened to 3) the owner of the computer (the device administrator) configures their DNS setup?

The status quo implementation has been that the operating system handled DNS, which actually did put the power in the hands of the device administrator: I don't think I have ever seen a device that wasn't clearly owned under some crazy MDM scheme where you couldn't choose your own DNS servers. Sure: recently, it happened to have a default to trust the network... but that was just a convenience, and is a "new phenomenon" brought on by DHCP being widely deployed. All of the software wasn't designed with that as an assumption.

So, if I want DoH, why am I not just setting up a custom resolver on my computer, that all of my apps use, including Firefox? The "power struggle" alluded to up-thread is actually much deeper: it is using network operators as an excuse to take power away from users, by moving what used to be an operating system feature into individual applications in a world where DRM via code signature is being deployed to lock users into curated application domains to prevent them from modifying that software to do what they want.

(That said, I mean... the way Firefox implemented this totally still gives the network administrator control, due to the opt-out provision? So in some sense a lot of this conversation is useless... for now.)

Network administrators don't have power over device administrators, so the premise is a bit false. Device administrators are the network administrators on their own devices.

> Network administrators don't have power over device administrators ...

They (possibly) do when they're both under the same Director of IT.

Security is everyone's responsibility in an organization, and the folks in Helpdesk (ideally) want to prevent intrusions just as much as the NetOps folks.

> The device administrator should be the one making the choice about what resolvers to use.

No, the device owner should be the one. Which could the company/organization that bought the device in the first place, in which case that is delegated to the IT team.

And if the IT team does not want DoH, it is the IT team that gets the final word.

Mozilla has been nice enough to give options to disable that, and that can easily be done with GPOs on Windows, but not all the world is Windows, and if you have a large Mac or Linux use base that uses Firefox, how will disabling DoH be automated there?

And just because Mozilla has been nice enough, does not mean that other developers will be.

Right? Because the core issue is that browser vendors (and eventually probably OS vendors) do not trust the local network operator. There will be GPO’s and Jamf profiles, and Ansible playbooks to configure this setting for the swarm of machines you ‘own’ but you are simply not a trusted party to any person that connects to your Wi-Fi access point.

> I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change.

Tell that to the health and financial regulatory regimes that us some of have to work under to ensure people's privacy is respected. I work in health care, and we have data-at-rest and -in-motion encryption and firewalls and application-level ACLs & permissions all over the place in our internal network.

Not being able to resolve internal-only systems, which have absolutely no need/business being in external DNS, because of a change in behaviour in client software is just dumb.

People complain about the stupidity of (e.g.) power plant controls being directly connected to the Internet, or not being air gapped from the folks in Accounting, but then we seem to have developers writing software that will not work very well in these isolated/island networks.

I'm all for the general end-to-end principal (that IPv6 may help bring back) with protection being done by stateful firewalls, but there are all sorts of use cases for private, isolated networks that are behind NAT/NPT gateways that are given ULA addresses.

> When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility.

What weakness?

> As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption.

Then use DNS-over-TLS (DoT). It was an RFC (7858) two years before DoH (8484, 2016 vs 2018).

Why does yet another protocol have to be shoehorned into HTTP(S)?

It's amazing that you have such strong opinions about an article you didn't even bother to read.

First, they detect split horizon situations and explain how.

Second, if you as an admin want to force disable DoH across the network, they've provided a DNS-based way to do so.

Third, if this really bothers you, Mozilla provides GPO templates (and JSON based methods for other OSes) to configure all of these settings at an application level.

Maybe focus that outrage energy on reading the article before posting?

Mozilla may be kind enough to have those settings, but that doesn't mean other software will do the same thing.

It's nice that Mozilla may allow setting other DNS servers for DoH, and perhaps will eventually use OS-level settings, but what happens when some dumb ass developer does not?

Perhaps if they implemented DNS-over-TLS (DoT) instead/as well, then we could have encrypted DNS that is still monitorable.

I'm waiting for the day when malware will start using DoH and use Cloudflare as the DNS server. As someone who works in IT, will I have to block CF to prevent that possibility? How many bots have been taken down over the years because their C&C domains were taken over?

The silly assumption being made here is that "DoH" = "talk HTTPS to Cloudflare". I want DoH, but I need private domains. I would like to talk DoH to a thing I control.

It should be Opt-In.

Not Opt-Out.

> unless your LAN is 100% trusted

For 99% of the people out there, it is.

Can Mozilla stop interfering with my network and get back to doing useful things with Firefox now?

No kidding. Bypassing all the ad/malware domains in my HOSTS file, which practically all other applications on the system respect, feels disturbingly shady. Where's my privacy now!?!?

If Mozilla wants to, they are more than welcome to work on encrypted DNS or VPNs or whatever else, but those should be at the OS level. Disrepecting configured OS settings borders on actively malicious behaviour.

How exactly do you expect Mozilla to "work on encrypted DNS at the OS level"? How does Mozilla make Microsoft/Apple/Google implement it?

How do you think people write VPN clients? Encrypted DNS is very much within that category of software.

How does Mozilla make Microsoft/Apple/Google implement it?

It doesn't need to, the same way it doesn't need to (nor should it) make Microsoft/Apple/Google ship Firefox as the default browser.

> For 99% of the people out there, it is.

99% of the people out there never connect to wifi in coffeeshops?

I'm not even sure you hit the 99% mark if you measure by time spent connected, though I would love to see some data.

(Disclaimer: I work for Mozilla, but have not really been involved with DoH.)

Mozilla can only speak for their applications and they seem to eventually intend Firefox to use DoH as default and fallback to OS DNS under various failure conditions some of which are mentioned in the post. They also say:

"When DoH is enabled, users will be notified and given the opportunity to opt out."

> Is there an option to tell all applications that they should not bypass it?

Yes there is. If your internal recursive DNS servers return an NXDOMAIN for "use-application-dns.net", then Firefox will stick with gethostbyname(3) (or whatever). See:

* https://support.mozilla.org/en-US/kb/configuring-networks-di...

If you’re using NLnet’s unbound(8) as a recursive DNS server, it’s possible to use the “local-zone” directive to force an NXDOMAIN:

* https://serverfault.com/questions/625170/

For ISC’s BIND, the response policy zone (RPZ) mechanism does something similar on BIND 9.8+ (it’s more flexible, so more complicated to configure):

* https://jpmens.net/2011/04/26/how-to-configure-your-bind-res...

* https://downloads.isc.org/isc/bind9/9.9.5/doc/arm/Bv9ARM.ch0...

* https://dnsrpz.info

* https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz

* http://www.zytrax.com/books/dns/ch7/rpz.html

* https://serverfault.com/questions/618106/set-up-bind9-as-dns...

>Are all applications expected to disregard the OS DNS?

I hope so if OS continues to use plaintext (none secure) DNS queries.