[xg15]

Thanks for answering questions in this thread. This makes a lot more sense - so LAN-only names would still resolve then.

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?

[patrickmcmanus]

The most important attribute of DoH is, imo, authentication with the resolver. The browser has a terrible time with 3rd parties messing with the DNS stream. DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to.

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

[xg15]

> DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to. [...] The right answer, imo, is that the pihole implements doh and firefox is configured to use it directly.

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.