Original text:
5. <del> To make a DNS API query, a DNS API client sends an HTTP request to the URI of the DNS API. The URI scheme MUST be https. A client can be configured with a DNS API URI, or it can discover the URI.  This document defines a well-known URI path of "/.well-known/ dns-query" so that a discovery process that produces a domain name or domain name and port can be used to construct the DNS API URI.  (See iana for the registration of this in the well-known URI registry.) DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. A DNS API Client encodes a single DNS query into the HTTP request using either the HTTP GET or POST methods. </del>  When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header These examples use HTTP/2 style formatting from RFC7540. <del> For this example assume a DNS API server is following this specification on origin https://dnsserver.example.net/ and the well- known path.  The DNS API client chooses to send its requests in application/dns-udpwirefomat but indicates it can parse replies in that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del>  The same DNS query, using the POST method would be: 8.1. <del> This specification registers a Well-Known URI RFC5785: URI Suffix: dns-query Change Controller: IETF Specification Document(s): [this specification] 8.2. </del> 9. Running DNS over HTTPS relies on the security of the underlying HTTP

Reviewer comments:
and
The draft says: But it probably needs to describe at least one way to perform that automated discovery. It's probably not a good idea to have people attempt to guess.
fwiw the .wk is used here so that that when a request/response pair is pushed the client understands this to be DoH. Its probably also helpful to have a well-known path here for the normal so that defaults of https://, 443, and the default path can be used in configuration systems that might only be capable of a hostname. (e.g. my DoH server is at URL).. I'll work on text.
I think I can future proof for the context I want using a response header instead of a well known.. imo that's kind of ignoring the point of the path - but whatever. Maybe I'll propose x-well-known :)

Revised text:
5.  <ins> To make a DNS API query a DNS API client encodes a single DNS query into an HTTP request using either the HTTP GET or POST method and the other requirements of this section.  The DNS API server defines the URI used by the request.  Configuration and discovery of the URI is done out of band from this protocol. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header These examples use HTTP/2 style formatting from RFC7540.  <ins> These examples use a DNS API service located at https://dnsserver.example.net/dns-query.  The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </ins> The same DNS query, using the POST method would be: 8.1.  9. Running DNS over HTTPS relies on the security of the underlying HTTP