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.
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.
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.
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.
> 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.
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.