2 ms·

>What DoH does break though, is internal DNS resolution of internal intranet hosts. Those would obviously be corporate owned as they would obviously have a corp

>What DoH does break though, is internal DNS resolution of internal intranet hosts. Those would obviously be corporate owned as they would obviously have a corporation specific domain anyways, so no MitM is needed anyways because the admin can just look at the traffic on the server side. >This means that as DoH becomes more widely used, a corporation has only two options to continue to be able to allow users to connect to internal sites, both of which are worse from a security standpoint than the status-quo: Why not just have an internal forwarder that does DNS-over-HTTPS? Browsers would send traditional DNS to the forwarder, and the forwarder would do DoH from there.

LinuxBender 8y ago
This would also assume all the users would know how to configure this specific endpoint, or that IT staff do this for all the users. Today there isn't a good story around automating this process in heterogeneous shops. (windows, mac, linux, misc api tools) If a browser has a default option to use CloudFlare, Google, Amazon or Microsoft, then the user will click the button to "secure their DNS" and suddenly their internal applications may break or do odd things and companies start leaking even more internal records. Some IT departments may try to fix this by deploying configurations for 80% of the use cases and some may just block the public DoH servers. I can think of many ways this could be solved. The point I was trying to convey is that people have not thought this through and implemented this in browsers before corporate infrastructure was ready to accommodate the need. This creates contention and friction that could have been avoided, in my opinion. Adoption is likely to be embraced more widely if more use cases are accommodated.