Change:
This is similar to but, in my opinion, slightly different. The Introduction text says: I guess this implies integrity and confidentiality over the wire. For example DoH doesn't guarantee confidentiality from the DoH server learning the content of the DNS query. Ok so it's pretty clear that DoH focuses on the wire. Someone could argue it's obvious but the document actually talks about it. Then in Selection of DNS API Server the text says: And because it's a MUST, not trusting the server violates the DoH specification and hence its benefits? Patrick made the comment that trust is a client issue (URL) and I agree but there are different kinds of trust against different threats. I think we should tell clients what kind of trust they need to establish. Clients might trust the TLS connection to the server because, e.g., it uses a strong CipherSuite and they can verify the server's identity. At the same time clients might not trust the server to not profile them based on their queries and sell that information to advertisers. (In this case clients might obscure their source IP address) Clients might also not trust that the server is being diligent in checking the RRSIG records for every A record it gets from upstream servers. (In this case clients will do the DNSSEC checks themselves) In other words, clients may have a trusted connection to the server but at the same time might treat the server's application logic as untrusted. What should the client do according to the DoH document? I think the answer is they should use the server because DoH protects queries on the wire and from that aspect the server is trustworthy. But that's not clear by the current language which seems to imply absolute trust for everything. I would propose that the text is updated to say:
I am uncomfortable with this language because it implies some things about how an HTTPS resource is fetched that are defined elsewhere. Heck, with a good cache there might not even be a connection. Let's not go there. The existing text: "Before using a DNS API server for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query, in other words, a DNS API client MUST only use a DNS API server that is configured as trustworthy." It really tries to say the same thing twice ("in other words") - which may cause confusion. They can be blended to be: "A DNS API client selects the URI, and by extension DNS API server, used for resolution via configuration." This does remove an appropriate (imo) MUST, but the next sentence contains a MUST NOT that covers the important part. NAME wdyt?
NAME This text is much better - I support PR Only minor nit is that I might ask it says 'direct configuration' to distinguish it from any type of dynamic configuration?

Discussion:
4. <del> Before using a DNS API server for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query, in other words, a DNS API client MUST only use a DNS API server that is configured as trustworthy. A client MUST NOT use a DNS API server simply because it was discovered, or because the client was told to use the DNS API server by an untrusted party. </del> <ins> A DNS API client uses configuration to select the URI, and thus the DNS API server, used for resolution.  A client MUST NOT use a DNS API server simply because it was discovered, or because the client was told to use the DNS API server by an untrusted party. </ins> This specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as trusted DNS API