It's nice that browsers are likely offering an opt-out. However it seems likely to me that DoH will soon be used by non-browser apps as well, which are in no way obligated to provide an opt-out. What will you do about them?
The target is not Application Level DOH, Firefox implements DOH now because it will take a while until OS' ship it, and the OS vendors want to know it's worth it first.
Once OS vendors include support, your pihole can run a DoH server locally and all apps in your network use that DoH server.
I don't believe OS-level support would be relevant.
Once there is a decent
set of public/commercial DoH servers available, devs can simply follow the browsers' example: Directly embed a DoH client into the application and supply a hardwired list of URLs and certificates. To my knowledge, you cannot block that with pihole.
At least, if I were an app developer with financial interest in users not blocking my ads and trackers, this would seem like an obvious thing to do.
Well, it has happened like this with TLS certificate validation. In theory, apps can use the system cert stores and you as a user can install custom root CAs if you want to find out what an app is actually sending. In practice, many apps have pinned certificates embedded to prevent that.
> it's just too complicated to be worth it
That's the point. It's complicated and costly today if you have to design your own protocol, run your own DNS proxy and be the target of outrage if someone finds out.
It won't be if DoH normalizes application-specific DNS servers and provides an ecosystem with infrastructure and tooling for it.
I don't think DoH will normalize it. As mentioned, App-level DoH is merely here because the OS-level doesn't support it yet. I don't see how that means DoH will replaced OS-level DNS.
