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