Hacker News Reader

Comment by selenamarie | Hacker News Reader

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.

View on HN

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

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

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.

Reply on news.ycombinator.com