> DoH is the improved protocol.

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.

The RFC doesn't provide any method to discover the "URI Template" of a domain's authoritative DoH server. The existing NS records only[2] include a domain name. This omitted feature appears to be intentional; RFC 8484 only says[3] that configuration of the "URI Template":

    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).

Even worse, the protocol seems to require[3] aggregating all requests through a single DoH server:

    A DoH client MUST NOT use a different URI simply because
    it was discovered outside of the client's configuration

That seems to forbid the fundamental idea of discovering delegated nameservers. Why would a core feature of DNS be forbidden? Apparently from a concern[3] that allowing unrecognized URIs:

    may create additional operational, tracking, and security
    hazards that require limitations for safe usage. 

This is a strange concern. If the user wants to perform a DNS request, that's their business. How would this become a "tracking [or] security hazard"? This concern seems to be a consequence of a design goal for DoH:

    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)

DoH is designed to enable performing DNS requests in a web app (which will probably be yet another API I will need to disable). If I'm mistaken and it is possible to use DoH in a recursive resolver, how would that work?

> 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

[2] https://tools.ietf.org/html/rfc1035#section-3.3.11

[3] https://tools.ietf.org/html/rfc8484#section-3