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?
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.
https://searchfox.org/mozilla-central/rev/3fdc491e118c5cdfba...
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.
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.
Just because you don't see it, doesn't mean its not there!
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.