I'm working on our DoH implementation. I'm guessing this is a split-horizon set up with a domain that resolves both internally and externally. If you are willing, we're very interested in these situations and coming up with heuristics to detect and disable DoH proactively. We're also looking into standards changes that could make these configurations more reliably detectable at the application level. I'm selena at mozilla.com.

As a sysadmin who rails against split-horizon DNS (usually around Active Directory implementations where brain-damaged people have named the AD domain the same as a public Internet domain name) I'm already getting a churning feeling in my stomach thinking about how software is going to mishandle this scenario in DNS-over-HTTPS.

It's going to be particularly god-awful for devices that roam between networks where the "internal" DNS is visible and networks where it isn't. Ugh...

My organization does this (AD domain appears to be the same as the public domain name), and I also had problems when I opted into the HTTPS DNS trial. As in, no internal servers resolved.

I had thought that internal networks these days would favor multicast resolution (LLMNR/mDNS), but that doesn't appear to be the case here. Admin work is not my wheelhouse, so I have no idea what standard practice is. What is the recommended setup for AD and name resolution configuration?

For now, we recommend having an enterprise policy for the browser configured. That is the best indication we have that the browser configuration is managed and this kind of issue might occur. We're also open to recommendations from admins on other things that might clue us in that we're in this situation. Finally, we're discussing the possibility of establishing a network standard that signals more strongly that "name shadowing" is occurring... like maybe there's some DNS response that can be configured locally that we can look to proactively and then disable DoH.

> usually around Active Directory implementations where brain-damaged people have named the AD domain the same as a public Internet domain name

I don't like this one either, but often it is inherited from the past from other people and it is not going to change.

On the other hand, split-horizon DNS is going to stay with us, even if the AD domain is a subdomain of the public one. Records in the internal zone are not going to become public anytime soon.

A subdomain that doesn't resolve is handled properly -- meaning DoH is then disabled.

Didn't know that, great, thanks.

On the other of the common problems: I assume there is no way to blackhole existing, public records, other than extension ala uBlock/Adblock?

We're working on exceptions support, which would allow specific domains to be looked up via DNS instead of DoH. In that case, mirroring a blackhole list to the exceptions support would result in what you want (I mean, if I understand what you're asking).

That's not entierely true. If the domain doesn't resolve via DoH, Firefox will fallback to the system DNS server.

    network.trr.mode

Needs to be set to 2 (fallback), 1 (pick faster), or 0 (dissable DoH) for this to happen. 3 disables the system resolver.

So, the internal domain names leak to Mozilla unless I disable this totally?

Not to Mozilla, but to whichever DoH service Firefox is configured to use, by default or by the user. Mozilla isn't running a DoH service.

What is the default?

Cloudflare 1.1.1.1 is the default.

So, when the user types in internal.mydomain.com, it gets sent to Cloudflare then they query my public domain server which doesn't have the entry so it falls back to checking the DNS the system has listed. Is Firefox going to cache the IP like the OS does?

The behaviour depends on a few preferences:

* network.trr.mode can be set to 0 (disabled), 1 (race native vs TRR), 2 (TRR first, OS DNS as fallback), 3 (TRR only), 4 (run native and TRR in parallel but use native results, save TRR timings for telemetry), or 5 (off by choice)

* network.trr.uri configures which DoH endpoint is queried

Firefox does maintain a DNS cache, even if you use the native DNS resolver. You can view the cache at about:networking#dns.

So, I really need to set 5 because 0 will probably later become default consent to use DNS-over-HTTPS.

To be fair, can anyone really expect otherwise?

If you insist on using a third party resolver for name resolution they will have knowledge of your queries no matter what the protocol. Doing it over tcp and http is not any better, or worse, than doing it over udp. This is something you have to opt in to.

> This is something you have to opt in to.

Does it come turned off by default?

DNS-over-HTTPS in Firefox? Yes, it does, at the moment. See https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d... -- 0 means it's off.

5 is "off by choice"

Yes, the difference is that 0 is the default value right now, so if you set it in about:config all Gecko remembers is "it's the default" and stores nothing in user.js; if the default then changes the value changes.

5 is not the default, so if you set it it will get stored in user.js and then even if the default changes the value will remain 5.

Do they bother resolving internal domain names such as example.lan? Otherwise that would be stupid and leaky.

Also intranet.mycompany.com. There's not a chance that a resolver would know, which domains are internal and which are not.

With Windows and AD “internal” names are FQDN, which resolves fine with the DNS server provided with the DHCP settings.

Of course DoH will break this and leak. Enterprises everywhere will hate this and ban Firefox.

> Note that with DoH on Firefox, your intranet domains do not work

That’s part of the plan. From now everything is cloud only, and everyone doing anything differently gets thrown under the bus, with less and less control left for the user.

We’re progressing backwards into the future.