How does this prevent a random application from making an HTTPS request to a random hard-coded IP address? Similarly, how does this prevent an application from making an HTTPS request to a generic host (e.g., api.example.com)?
This is what DoH looks like from outside the application. You can't really tell that it's DoH since it's just an HTTPS connection, which is kind of the whole point of it.
Yep with applications hardcoding addresses and utilizing certificate pinning, there's nothing the device owner/homeowner/network admin/system admin can do to inspect or modify DNS over HTTPS traffic, other than uninstall the application or block the connection entirely. Increasingly, blocking connections breaks the app so you almost might as well just uninstall the app or block it from being installed on managed endpoints.
> How does this prevent a random application from making an HTTPS request to a random hard-coded IP address? Similarly, how does this prevent an application from making an HTTPS request to a generic host (e.g., api.example.com)?
I think that, franky, even without DoH, that ship has sailed. WhatsApp and Telegram (to name a few) is known to embed IP addresses into their applications. It is silly to assume that not standardizing DoH will not result in the same situation, and I imagine there are custom DNS bootstraping happening, for good or evil.
Theoretically you could domainblock known DoH servers that certain applications would use.
But yes, I believe that if an application try hard enough there are ways to bypass any set of rules you set on a device. Luckily, most applications just use the internal libresolv for any domain resolving needs.
This is what DoH looks like from outside the application. You can't really tell that it's DoH since it's just an HTTPS connection, which is kind of the whole point of it.