Hacker News new | comments | show | ask | jobs | submit login
Firefox’s Trusted Recursive Resolver DNS feature is dangerous (ungleich.ch)
245 points by chipsdujour 9 days ago | hide | past | web | favorite | 298 comments





DNS over HTTPS is a great idea. There's nothing wrong with the protocol or Mozilla's implementation of it. This article is all about Mozilla's default choice for a DNS provider. I think Cloudflare is actually a reasonable choice though I'm not a big fan of their annoying captchas that I get served whenever I use vpns.

There's nothing sneaky going on here; which the article seems to imply.

Currently there is no UI to configure any of this yet (other than about:config) but you can trivially select any DNS provider that implements this in the same place where you turn this on. The relevant setting is network.trr.uri. Also, you need to opt in to this to turn it on so you'd be reviewing this setting as well. Also you can configure how this is used, how and when it falls back to normal DNS, etc.

You can run your own server if you want; or use the one from your provider if/when they implement this. For obvious reasons, there are not a lot of usable servers yet but it seems Google has implemented this as well. So I assume they plan to roll this out for Chrome at some point.

The premise of this article seems to be that you should trust your provider to do DNS and do it well. I'm sorry to say but for the vast majority of providers I have experience with the opposite is the case. I've had providers redirect dns failures to advertising pages in the past, shitty performance (600 ms or worse), and generally trying to rip me off with bad network infrastructure related outages while charging me a premium for bandwidth clearly not delivered via obviously very congested infrastructure. I have no reason whatsoever to trust them, at all. The less they can learn from my traffic the better.


The article doesn't suggest there's something sneaky going on. The article is suggesting that Mozilla are choosing to share your DNS queries with a third party service by default, which is exactly what they're doing. It's not about them choosing Cloudflare in particular, it's about them choosing any particular service by default. And the article's argument that, if you have to choose somebody to share this data with, it might as well be the people you already share it with, seems pretty valid to me.

edit: I have to point out that the article has backed away from the claim that this will be enabled by default in September. Looking at the Mozilla blog, they mention wanting to enable this by default but have no actual plan to do so (and more crucially doesn't discuss at all what sort of form it would have to be in for them to enable it by default, it may look nothing like the cloudflare-default we're discussing here).


That’s simply not true. Mozilla is not sharing DNS queries with Cloudfare by default, nor are they overriding your configured DNS servers per default. This is an experimental opt-in feature, and they are also running an opt-in study. There has been no announcement of an ”on by default” for DOH. If you enable the experimental feature there is no default provided and you have to set your own server, but if you opt in to the study, you’ll get Cloudfare. This is almost pure FUD at this point.

Just to be clear, the authors are wrong? There will not be a September patch that overrides my network DNS settings?

"With the next Mozilla patch in September any DNS change you configure in your network won't have any effect anymore, at least for browsing with Firefox, because Mozilla has partnered up with Cloudflare and will resolve the domain names from the application itself via a DNS server from Cloudflare based in the United States."


This is the relevant post from the Mozilla nightly blog: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr... It confirms that the default is off. It also gives a much more nuanced view of the level of partnership. CF is currently the partner for a study regarding that feature. That study still requires opt-in (and currently nightly) The patch in September will bring the feature to mainline FF, but it’s still default off and hidden behind “about:config”

Do you seriously believe that Mozilla is issuing a patch in September that will somehow force you to use Cloudflare as a DNS provider? That 'any DNS change you configure in your network won't have any effect anymore'? Do you know many setups that would break?

Of course the article is wrong. Classic FUD.


Actually, yes, I do. From their blog:

> We believe that negotiating a privacy first operating agreement is something that Firefox can do for people that is just impractical to ask them to do for themselves. Imagine calling up your residential ISP and asking them to agree to an audit that demonstrates they do not log your IP address on their DNS server. And then repeating the process for your favorite coffee shop, library, friend’s house — anywhere you and your browser go to connect.

Firefox improves user privacy by default by finding good partners, establishing legal agreements that put privacy first, and eventually shipping a default configuration we believe is best.

They know about the power of default settings - and with the current default, they will be unable to roll-out this feature to a meaningful number of users. So at some point, the default will probably change to activate DoH.

Technically, this isn't "force" as you'll probably be able to turn it back off via about:config - if you know which options to change, what to change them to and if you are willing to click past the "if you proceed, you may damage your computer" warning.

Not every random guest that wants to access your local Nexcloud instance will be willing to do this.


And you expect that to happen within the next month? Without any warning that it will happen with the 62 release? After they have just started an experiment intended to shake down the feature on both the server and the client side? Even after having it default off in nightly? With no practical experience of how a large-scale DoH setup behaves in a real-world environment? Breaking all setups that use an internal DNS to resolve internal names (such as any larger-scale corporate setup)?

If you intend to say “sometime in the unspecified future Mozilla will probably default to this.”, then I’d agree but this is not what’s being discussed. At that point in the future, the whole environment in which this is operating in will look different. More DoH-capable providers, a better understanding of the benefits and drawbacks, a config UI,...


Hmm, looks as if the September date was indeed an error - even the article added a correction. (Also a Mozilla representative seemed to post they plan to keep local DNS as fallback)

So I do hope you're right and they will take their time until the ecosystem stabilizes and they found less damaging strategies.

I still think there are general problems with DoH and the assumption that all local networks are hostile. But maybe, there will be more time to discuss those assumptions.

I don't see that they will necessarily add a config GUI though. Most people will likely ignore the feature and the techies already have about: config, so there might be little pressure to add a more accessible UI.


I don't see how they could enable it by default unless they query both local and DoH at the same time .. or perhaps a hybrid model where they only using DoH by default on certain TLD's and / or domains.

Corporate users would be utterly broken unless their IT staff are managing the proxy settings in all their installed browsers, which is often not the case. This would lead to Security and IT staff blocking CF DNS until it was fixed.

I believe this is a good thing to watch for, but I can't imagine Mozilla not having thought this through.


The default applies currently if you enable an experimental feature. They hammered out a tight privacy agreement for one service and use that as default while this is stabilized. You can pick any other resolver if you prefer. Seems a legit way of handling this.

> And the article's argument that, if you have to choose somebody to share this data with, it might as well be the people you already share it with, seems pretty valid to me.

The whole point of HTTPS and DNS-over-HTTPS is to not share any data at all with your provider. It’s not entirely working right now due to SNI being plaintext, but work is being done on that, too. So that’s really not a good argument.


Cloudflare is an US company, their privacy statement is worth zero to most Firefox users.

Most Firefox users are absolutely unaffected by this. Literally all people that don’t explicitly enable this. All those who do might want to make up their mind if they want to participate in this and if they want CF to be their provider of trust. Keep in mind that CF will see a substantial chunk of the traffic anyways.

Mozilla seems to be confident in that agreement and I have a certain amount of trust in Mozilla which factors into my decision. Yours might be different, so don’t enable that feature or use a different provider.


FF will turn this on for everybody and Cloudflare will be the default 2018? Don't know. 2019? For sure. All FF browsing meta data flows into the US, the country with the most spies and no legal framework to go to court.

So your argument is an obvious straw man and one wonders about your motivations to support getting all the browsing meta data into the US by default.

Moving my data from Germany to the US will not make me more secure in any way.

And talking about repressed countries is like "think about the children!" for the rest of us - a nice lever to sell this massive data vacuuming.


Why do you believe that this will be default on at any time in the near future without a reasonable configuration UI and without a reasonable set of DoH-capable nameservers? Especially given that this would break a substantial number of existing setupts? If you have this little faith into the FF/Mozilla folks, why do you keep using FF? If you’re not using Firefox, what are you concerned about?

If they don't turn it on by default, only a small number of people will use it. If only a small number of people use it, why bother implementing it?

The section of people that use it might benefit to a very large degree. Or they can make the switch prominent to push adoption. There are a lot of features implemented and hidden behind “about:config” where you could ask the same question. Many of them are for the security and privacy conscious but come with a few strings attached, for example some advanced cookie settings such as third party isolation.

That said: I fully expect that at some point Mozilla will want to push adoption of this feature, but not in its most extreme form. I’d expect that a default configuration would use soft fallback.


Maybe to see if it works?

Which I think is the purpose of almost all experimental feature.

In the blog it is clearly stated that they hope DoH implementations will become standard and common, maybe that even some ISP start offering their own.


Why does so many people distrust every single step done by mozzilla!?

Sorry, this got me emotional, but since I started following tech news few years ago the amount of fake news on mozzilla I read is astounding.

And proper fake news. Many, as this article does, do no claim that a new feature dangerous per se, but falsely (I don't think with purpose, that is what I find astounding) quote mozzilla blogs to build an apocalyptic scenario


In today's world, it's important to remain skeptical of companies who are responsible for how our data and usage statistics are used or shared. Companies have generally shown themselves to be untrustworthy and it's not enough for a company to have been 'good' so far. We need to stay vigilant, even if it is Mozilla.

Totally agree! it is also important to mozzilla to know the won't be easily forgiven bad choices.

I'm wondering why the constant and maybe not even ill-intentioned misinformation about the word they say.

I don't want to accuse anyone, I believe that both side value the truth, but it really looks like as if there was a fake news factory against mozzilla


I believe Mozillas goal is to use the collective bargaining power of it's user-base to get favorable terms and conditions from vendors like cloudflare.

This could include 3rd party reviews, etc.. Who knows?


Cloudflare agreed to having the DNS infrastructure audited, something that does set it apart from a lot of ISPs. So that seems to be working.

That wouldn't stop legal threats. Per Core Secrets leak, NSA/FBI both pay for and force backdoors in U.S. companies' products. They also share that information with other enforcement organizations per other leaks. Cloudfare are in a position to monitor lots of network activity. I'd be quie surprised if they weren't already backdoored.

If NSA/FBI aren't in one's threat profile, one might also be concerned about a court order over something having to do with copyright or patents. Damages for those can be huge. There's both legal and technical firms dedicated to pouring through data for evidence of patent infringements. Many licensing "agreements" start with evidence they find. I don't know much more about this. My wild guess is that they often start with tips from disgruntled workers or maybe those leaving for competitors.

These are main, three threats I'd be concerned about if sharing what I did with a U.S.-based provider. Double true for me given I'm in the jurisdiction of the enforcement agencies.


Cloudflare publishes transparency reports https://www.cloudflare.com/transparency/

It also promises not to store your IP associated with the DNS requests https://developers.cloudflare.com/1.1.1.1/commitment-to-priv... so the law enforcement would have to ask Cloudflare to install a wiretap device.

If you're this worried about being traced, it's probably best not to disclose your IP address at all https://blog.cloudflare.com/welcome-hidden-resolver/


And they would have to hide such a wiretap device from auditors.

Moreover, cloudflare would be in a legal minefield since Mozilla would likely have standing to sue, if cloudflare violates its own terms of service.


Let me be more specific: they might be fined out of existence and/or executives do prison time if they don't comply. They'll also be told to lie to preserve both the collection method and their businesses' success. Read the Lavabit case records to see FBI doing that. So, they'd be forced to comply and lie to you about it in that scenario. In such a scenario, faking transparency reports would support the lie and/or do some good showing they're stopping other threats. It's not all or nothing despite forced backdoors.

So, you basically have to believe the US-based company you trust won't take 8-9 digit bribe, will accept bankruptcy, and/or has people who will do time for your privacy. I don't trust anybody running for-profit companies to do that except for maybe Levison. Even he might change after weighing damage he received vs probably no benefit of principled stand. Maybe he'll stay in the fight, too. Who knows. I do know Cloudfare has financial incentives to take massive investments and/or avoid massive losses. Might work against users at some point.

To be clear, Im a big fan of Cloudfare. They're awesome. There's just upper limit of trust since they're profit-motivated operating in a quasi-police state (ie a Dual State).


All of these involves cloudflare violating terms of service they've made to Mozilla.

Ideally, this would be caught in an audit and ideally Mozilla would be in a position to sue on your behalf.

How many users sue their ISPs over DNS logging, poisoning or other violations of trust.


"All of these involves cloudflare violating terms of service they've made to Mozilla."

Terms of service don't overrule federal law or court orders. That's assuming they'll turn down money. RSA told customers they were buying crypto with no mention of backdoors. Yet, they put one in for about $30 million.

So, a company might willingly violate ToS for a pile of cash or unwillingly do it via legal coercion that comes with secrecy order. Leaks indicated most took the bribes. Many more bribes or coercions might have happened since. So, we should just assume its true with companies in surveillance states with other security practices designed with that assumption baked in.

Also, it might not even matter if one isnt doing anything over those connections that's illegal. The backdoor becomes something probable but irrelevant for those users. From there, Cloudfare protdcts them from relevant-to-them threats like DDOS or delays causing lost sales.


> The whole point of HTTPS and DNS-over-HTTPS is to not share any data at all with your provider.

Won't they still see which website you then request?


Currently, the provider could read the SNI value from the request, but work is done to encrypt that as well. This would allow them to see which Hostnamen was requested, but they cannot peek into the actual transmission (which is incidentally how domain fronting works: announce a different SNI than the actual requests Host header)

> The whole point of HTTPS and DNS-over-HTTPS is to not share any data at all with your provider. It’s not entirely working right now due to SNI being plaintext, but work is being done on that, too. So that’s really not a good argument.

If that was the whole point of https then we wouldn't have plaintext SNI. I can't even begin to understand why you think that there being a draft of an SNI encryption standard makes it 'really not a good argument'.


Originally, HTTPS required a dedicated IP address (or at least a dedicated IP/Port pair) for the server. SNI is a tack-on on TLS to fix that, so that TLS can be deployed more widely, allowing to encrypt traffic that was plaintext before. Encrypted SNI is a tack-on to fix that SNI needs to transmitted in plaintext. So yes, the design goal of HTTPS is to hide as much information from all intermediaries as possible. It’s just that you can’t fix everything at once, so gradual improvements are made.

Well, I can't get behind saying that hiding the site your visiting from your provider is the "whole point" of https when it specifically doesn't do that. I mean, we both understand what https is aiming to do in general, and I assume you aren't suggesting that https has been an complete failure since SNI was introduced.

However, admittedly I'm just reacting to you using the term "whole point" in conjunction with something it's failing to do.


I’m not suggesting https is a complete failure. I’m saying that HTTPS hasn’t yet achieved all that it intended to cover. It does the best it can given current real world constraints. That requires tradeoffs. But work is done to improve the situation and I’m generally happy for every feature that pushes the needle in the right direction.

So.. in some future Mozilla might select a default DNS provider on your behalf.

Did you consider the upside?

Mozilla can negotiate on your behalf. Mozilla can obtain favorable terms of service, concessions in privacy, third-party reviews. Things you would never be able to negotiate for.

If you think of Mozilla as negotiating on your behalf, they have motive to protect you, and they have the leverage to get concessions from 3rd party vendors.

Think of Mozilla as using the collective bargaining power of it's user-base to get favorable terms. This could be a game changer.


It’s already happening: the DoH endpoint that Mozilla defaults to on the CF-Side has a stronger privacy agreement as per https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...

CF is not a default. There is no default.

CF is a partner in studying an experimental feature


This replaces decentralised with centralised in the hope it would be a good idea if the choice is right. I'm sceptical, if nothing else because it would be easier to compromise or DoS one target than a lot of individual DNS providers.

I can't see myself ever supporting this as opt-out rather than opt-in.

Will it not improve security for the majority of Firefox users?

> The article doesn't suggest there's something sneaky going on.

The article headline is "Mozilla's new DNS resolution is dangerous", so I guess you are right in saying they are not "suggesting", because they are down right accusing Mozilla of being sneaky.


Sneaky and dangerous are not the same thing

> DNS over HTTPS is a great idea

Putting everything, even lower-than-http level things on top of HTTP is a horrible idea, introducing yet another layer of abstraction.


It's important to understand the advantages of HTTPS via other protocols or custom crypto:

* HTTPS stacks are battle tested and there are multiple of them. Browsers in particular already ship a heavily maintained one that performs great, so using DNS on top of it gets all those benefits. Because there are multiple stacks the risk of people settling on a monoculture is a lot lower.

* People running a DNS resolver likely have the ability to run a good HTTPS server already, including having certs ready to go. Likewise, there are a bunch of battle tested httpd implementations out there and good https stacks to go with them.

* Proxies, reverse proxies, caching, etc are all well understood for HTTPS

* HTTPS2 has transport compression all figured out, so if you turn that on (which is 'free' once your server+client both support it) you're getting compression for free. HTTPS2 also supports multiple channels so if one request is pending you can still kick off another one over the same socket.

* Any debugging tools you can use with HTTPS can be used with DNS.

It's possible for a raw DNS protocol, or DNS+TLS, to pick up all of these benefits but DNS-over-HTTPS gets them almost entirely for free.

fwiw, web proxies over HTTPS2 are great too. The performance is great even over long distances because of the multiple channels and compression features.


You forgot the more pragmatic reason: middleboxes. HTTPS works everywhere, and introducing a new(2 years old) protocol (DNS over TLS) working on a new port (853) is a sure way to make sure it does not work in many places.

That mostly applies to corporate environments which already want to use their own resolvers anyway. For most people DNS over dTLS should work fine and if anything should be implemented on the OS level.

Your browser is not special, everything could benefit from secure DNS.


Well, once OS starts doing it maybe mozzilla will switch to that as default...

Is there anything left, that's not on HTTP? Maybe NTP. I know about JMAP to replace IMAP.

Here's another idea: other protocols are useful as well, sometimes more useful, than HTTP.

> HTTPS stacks are battle tested and there are multiple of them.

So is DNS. I wonder how the HTTP servers deal with DNS amplification attacks.

> People running a DNS resolver likely have the ability to run a good HTTPS server already

Your conclusion lacks any indication of evidence.

> Because there are multiple stacks the risk of people settling on a monoculture is a lot lower.

HTTP _is_ becoming a monoculture. Sort of. I know it's an open standard, and everything, but still.


> I wonder how the HTTP servers deal with DNS amplification attacks.

They don't have to since http(s) is TCP and not UDP?


DNS over HTTPS is immune to amplification attacks.

If the alternative to DNS over HTTPS is a DNS-over-TLS resolver being run by a company without a website (???) then I guess that's easier than DNS-over-HTTPS. Are you really going to use a resolver run by a mysterious nobody?

There are probably more than a dozen HTTP stacks being widely used in production. It's not remotely a monoculture.


> Is there anything left, that's not on HTTP? Maybe NTP.

OpenNTPD also uses HTTPS (TLS, technically) by default [0].

Fortunately, they aren't yet trying to tunnel actual NTP packets over HTTP or anything like that, just using the information in the "Date: " header as a sanity check.

[0]: https://www.undeadly.org/cgi?action=article&sid=201502101036...


HTTPS gives you the packet ordering costs of TCP and the handshake costs of TLS.

With an SSH-like key setup - i.e. just getting the server's pubkey on first use and rolling it over when it advertises a new one - you could asymmetrically encrypt every request in a single UDP packet and thus gain the same security and lower 99'tile latency.


HTTPS gives you clear upgrade path to QUIC and handshake costs of TLS 1.2-3 as well.

This is the very goal of this study - to determine how feasible is it in the real world and what's the performance impact.


You still don't need HTTP(S) for that. You could still use dTLS and later experiment with raw QUIC, sans HTTP.

I have configured my network settings to use a particular set of DNS servers. The issue is Firefox going out of the way to use something else.

The feature is opt-in. Firefox will use your system configured DNS servers unless you explicitly enable DOH. In that case you can still change Cloudfare for some other server if you’d like.
dingo_bat 8 days ago [flagged]

The impression I got from TFA is that the feature will be on by default and you have to dig into about:config to disable it.

They retracted it

Horrible seems like a pretty melodramatic word here compared to your explanation.

>DNS over HTTPS is a great idea

Why is it better than DNS over TLS? All I can see here is increased overhead.


Since HTTP(S) basically works everywhere and a new port (DNS over TLS on standard port 853) is guaranteed not to work everywhere.

Once DNS-over-HTTPS starts creating problems, port 443 to well-known IPs will be also not guaranteed to work everywhere.


Harder to distinguish between DNS queries and other traffic. Since a lot of censorship is DNS based that’s significant.

This is really the main point.

I support this but it has its downsides, for example flixbus blocks YouTube on their free WiFi. I think they have all the rights to do it as some site are heavier to support than others and they might be forced to shut it off if it became common

(Also a lot of people don't have earphones on them an being beside someone watching "funny" YouTube videos at 3am is torture (end of personal rant...))


Wouldn't this be better served by bandwidth limiting/shaping?

that would mean that if many people used youtube they would all have terrible speed, which would make their wifi look of bad quality.

The primary purpose of their on board wifi is to buy tickets and check connections. In this case video streaming might really be more expensive than necessary


I mean limiting per-user bandwidth. So if you try to watch youtube on your personal 1Mb slice, good luck, but you won't drag down anyone else, and for the stated goals of buying tickets and such it's fine.

DNS over HTTPS might or might not be a great idea; but I'm critical whether centralised is better than the current decentralised approach. You're putting all your eggs in one basket, which might become an exceedingly interesting target.

> I have no reason whatsoever to trust [any ISP], at all.

You also have no reason to trust cloudflare, at all.


According to the article this is enabled by default to use Cloudflare. Are you saying that is not the case?

The article provides no source for this assertion and this Mozilla blog post is pretty clear that DNS-over-HTTPS is off by default and defaults to CF if you enable it or are part of the shield study (which requires nightly and opt-in to shield studies in the first place) https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...

If this is true, then I'm okay with the feature being available if it is opt-in. Although I generally think this is a concern better left outside of the particular browser I'm using. If I want to route DNS queries through a third party then I'd like to do that for all my network traffic, not just my browser.

But that’s a different argument you’re making. For many people, routing the browsers DNS via a secure channel is a substantial improvement. You’re still free to route all your network DNS via DoH, there’s software for that. But until DoH is the operating systems default (or at least a non-expert option), this can be a viable improvement.

Yes. If it's opt-in, then I can certainly live with it and I understand why people might use it. I'm just pointing out that features like these, while well intentioned, still add bloat to the browser. Sometimes saying no to feature inclusion is the right thing to do in the long term even if it has a use in the short term. I'm a big believer of the Unix philosophy of do one thing and do it well.

Modern browser are basically OSes not by coincidence but because they are basically used as OS replacement. I think Tanenbaum (citation needed) wrote that an OS basically does two things: abstracting the HW and managing resources. Browsers do the latter as much as an OS

For many it is, but for billions it isn't. For those where it is an improvement they can opt in.
Xylakant 8 days ago [flagged]

I think you substantially overestimate the number of providers that behave ethically with regards to DNS and substantially underestimate how many people have shitty ISPs. You seem to have a very skewed view of how the number of internet users distributes across the world. Even in Europe, providers are not refraining from hijacking DNS and using DNS blocks for certain sites.

I think you substantially underestimate the number of networks that use split-horizon DNS for their functioning, and where hijacking the DNS is going to cause significant breakage.

Which are almost zero home network of non technical users

I've never seen any marketing materials, where Mozilla limits themselves to non technical users with zero home network. Did you?

No, but they do exist and specifically in this case (since they mention public wifi) pro users capable of configuring their system dns might not be the only target audience

So make it active only for public wifi, or whatever is labeled as public network by the operating system or firewall? Certainly not all networks.

I agree. I use DNSCrypt and route my requests through a different server each time.

That said, Joe User doesn't know how to setup any DNS server. Even going into Window's Control Panel gets Joe User anxious. Joe User doesn't care enough about privacy to learn how to set it up system wide. And for Joe User this would cover 99% of his internet usage.


Why doesn't control panel have a roll-back function?

And break his favourite BYOB device that he brings to the work.

It's currently an experimental feature not enabled by default and with no UI to change settings outwith about:config.

In the current release version of Firefox (61.0.1) the provider parameter (network.trr.uri) is blank and not set to Cloudfare out of the box.


> There's nothing sneaky going on here;

It bloody is. Egregiously so. If they are deviating from expected behaviour[1] they should obtain informed consent and even then it's unethical. Half of Mozilla is screaming decentralisation[2], the other is centralising the web as fast as they can. I still haven't forgiven Linux Mint for similar shenanigans[3].

[1] Users understand instinctively the principle behind reverse dns lookup. If ISPs can resolve at least portion of domain names then it doesn't make sense to then introduce another completely random third party that isn't strictly necessary for the process.

[2] https://hacks.mozilla.org/2018/07/introducing-the-d-web/

[3] https://bugs.launchpad.net/linuxmint/+bug/1133777


> My local ISP seems more trustworthy to me than a big US-based corporate which acts under the guise of a selfless privacy rights defender.

I have never trusted any local ISP. They’re commonly expressly allowed by law to share roughly whatever they like about you†, and they are known to do so.

Cloudflare has at least promised not to be evil, and is to be audited annually concerning it. If they desire to be evil I have no doubt they could wangle it, but I still trust them way more than I trust any ISP, because they’re already known to be evil under these definitions.

----

† (This is a gross simplification, but it’s broadly true enough in most countries.)


> (This is a gross simplification, but it’s broadly true enough in most countries.)

Seems like you forget Europe and e.g. GDPR.

It would be a big no-no in Denmark: My bank has one division for normal accounts and another for mastercard. The 2 divisions are separate companies, so I have to sign a paper to allow the MasterCard division to know about my normal account.

So Danes have no hesitation giving out personal information as they know it’s protected by law. “We don’t sell your info” is redundant in Denmark.


I wish that was the case. TDC (the largest danish telco) actually sold information about mobile users, including roaming users to VisitAarhus. Specifically, it was data about the locations of mobile users.

Danish article on the subject: https://www.version2.dk/artikel/tdc-saelger-data-mobilbruger...

So there is still plenty of reasons not to trust your ISP in Denmark and Europe in general.


Telia did the same thing in Sweden some years ago. There are however ISPs who have a business model based on them having a very high profile in personal integrity politics (like Bahnhof), which I would feel more comfortable with thanany other DNSs

By wouldn’t you expect Bahnhof to offer a DoH-capable resolver for its customers then, that you could use in FF if you choose to enable the feature once it’s out of the experimental phase?

What prevents them from selling aggregated DNS statistics?

For what was queried on their servers.


> I have never trusted any local ISP.

You are forgetting that the author is from Switzerland.


Cloudfare can promise what they want, they can still be subject to warrantless spying by US agencies and not disclose anything about it.

As a user whose trust has already been broken by both ISPs and governments, I see no drawback in participating as a user in this public experiment. What you describe as a drawback is a privacy improvement for me.

The DNS implementation used by every non-Tor user around the world today is already subject to warrantless spying by every ISP and government in the world, due to the property known as “cleartext”. If you opt-in to the Cloudflare trial, you are only at risk of warrantless spying by Cloudflare — rather than every ISP — and the US government — rather than every government.

My cellular ISP sells my DNS queries to advertising networks, and my home ISP is wiretapped warrantlessly by the US government. This experiment decreases the chances of the resale of my personalized data to data warehouses and decreases the chances of success of warrantless wiretapping by my government.

I envy those of you that believe you can trust your ISPs and governments.


And lets not forget that their CEO will arbitrarily censor and stop serving people he doesn't like. He's done it before. He'll do it again. Cloudflare has already lost my trust.

In his blog post on that, he said pretty clearly that he doesn't want and should not have this power. https://blog.cloudflare.com/why-we-terminated-daily-stormer/

(Disclosure: I work for Cloudflare.)


But he does and does. And now in the Perfect 10 lawsuit against your company it's biting you in the ass. Now you have to censor everything. Good going.

But in agreeing to spy they would violate their contract with Mozilla.

Presumably, that would make them liable to damages.

Moreover, they will be subject to audits, where such spying is at risk of getting caught.

This is a lot better than everyone trusting their own ISP.


Cloudflare has already received NSLs. Once they provide both encrypted DNS and TLS-termination for a good chunk of the internet they'll become a juicy target for the three letter agencies and you might not know about it for years.

If you don't live in the US a local ISP might be a lesser evil and I wonder why mozilla should make that tradeoff for everyone.

Sure, some jurisdictions might be worse than the US and TRR might be a win there. But for some it's worse. So we shouldn't pretend it's a one-size-fits all solution.


I wonder what kind of ISPs you use? Here in .ch, ISPs can be rather small and you even know the operators personally. So trust ISP >> cloudflare.

I live in Australia; ISPs are basically all big entities, altogether unworthy of trust. The US is broadly similar. In both countries, you do get some obscure tiny ISPs, but they’re fairly rare overall.

I’ve also spent time in India with a small ISP, and I hated their DNS: they actively intercepted all DNS and replaced it with their own OpenDNS arrangement, involving the horrible NXDOMAIN replacement that was still a thing at the time, and in such a way that you couldn’t opt out of it! I don’t know how trustworthy they might or might not have been (I didn’t personally know them), but I do know that I loathed their technical decisions and would fain have bypassed them.


I get the point. If your ISP is also not trustworthy, the situation probably does not change much for you. Then again, maybe the right solution is to look at how to get back trustworthy ISPs.

Which is a goal to strive for as well however this endeavor is still valid as the client can be mobile and transient across ISPs. So until you can trust all Is as you might come into contact with, having a secure and hardened client is the better of the two.

There are (privacy) pro's and con's to having a small(-ish) ISP. 1: you have a payment relation with your ISP so your identity is 100% known. 2: Operators you know personally might turn against you, as it happens between people.

I use Swisscom (larger ISP here in Switzerland, both for mobile & home connectivity) but damn if I do not encrypt /hide as much traffic (DNS first) as possible to prevent exactly them from being able to see exactly what I do.

I have worked for far larger providers and I have personally investigated 10's of cases where a "roque" operator has fired for "abusing" access to very privacy sensitive data (being it internet access or mobile phone locations etc). As [most of the time|always] in these cases, the offender gets offered a decent exit to prevent (public exposure via) lawsuits so little gets known to the outside world.

In the end it is up to you, but my advice would always be: do not put all your eggs in one basket.


> Cloudflare has at least promised not to be evil

Remember when Google did so, too? Then they bid on military contracts and bought a military contractor.


It may surprise you, but not everyone believes the military is evil, and thus working with them is evil.

Speaking for the US now (this is an outside view) but to me it looks like institutions such as the CIA or the NSA are indeed seen as evil by the majority of the public. Now, both the NSA and the CIA would mean nothing in the medium and long span of time if it weren’t for the power projected and often times actually exercised by the US military. As such, one can be forgiven for looking at the military as “bad”, if only for the fact that it “supports” bad institutions. Or, in other words, you cannot pick the “good guys” out of the military-industrial complex, to think otherwise is just self-delusion.

For me this comparison is seams false as it would work the same way if you replaced "military" with "US taxpayer".

Indeed, all us US taxpayers and, more importantly, citizens are complicity with the myriad heinous crimes of our government. They do them in our name, with our money, and in most cases with our vote.

OK, but I hope that you don't propose vilanizing any support helping US taxpayers because of it, as it was the purpose of the analogy to explore that. Are hospitals evil for providing healtcare to US citizens who are enabling NSA?

No, that's absurd.

Well, military's purpose is killing people. Now if that is evil or not of course depends on your beliefs.

Indeed. My choice of words there was deliberate and a subtle acknowledgement that such things can go awry over time.

Cloudfare engaged in censorship so they've already broken that promise.

But if they violate their promise to Mozilla, won't they be liable? And won't Mozilla have standing to sue?

What do you think damages would be if you violate a contract with Mozilla that puts millions of users at risk? (I wouldn't want to test that)

And won't they get caught during audits? Or at least risk it.


I don't really care about "promises" and contracts made between faceless corporations. I have no reason to trust Cloudflare or modern Mozilla, neither have I a reason to believe Mozilla would litigate against a breach of contract publicly instead of settling privately and secretly to prevent public outrage.

You trust Mozilla code, why not trust them to negotiate on your behalf?

Do you think you'll be able to negotiate a better solution on your own... If so, just change the defaults.


Refusing to host neo-Nazis might be inconsistent, but calling it "evil" is pushing it.

Censorship is evil, regardless of who it is directed against.

"Cloudflare has at least promised not to be evil"

I have a bridge to sell!


> They’re commonly expressly allowed by law to share roughly whatever they like about you†, and they are known to do so.

Why would this not apply to Cloudflare as well?


Because you may live in a country where the government is much more hostile than cloudflare.

Those of us, who live in democracy, can do something about our government. We can do zilch about Cloudflare, when they do something wrong.

> Cloudflare has at least promised not to be evil

lol


It's not a ISP vs Cloudflare issue though, the ISP will know where you are connecting to anyway...

This is such a toxic decision by Mozilla, but I'm not surprised since they have been leaking customer data to other companies (Google) that threw money at them in the past too.


but your ISP will still be able to see all your connections even if you don't use its DNS servers unless you use a VPN... this just spreads the information to a third party.

https://en.wikipedia.org/wiki/Server_Name_Indication#Securit...

Downvote me all you want, but domain names are still being sent to the ISP unencrypted, as of TLS 1.3... so it doesn't matter who processes your DNS queries, your ISP still knows everything about which sites you are accessing... but anyways, bare IP addresses still reveal a lot (metadata)


right - but we're coming for cleartext sni too:

https://tools.ietf.org/html/draft-rescorla-tls-esni-00

interestingly, something like DoH is a pre-requisite for pulling off esni.


that's great, but are you coming for the ip addresses too (probably the bigger challenge)?

wrt esni the anonymity pool is definitely the set of content that can share the same address pool. In a world with lots of CDNS (and several multi-CDN switching services) this covers a huge amount of content - but I agree - not everything.

If you think about the best/worst case scenario, would you be happy if one CDN would deliver everything? I think that we would be in a worst situation... ideally, I think that everyone would have their own servers and that your ISP would not even be able to see which IP addresses you are talking too (completely decentralized)

cdn switchers/sharers are very interesting here. e.g. cedexis

Yes, we are. After ESNI we’re working on DNS IP address randomization.

is that a joke? sorry I don't see how that would help... where could I get more info?

The article is incorrect.

1. TRR is not turned on by default. To turn it on, you need to go to about:config and set network.trr.mode to something other than 0 or 5.

2. Even if trr.mode is turned on, you need to go in and set the DOH server at network.trr.uri. The default is blank. You can set it to any publicly known DOH server (https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-av...), or even your own.

3. The article doesn't talk about how your ISP can use DNS to censor your result - very common, for example, in a country like India where the court orders certain sites taken down. Mozilla's DOH solves this.


The first sentence of the article is about TRR/DOH being turned on by default in the next patch.

Can you point to a Mozilla announcement that says they'll turn on DOH by default in a regular non-experimental non-nightly release?

This is what Mozilla says in their DOH blog:

Our second effort focuses on building a default configuration for DoH servers that puts privacy first.

We are running a shield study where some Nightly users will participate in one or more experiments to help us build out a secure, cloud-based service that handles DoH requests. All Nightly users will receive an in-product notification about these studies.

Cloudflare is our partner for these experiments. When a shield study is active, Nightly Firefox will automatically use Cloudflare’s secure DNS over HTTPS service (though we aren’t using the famous 1.1.1.1 address). The first study will test whether DoH’s performance is up to the task.


> Can you point to a Mozilla announcement that says they'll turn on DOH by default in a regular non-experimental non-nightly release?

Right on their blog (https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove...), quoted by the article:

"We’d like to turn this on as the default for all of our users. We believe that every one of our users deserves this privacy and security, no matter if they understand DNS leaks or not."


That is not an intent-to-ship email on the dev-platform mailing list.

Yes, that's the big issue. Plus, changing to a different resolver is not very simple and most users won't even know.

It would be a big issue, if it was true.

Which is false.

The article lacks instructions about disabling it or using some other DOH resolvers.

about:config -> search for network.trr -> set network.trr.mode = 5 to completely disable it (I do not recommend this)

The curl wiki has a list of DOH servers: https://github.com/curl/curl/wiki/DNS-over-HTTPS

It should also point to "the other side of the story", the benefits of DOH over classic DNS resolving, for example https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove...


Manually setting static resolvers is not adequate in many scenarios.

For example, when the user roams among several networks, and each of them has split-horizon DNS, the user is not going to re-set their setting after connecting to each specific network. Throw in VPN connections and their DNS settings, and you have quite a problem at hand.

There's a reason why DNS settings are traditionally set system-wide via DHCP, not statically. This is a step backwards.


Thanks for the hint! We added that to our blog entry - please let us know if it sounds right to you.

The default is already off[1] though...

Mozilla has stated plans to eventually turn it on by default[2] but I have yet to see any timeline or details of what the default config will actually be. Your article seems to assert that it will be on by default in FF62, where did Mozilla ever say this? Everything I have read seems to indicate that FF62 is just adding support, which is off by default, and requires a change to about:config to enable in the first place.

[1] https://gist.github.com/bagder/5e29101079e9ac78920ba2fc718ac...

[2] https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...


You're operating under the assumption that if this is turned on by default in the future, everything will go to CloudFlare.

While CloudFlare is being used for the opt-in study, you have no evidence that they will be used in any on-by-default scenario. Nor do you have any evidence that only a single DoH provider will be used globally.

Perhaps you should monitor Mozilla mailing lists.


Considering the default is off, anyone that goes out of their way to turn this on should remember how to turn it back off.

Correction: .mode = 0 disables it!

I'm not looking forward to this.

I use internal DNS for stuff I'm running at home (e.g., a NAS, Home Assistant, etc). I don't want to go back to the bad old days of having to remember what IP addresses go with what service.

My girlfriend is not going to like it when Pi-Hole magically stops working because Firefox doesn't respect the DNS settings that are served by DHCP.

My employer uses internal DNS for internal services. The helpdesk is going to have a fun time as Firefoxes across the organization get updated. It also doesn't help that a large number of users are BYOD users, so enforcing certain Firefox settings is a no-go.

Sure, there's instructions to fix it, but it should never be broken like this in the first place.

EDIT:

The article has been updated - it now shows a screenshot from Mozilla's blog[0] which says:

> We’ll use the default resolver, as we do now, but we’ll also send the request to Cloudflare’s DoH resolver. Then we’ll compare the two to make sure that everything is working as we expect.

Cloudflare is going to have a huge list of internal stuff used by Firefox Nightly users, and Mozilla is going to have huge insights into how many people use things like Pi-Hole, internal DNS servers, split DNS servers (e.g., BIND Views), etc. And they're going to be analyzing this data in order to determine how well DNS-over-HTTPS works.

I'm not sure if this is better or worse than I initially thought it was.

[0] https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove...


> Cloudflare is going to have a huge list of internal stuff used by Firefox Nightly users

By Firefox Nightly users who agree to be in the study, yes?


First, I have to say that I love cloudflare, but the last thing we need is the centralization of all our DNS resolution to them. Please Mozilla, don't give anyone too much power.

And if DNS over HTTPS is the way to go (which might be), give the user a choice. There are 3 public resolvers already offering DNS over HTTPS:

  Google[1] (was the first one to support it) 
  CloudFlare[2]
  CleanBrowsing[3] (for security and/or adult filtering)
And hopefully Quad9 will join the list soon. I hope this doesn't become a "search engine" war that the company that pays more becomes the chosen DNS. Please Mozilla, don't do that.

* 1: https://developers.google.com/speed/public-dns/docs/dns-over...

* 2: https://developers.cloudflare.com/1.1.1.1/dns-over-https/

* 3: https://cleanbrowsing.org/dnsoverhttps


What about if you have private DNS servers that has sites that cloudflare does not have? For example internal intranets etc?

So mozilla will not work at all in that case?


The expected common deployment mode is soft fallback - using traditional DNS if connections cannot be made via the DoH resolved address. Captive portal provides the most common use case.

There is a hard failure mode available that you can use for better security if you're in a vanilla Internet environment - but we don't see a way to broadly offer that choice other than in technical documentation.


Thanks for answering questions in this thread. This makes a lot more sense - so LAN-only names would still resolve then.

This still seems like it could cause problems in certain circumstances, e.g.:

- The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole)

- An internal host also happens to resolve on the external DNS, though with a different IP. E.g., a company could have its public DNS set to a catchall entry *.company.com, but at the same time could have dev.company.com set to a special IP inside the LAN. This setup seems also required if you want to use Let's Encrypt internally.

Those scenarios seem difficult to manage, because they are potentially indistinguishable from attacks. Do you have any solution for that?


The most important attribute of DoH is, imo, authentication with the resolver. The browser has a terrible time with 3rd parties messing with the DNS stream. DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to.

> - The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole)

The right answer, imo, is that the pihole implements doh and firefox is configured to use it directly. The reoslver is authenticated and you're sure you're using the policy you want. A quick search indicates some interest in doing just that - I know stubby is working on doh support.

in the interim of course, you can just disable DoH and hope that your unauthenticated udp makes it to the pihole and back in tact :) - there's never going to be a lock in.

> An internal host also happens to resolve on the external DNS, though with a different IP. E.g., a company could have its public DNS set to a catchall entry *.company.com, but at the same time could have dev.company.com set to a special IP

so far as we can tell, this doesn't seem to be a significant pattern with http content.. at least not to the point where both split horizon addresses correctly handshake from each side (defeating the fallback logic). I suspect this has to do with http caching not working very well in such a setup either. This is exactly what we're looking at error rates trying to determine, but the prevalence of other open resolvers like quad 8 seems to have really reduced the frequency of this kind of thing.

There are certainly some dev environments at the tail that will require manual config.. but for the most part those environments already have a bunch of manual config so this isn't a huge leap to do.


> DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to. [...] The right answer, imo, is that the pihole implements doh and firefox is configured to use it directly.

This is a worthwhile goal. However, the current UI heavily discourages changing the preset resolver (you have to skip through a warning page, know the correct properties, etc). Do you have any plans for a more acessible UI to set resolvers?

Another point, I think, is that DoH endpoints could be abused by malicious (non-browser) software to hide its communication endpoints.

E.g., when public DoH servers are common and encrypted SNI is operational, a mobile app or IoT device could completely hide with which hosts it is communicating - with no option for the user to override. This doesn't seem to be in the interest of privacy or transparency of data use.

Similarly, a trojan could use a public DoH server as a secure channel to get C&C server addresses, without the name of the C&C server ever getting exposed - or it might even directly obtain commands through it, if the commands can be embedded in DNS records.


Hopefully it caches the domains that it found to be internal (not just the records), or there is going to be a lot of data leakage of internal records. There is already way too much of that, given how most folks have their resolvers configured poorly, but this would only make it worse.

That one actually breaks in the new release :-/

Wow.

Firefox, out of the box, is going to be perfectly useless to me.

At home, I have an internal DNS resolver which is used for internal stuff (e.g., Home Assistant, a friendly name for my NAS, etc). This will be broken. Likewise, I've got Pi-Hole set up for my girlfriend, but that's going to stop working as soon as her Firefox updates itself to this version.

At work, we have an internal DNS resolver for obvious reasons. All of the users who use Firefox will suddenly be unable to access internal sites. That's going to be a fun time for the helpdesk as 3000+ staff start receiving updates.

I know it can be turned off, but having to track down a hidden setting to make the browser actually function correctly is insane.


This isn’t enabled by default on any versions of Firefox and Mozilla does not have a timeline for enabling this by default on any future versions of Firefox.

Is there a tracking bug for this on Mozilla's bugzilla?

Some evidence to back that up would be good.

It would actually leak the names to the external resolvers.

fwiw, the .local TLD will never be run through TRR (unless fallback is completely disabled). Ref:

https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfba...


I think as far as browsers are concerned, there are no private DNS names anymore for a good while already - either everyone on the internet knows your DNS or it doesn't exist.

See the similar problem with TLS certificates...

(edit) Ok, that was indeed put more dramatically than necessary. My point is that private DNS names seem to be heavily discouraged by browsers default configurations.

You can change both the DNS resolver as well as install custom CAs - however, this has to be done again for each client. If you want to have your sites visited by clients that you don't administrate, you're out of luck.

(warning - rant follows) The direction browser vendors would like the ecosystem to move also seems quite clear to me - there is a strong push to get everyone on HTTPS, at the same time CAs are themselves increasingly regulated by browser vendors and cannot hand out certificates for IPs and private DNS names anymore. Now the next step seems to be DNS. If that is not a platformisation of the web, I don't know what is.


Perhaps if you only work for small organisations. Medium to large organisations tend to handle these issues relatively smoothly, with company computers and devices usually having their root CA pre-loaded into the trust store - or requiring users to do it themselves in order to connect to the intranet.

Just because you don't see it, doesn't mean its not there!


Can only heavily disagree with this one. The reason why BIND has views is because bigger organisation (like universities) employ different views depending on whether you are internal or external.

But this is the exact point. With DoH active by default (and no custom configuration set), every instance of Firefox will appear to be querying your DNS from outside, no matter if the machine is inside the LAN or not.

Why do you think that? My home router will happily resolve sites that only exist on my home server.

Your home router will. However, as the article made clear, you won't be able to open that site in Firefox.

Even if you were, you won't be able to get a public TLS certificate for that site, making you unable to serve the site as HTTPS and locking you out of many current and all(!) futue JS and CSS features.

Yes, you can solve both problems by installing overrides. However, this has to be done separately for every client that you want to use and (potentially) for every app that you want to connect to.

If you want to make an intranet-only web page that "just works" with off-the-shelf clients, you'll have to stick to public domain names.


That's my point. My parent said that private DNS names have been dead for a while, and I said they aren't.

Updated my parent comment to more precisely say what I meant.

Which is clearly bonkers. Why would Firefox deliberately break people who run Nextcloud on a Raspi at home? There must be something missing here.

https://wiki.mozilla.org/Trusted_Recursive_Resolver

>Set `network.trr.mode` to 2 to make DNS Over HTTPS the browser's first choice but use regular DNS as a fallback

So regular DNS entries will still resolve after the lookup over DoH failed.


But which user will be able to figure that out?

Maybe all the users that turn TRR on in the first place? It’s default off and you need to enable it in the expert configuration menu. I don’t expect it to be enabled by default without a reasonable config UI.

The article states that DoH will become on-by-default in september.

In general, I find it highly unlikely that it will stay off-by-default forever, because there is no way to have any meaningful adoption of it as an expert-only feature.


The article is wrong.

Nothing in Mozilla’s communication even hints at DoH becoming default on any time in the nearer future. I’m certain Mozilla would like encrypted DNS by default, but not at all cost. It will probably land as a generally available feature in September, but still default to off and still be behind about:config. There are many expert features hidden in about:config that might never become default or only after a substantial shakedown period. Third party isolation, for example. So it would not entirely surprise me if DoH would remain an expert feature for a long time. And I’m certain it won’t become default on without a very clear config UI. Messing with name resolution has massive impact on a lot of setups.


My home router will. My browser will also open the site. My browser might not necessarily be Firefox, though.

For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed, so whoever controls that domain, can make certs for its resources. If you do that at home, it is no problem to make your own CA and use it for your home resources. It is just few commands with openssl, which you have already installed anyway.

> If you want to make an intranet-only web page that "just works" with off-the-shelf clients, you'll have to stick to public domain names.

That's not true at all, see the previous paragraph.


> For internal sites, you don't need public TLS cert. If your device is joined to a domain, you already have a private CA cert installed

Thanks for that info, I wasn't aware of that. However, to my knowledge, Firefox doesn't use the OS trust store but its own. So for clients using Firefox, you'd still have to install the cert, wouldn't you?


For the ESR release, you can use Group policy (Windows only) or policies.json (all systems) to make it accept the system cert store.

For all releases, you can make the process of joining the domain to also include installing the cert into Firefox's store. For example, the Redhat's ipa-client-install does install the certificate into the Firefox store by default.


Does Firefox enforce HTTPS for IPs in the same subnet?

> You can change both the DNS resolver as well as install custom CAs - however, this has to be done again for each client.

That's exactly what Active Directory and FreeIPA do. They have their own CA and once you join the respective domain, you will get the CA cert installed. Hence, using the internal resources is not a problem.

There is and never will be a good reason to publish to the world, what your _kdc._tcp.yourcorp.com is.


More information: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-pr...

According to this page:

- you can already test this right now

- you can provide your own server

And some more: https://en.wikipedia.org/wiki/DNS_over_HTTPS


> - you can provide your own server

Nobody will do this except for maybe 5 individuals and a few dozen cooperations simply because there are no other public DoH servers around.


Many already run their own resolvers, so providing DNS-over-HTTPS proxy is not a problem.

What is THE problem, is configuring the browser. No one is going to reconfigure their browser after each connection to a different network. There's a reason why we moved from static configuration towards DHCP, which can configure network-specific settings. DNS is a network-specific setting, and Mozilla is breaking it.


That’s really the issue I think, has to be a public server if it’s going to work for mobility.

Fixed desktops maybe, but a laptop or phone?


Split horizon was always a bad hack, there has always been alternatives. DoH could be used on the default DNS servers too, there is value of encrypted DNS on LAN as well.

> Split horizon was always a bad hack, there has always been alternatives.

I always see this repeated as a mantra, but never it's rationale. No company is going to advertise their internal infrastructure needlessly. There's no upside in the world knowing that your _kdc._tcp.company.com is 192.168.10.20; but there are downsides.

> DoH could be used on the default DNS servers too, there is value of encrypted DNS on LAN as well.

Sure, but hardcoding or statically-configuring the value is not the way. LANs need to have their DHCP tags respected. If one of them is "use this URL for DoH-server", that's fine.


No other public resolver?

https://developers.google.com/speed/public-dns/docs/dns-over... https://ripe76.ripe.net/on-site/technical-information/dns-ov...

The DNScrypt project has a longer list here:

https://download.dnscrypt.info/resolvers-list/v2/public-reso...

Keep in mind that this is currently all pretty much experimental.


Many corporations will choose to run their own resolvers for internal services.

Home/small business router vendors already include DNS resolvers on the boxes they sell which work to automatically provide hostnames for addresses that they've served up with DHCP.


> - you can provide your own server

How do I RUN my own server? A few minutes of Googling hasn't revealed any DNS-over-HTTPS server that appears production-ready.


There are a lot of wrappers that you can use to provide a TLS proxy to an existing resolver,a few are listed at the bottom of this page:

https://github.com/curl/curl/wiki/DNS-over-HTTPS


You don't need DoH for that. Just use a VPN and configure it to replace your host's resolver as long as it is up.

Another advantage of using standard UDP-based DNS over a UDP-based VPN is that it can reorder packets in flight, so it should have lower latency than anything TCP-based.


The counterpoint is that traditional DNS has horrendous loss recovery and basically no congestion control and these things definitely benefit DoH at the tail.

QUIC will let us have it both ways (and as QUIC has an HTTP definition, its basically a free upgrade for DoH).


Sure, I don't NEED it right now, but it feels like DNS-over-HTTPS will become non-optional at some point.

I hope I'm wrong about that, but I'd like to prepare a little bit in case I'm right.


> And your ISP knows where you connect to anyways. So the data or information generated by their DNS server provides no additional information to them.

This is not correct. Your ISP only knows what IP you are connecting to and that is not enough in general. E.g. Cloudflare.


With SNI they also know the domain you're connecting to.

There are people working on encrypted SNI: https://huitema.wordpress.com/2017/09/12/cracking-the-sni-en... it'll take some time, but we'll get there hopefull soon.

Good point, but it's not here now. It is however better than the old days where you needed your own IP address to do TLS/HTTPS.

That might be true in the future if and when SNI encryption is widely implemented.

and the internet becomes sufficiently centralised that you only access a few IP addresses behind which most services are hosted. In other words, we can either

a) trust our ISP with DNS queries and IP addresses which fairly uniquely identify services or

b) trust Cloudflare with DNS queries and our ISP with IP addresses which fairly uniquely identify services or

c) move everything "behind Cloudflare" and solely trust Cloudflare

Given that I can cancel my ISP’s contract, I can hold them accountable if they spew my data into the internet and I have no idea who Cloudflare is or what their aims are, I’d much prefer a) over c). b) is just worse than a) or c).


I rather use a DNS cloud that promises to wipe logs every 24 hours than a DNS server of an ISP who is guaranteed to spy on me.

Great! And you can already choose to do so. But it seems pretty likely that Firefox will be making that decision on behalf of all its users (except those with the wherewithal to know how to opt out), without effectively communicating the risks of that decision to them (based upon their communication about this feature so far).

It’s currently an expert feature that’s off by default. There is documentation in the wiki and a blog post on the nightly news blog for those that are interested in turning it on. It’s quite the opposite of opt-out. It’s opt-in for the technical inclined. What would your expected level of communication be?

I host my own DNS resolver on a dedicated server, Firefox hijacking my DNS traffic without telling me is definitely not an improvement. It can be a nice feature in some situations but having it activated by default without explicit consent should be a big no-no.

I hate this mentality of "our users are complete idiots and we know what's good for them" (I call it the "Gnome" mentality).


I am of the same opinion and this is an experimental feature turned off by default which is why there is no UI for it.

I am imagining that if it goes live the UI will probably be like the Search Engine configuration with a default you can easily change.

Still annoying to have to change and almost impossible to notice if it should change, but not as bad as it's being made out to be.


Countries other than the US use Firefox, my ISP doesn't spy on me. Cloudflare might.

Considering US law, you have to assume they do.

There are many public DNS providers those promise to not logs DNS queries. I don't know precisely but if Mozilla forces user to use Cloudflare DNS is the deal breaker.

They don’t. It’s the default if you choose to enable the feature, but there are other compatible DNS providers, pick any that suits you (or just don’t enable the feature and keep doing what you’re doing now)

It is especially surprising, because so far Mozilla could always be trusted.

False dichotomy. I.E. those are not the only 2 options.

apt-get install unbound

Well, you have to trust some third party. Personally, I think Cloudflare's DNS is pretty trustworthy based on what we know. It's WAY better than sending unencrypted DNS requests to arbitrary network-dependent third parties, in my opinion.

If you gravely fear Cloudflare for some reason, Google also provides a DNS over HTTPS server, along with a couple others. You can probably set Firefox to use that.

But if we we're OK treating this as insensitive data not needing encryption before, worrying about trusting third parties is not even the beginning of the problem.


There are many countries where ISPs are obliged by law to spy on users, and retain logs for many years. DNS manipulation also used as a cheap censorship mechanism. So Cloudflare easily can be a better option for hundreds of millions if not billions of people. As a rule, local actors present way more serious threat compared to US agencies for majority of the planet's population. That said, Mozilla, of course, must be very transparent with such big changes, and explain them to users not using just "more secure" wording.

So data is safest in the country with the largest spying budget and the most spies. Not convinced.

You are refuting the statement I never made. There's no such thing as general threat. So who's data? If you are Julian Assange you should be afraid of US spying agencies, but if you are an Uzbekistani dissident it's your gov't repressive machine you should care about, and tracking possibilities of your direct adversary will be diminished with the discussed Mozilla's move. If you are an average Joe in a small town you may find it safer to trust faraway commercial entity rather then your neighbor's nephew who works in a local ISP.

I use Cloudflare's resolver, but I actually agree with this. I don't want every device in my local network ignoring my Pi hole or my custom DNS entries, I don't want the device of everyone in my country being subject to surveillance requests from the NSA (and Cloudflare is legally (if you call warrantless wiretaps legal) required to comply), and I don't like the centralization this brings.

If I recall correctly, this also breaks geographical-based DNS resolution?


> I don't want the device of everyone in my country being subject to surveillance requests from the NSA (and Cloudflare is legally (if you call warrantless wiretaps legal) required to comply), and I don't like the centralization this brings.

Agreed that this introduces additional centralization. Maybe Mozilla could work to with other third parties in different jurisdictions to see if there's interest to spin up additional DOH servers. That said, if your threat model includes the NSA then this would probably be far from sufficient.


As always, it's not "the NSA is targeting me specifically", it's "they're doing dragnet surveillance for potentially 'interesting' data and who knows how they'll choose to harass me".

There is literally no single country in the world I would like my data sent to than the US. Even China is preferable.


There are other DoH providers.

That depends. Cloudflare probably (did not check) uses anycast and thus their DNS servers are actually in the specfic region. This however does not change the problem of the legal authority still being in the US, as you pointed out.

For reference, the privacy agreement between Cloudflare and Mozilla: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...

Great, all your data is stored for 24 hours and then collected in "anonymised" form for further processing and "internal research"! Also no mention of penalties, either for Cloudflare as a company or the responsible employees (starting with the CEO) in case of a violation. And no notice period of any time should Cloudflare decide to change those terms and have thousands of browsers still pointed at its resolvers.

Why would this make Cloudflare appear remotely trustworthy?


It's a legally binding contract between Cloudflare and Mozilla. If Cloudflare were to violate it, Mozilla could sue and a judge would determine the penalties for Cloudflare. There should be some rough guidelines written into law as well.

And we're definitely not talking about small amounts. Cloudflare violating it would result in Mozilla violating the privacy of millions, which can be interpreted as significant damages to the citizens. They're also both situated in California, so privacy will be valued by a judge. Given Mozilla's public image as a privacy-friendly organization, they could also push charges for damaging that image.

That penalty + the damage to Cloudflare's own reputation, I cannot imagine they would survive.


Data from temporary logs will be moved (anonymized) to permanent logs. For me this reads as: once it is there, it is not your data anymore, not from Cloudflare Resolver for Firefox and not PII, so we can do ~whatever we wish.

IANAL but it looks like extreme weasel wording (and not even remotely GDPR compliant), there is nothing to violate.


Note also:

> Cloudflare will also collect and store the following information as part of its permanent logs. [...]

- Aggregate list of all domain names requested

So while they might not associate it with a person, they will collect all domain names they get and store them for their own purposes.


restricted to: "solely to improve the performance of Cloudflare Resolver for Firefox and to assist us in debugging efforts if an issue arises"

Nothing against Cloudflare, but I don’t think it is good in general for the Internet that they are getting so critical.

For them this sounds like a good deal (is money involved here?). Having more control of DNS should mean they can provide better service for their customers.


> For them this sounds like a good deal (is money involved here?).

There is a lot of money involved. When you resolve DNS only over Cloudflare, all Cloudflare sites will have a much lower DNS resolution time than any domain that is not hosted by CF's DNS service. CF can also do geo DNS more efficiently, potentially saving millions in edge nodes.


Agree - cloudflare probably does a good job here, but again: centralisation is making the Internet weaker. Also hands even more control into one entity's hands

Cloudflare shows how broken the internet is. For example, imagine a world where you would clearly see that your computer or toaster were used in a botnet because it showed up in your billing. DDoS wouldn’t be $5 anymore.

Saying Cloudflare ruins the decentralized internet got the events out of order.


So yet another step to centralize security with browsers and override any descisions of local admins. Great...

Where exactly Firefox/Mozilla people say that they plan to enable it by default?

Sigh. Mozilla had just made Firefox usable again... And now good reasons for leaving it again are coming up.

Firefox is still great. You can turn this off trivially or provide your own server. This is, however, an excellent step towards securing the web.

Fully agree. I was also about to take the final move chromium -> firefox. Maybe it's time to fork firefox?

You can disable it...

But for the majority of users, it's probably good to have Mozilla negotiate favorable terms with a DNS provider that can be subject to audits, etc.

Who audits your ISP? Does Mozilla do that?


So what is the alternative? Chrome, edge, and Vivaldi?

I've been using Brave. It's beta quality software but works surprisingly well.

Brave on Android is the way to go. Literally the best browser.

I think it's a great option for people who can't trust their isp. I've been using it in nightly for a month or so and it works nicely.

Making it default would be controversial though. Right now it's opt in.


Most important point from the article

"Let's stop here for the moment and repeat: With Mozilla's change, any (US) government agency can basically trace you down." - with ease I might add.


I was thinking about this issue. Once this feature is on by default, all Firefox DNS query goes through the Cloudflare, a for-profit company which resides on US whose government is infamous for spying everything.

My conclusion is, what's the difference?

Currently, Cloudflare is one of the major CDN in the world and most traffics goes through them.

Even worse, by it's nature, Cloudflare and most of the CDNs are practically doing MITM attack so they can cache the data. For that, HTTPS isn't that secure the most browser vendor want us believe to be. The rise of CDN cause serious single point of failure but most of us don't worry about it like DNS.

To solve this problem, we need to invent completely decentralized new network that doesn't relies on the current Internet even at the physical layer. Probably fallback to the level such that we carry storage by foot or pickup dead drops.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: