IP over https doesn’t do anything to hide where you are going, which is what DNS is. It tells you where to go. TLS just protects the payload from that IP. Your ISP knows that you went to Amazon, but they don’t know what you bought.
I understand the point you are making, but think that might be a little bit of an oversimplification. If you need true anonymity, only a VPN will help, and that is still only if you are careful. However, in the modern web where everything is behind a CDN, its not true that your ISP has a one-to-one map of your web history. SNI is a major data leak, but once ESNI becomes a normal thing then a lot of browser traffic will simply look like connections to these major CDN providers. Between Cloudflare, Imperva, CloudFront, Google Cloud CDN, and Azure CDN - a huge percentage of websites and services will be indiscernible between each other. And as far as ESNI becoming a thing - since so many services are behind these CDNs, its simply a matter of the CDNs enabling support for it (and broswers) - and not each individual website/service. Anyways, I understand the point you are making about the endpoint IP always being known to the ISP (unless you are on a VPN - in which its the VPN that always knows) - but just knowing the endpoint IP Address is not really enough anymore for a large portion of the internet. At least any server thats concerned about DDOS attacks and isn't large enough to mitigate them using their own resources.
This is something I need to face since having one of those Android devices with hard coded Google DNS (when the local DNS server - pi-hole - does not provide DNS-over-TLS than always 8.8.8.8 is used).
While I try other options to fix this (and use pi-hole and resolve local names in my network) on that device one option would be to have Pi-Hole supporting DNS-over-TLS.
For sure not many users affected, but those who care and rely on Pi-Hole... won‘t be happy seeing there‘s no real progress on this unfortunately. To be honest the root source for my problem is an external decision of a device or OS manufacturer so I don‘t blame Pi-hole in any way - would have just been nice to see it‘s implemented and „just“ needs to be enabled. If it would be that easy.
Years ago we closed this as out-of-scope: FTL is built on dnsmasq, a UDP DNS proxy, and adding TLS meant heavy rewrites, a crypto-maintenance burden, and the risk of getting encryption wrong. The recommendation back then was to put Stubby or Unbound in front.
That reasoning has run its course, and we are happy to move on now: Now that we actually put in full-features TLS encryption support for the webserver we bundled into FTL with version v6.0, we are currently adding native DoT and DoH support directly into FTL, no sidecar needed. The client side (FTL as the encrypted client toward upstream resolvers, which is where confidentiality actually matters for queries leaving your network) is implemented and open for review:
It is deliberately "part 1 of 2" - upstream/outbound (Pi-hole -> Internet -> upstream servers) first. The full plan (OpenSSL migration, HTTP/2, downstream DoT/DoH with FTL as the server, and DoQ/DNS-over-QUIC later) is written up here:
Reviewing takes time, so no promised release date yet, but DoH/DoT support is finally happening natively.