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.
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).
"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."
Of course the article is wrong. Classic FUD.
> 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.
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,...
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.
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.
> 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.
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.
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.
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.
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.
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
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
This could include 3rd party reviews, etc.. Who knows?
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.
It also promises not to store your IP associated with the DNS requests https://developers.cloudflare.com/184.108.40.206/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/
Moreover, cloudflare would be in a legal minefield since Mozilla would likely have standing to sue, if cloudflare violates its own terms of service.
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).
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.
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.
Won't they still see which website you then request?
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'.
However, admittedly I'm just reacting to you using the term "whole point" in conjunction with something it's failing to do.
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.
CF is a partner in studying an experimental feature
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.
Putting everything, even lower-than-http level things on top of HTTP is a horrible idea, introducing yet another layer of abstraction.
* 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.
Your browser is not special, everything could benefit from secure DNS.
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.
They don't have to since http(s) is TCP and not UDP?
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.
OpenNTPD also uses HTTPS (TLS, technically) by default .
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.
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.
This is the very goal of this study - to determine how feasible is it in the real world and what's the performance impact.
Why is it better than DNS over TLS? All I can see here is increased overhead.
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...))
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
You also have no reason to trust cloudflare, at all.
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.
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.
It bloody is. Egregiously so. If they are deviating from expected behaviour they should obtain informed consent and even then it's unethical. Half of Mozilla is screaming decentralisation, the other is centralising the web as fast as they can. I still haven't forgiven Linux Mint for similar shenanigans.
 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.
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.)
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.
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.
For what was queried on their servers.
You are forgetting that the author is from Switzerland.
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.
(Disclosure: I work for Cloudflare.)
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.
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’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 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.
Remember when Google did so, too? Then they bid on military contracts and bought a military contractor.
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.
Do you think you'll be able to negotiate a better solution on your own... If so, just change the defaults.
I have a bridge to sell!
Why would this not apply to Cloudflare as well?
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.
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)
interestingly, something like DoH is a pre-requisite for pulling off esni.
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.
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 220.127.116.11 address). The first study will test whether DoH’s performance is up to the task.
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."
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...
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.
Mozilla has stated plans to eventually turn it on by default 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.
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.
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.
The article has been updated - it now shows a screenshot from Mozilla's blog 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.
By Firefox Nightly users who agree to be in the study, yes?
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 (was the first one to support it)
CleanBrowsing (for security and/or adult filtering)
* 1: https://developers.google.com/speed/public-dns/docs/dns-over...
* 2: https://developers.cloudflare.com/18.104.22.168/dns-over-https/
* 3: https://cleanbrowsing.org/dnsoverhttps
So mozilla will not work at all in that 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.
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 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.
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.
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.
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.
Just because you don't see it, doesn't mean its not there!
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.
>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.
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.
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.
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.
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 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.
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.
According to this page:
- you can already test this right now
- you can provide your own server
And some more:
Nobody will do this except for maybe 5 individuals and a few dozen cooperations simply because there are no other public DoH servers around.
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.
Fixed desktops maybe, but a laptop or phone?
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.
The DNScrypt project has a longer list here:
Keep in mind that this is currently all pretty much experimental.
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.
How do I RUN my own server? A few minutes of Googling hasn't revealed any DNS-over-HTTPS server that appears production-ready.
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.
QUIC will let us have it both ways (and as QUIC has an HTTP definition, its basically a free upgrade for DoH).
I hope I'm wrong about that, but I'd like to prepare a little bit in case I'm right.
This is not correct. Your ISP only knows what IP you are connecting to and that is not enough in general. E.g. Cloudflare.
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 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 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.
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.
If I recall correctly, this also breaks geographical-based DNS resolution?
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.
There is literally no single country in the world I would like my data sent to than the US. Even China is preferable.
Why would this make Cloudflare appear remotely trustworthy?
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.
IANAL but it looks like extreme weasel wording (and not even remotely GDPR compliant), there is nothing to violate.
> 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.
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.
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.
Saying Cloudflare ruins the decentralized internet got the events out of order.
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?
Making it default would be controversial though. Right now it's opt in.
"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.
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.