DNS over HTTPS is great for the average Joe/Jane, but if you're technical and care about dns leaks ... I'd suggests a DNS over TLS (unbound) + filter setup.

This way your dns traffic is still encrypted, and you retain the capability to block/proxy.

> you retain the capability to block/proxy

Only if you are smart enough to know the browser has its own resolver, and that you need to turn it off first. We may not be able to turn it off in the future, meaning if you want to have privacy you have to run a privacy-specific browser.

This may end up breaking traffic as Google shifts more and more of the web into its proprietary products. For example, Google owns the .DEV gTLD, and makes .DEV domains "completely closed for the sole use of Google". It may at some point buy some other gTLD (such as ".BLOG", which it was outbid for) and decide that the only way for you to access websites with domains using that gTLD is to use Google's DNS API. It may sound crazy, but if they already shut out everyone in the entire world from having a .DEV domain, this doesn't seem much crazier to me.

Let's see where this gTLD thing goes. I can probably see an ICANN or EU intervention in case of a self-mandated requirement of this kind. But, as long as the market stay healthy, more competition can't be nothing than good.

After all, DOH is mainly a technical answer to hijacks (and monitoring). Some ASes seem to have a policy on that... Once it's ready, if it's enforced, you'll have a way to provide a custom resolver you control.

Can't the ISP still have reverse dns on whatever IPs you connect to?

I logged my own traffic for a while in order to have an insight about this.

It came out that in a world of reverse proxies, ddos protection and large tech conglomerates, reverse dns is not a big deal (depends on you behaviour too, smaller websites with a dedicated IP are easier to catch).

But traffic analysis may be a big deal, and the risk of this kind of exposure is not something you can evaluate by yourself. Mix networks are a mitigation.