That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recursive resolution locally.
It seems like you're only considering privacy at the protocol level. While that's important, it can eventually be fixed with improved protocols. I'm far more concerned about de facto standardizing on requiring a centralized service that necessarily has access to the plaintext DNS traffic. The only way to prevent logging of the user's entire internet pattern-of-life is to not give the entire pattern to a single entity.
To be clear: we should be updating all plaintext protocols with encryption/etc. Both DoT and DoH can help achieve that goal. Some sort of encrypted protocol is needed even when running a recursive resolver (such as DoT). It would also be great if popular OS had built-in support for running a local recursive resolver, OS-level support for DoH/DoT, and other advanced features.
The only reason anyone advocates DoT is because network operators can block it, forcing people to use plaintext DNS. Somehow, the meme has been created that DoT is somehow better or more privacy-respecting than DoH, but that's obviously false.
That doesn't appear to be true, according to RFC 8484. DoH cannot be used for encrypting communication to domain-delegated nameservers. Running your own DoH server just moves the problem to a different host. If I run a DoH server locally as a recursive resolver, the encryption between the browser and the DoH server is useless. The DoH server still sends the requests to domain-delegated nameservers in plaintext.
The protocol is explicitly[1] focused:
on communication between DNS clients (such as operating
system stub resolvers) and recursive resolvers.
might be manual (such as a user typing URI Templates in
a user interface for "options") or automatic (such as
URI Templates being supplied in responses from DHCP or
similar protocols).
A DoH client MUST NOT use a different URI simply because
it was discovered outside of the client's configuration
may create additional operational, tracking, and security
hazards that require limitations for safe usage.
Two primary use cases were considered during this protocol's
development. These use cases are [...] allowing web applications
to access DNS information via existing browser APIs in a safe way
consistent with Cross Origin Resource Sharing (CORS)
> There's nothing "centralized" about it
Requiring that a client "MUST NOT use a different URI" is the very definition of a "centralized" protocol. Moving to DoH from my existing local recursive resolver would be a huge loss of privacy. If there a way DoH can compartmentalize DNS requests to the domain specific nameservers, I would like to know how.
[1] https://tools.ietf.org/html/rfc8484#section-1