Draft: draft-ietf-doh-dns-over-https-latest

Commentary: this is a little longer than I had hoped given that bootstrap deadlock is not a new problem for dns introduced by doh .. but the    is worth mentioning . 
 If DOH uses https under the hood , how does this https host name get resolved ? I would have expected this to be mentioned in the RFC , though I did n't see any mention of it , besides OCSP Stapling . Is it assumed that DOH would need to be bootstrapped by traditional DNS ? Or is it assumed that a DOH endpoint would have a TLS / SSL certificate for its ip address ? ( Apparently a certificate for an IP address is possible in some cases , though hard to get . ) I assume DOH is not intended to be used by home NAT routers ? ( How would the router get a signed TLS certificate ? Maybe a DHCP response could say : use this DOH url and trust this self - signed cert for its ip address ( though a certificate might be too big for a DHCP response ) . Or , in cases where no local DNS services are needed , the DHCP response could maybe say : use this public DOH url , here 's the ip address for that hostname ) 
 The document does n't describe how a HTTPS client authenticates HTTPS ... that 's on purpose in order to simply leverage HTTPS without surprises . as a practical matter a number of things can be done . One is TOFU as you suggest . Another is an IP based certificate which you also suggest . Another would be to lookup the name via another , perhaps less trusted resolver , knowing that HTTPS means the IP address is n't part of the security scheme anyhow - its just a route .. subject to blocking , but not to impersonation . Another would be to bootstrap the client with a name and an address instead of one or the other . but as a general matter I think this is one step beyond the scope of the document as its basically writing down the rules for HTTPS . 
 This issue semi - duplicates 
 I think this should at least be called out as an operational concern . e.g. mentioning that you probably need an alternate resolver to find the DOH server , after which a paranoid implementation can re - query for the DOH 's address as an integrity check . 
 This is the direction I have taken for . When opening a connection to the remote DOH server , if an ip was provided , it will just use that , if not , it will try to resolve using the local stub , but that may not work .... Just like an IP has always been provided to bootstrap which nameserver to use , here we need to also be provided a name so we can validate that the server we are talking to is the one we trust .
Paragraph (version B):
A DNS API client may face a similar bootstrapping problem when the
HTTP request needs to resolve the hostname portion of the DNS URI.
Just as the address of a traditional DNS nameserver cannot be
originally determined from that same server, a DOH client cannot use
its DOH server to initially resolve the server's host name into an
address.  Alternative strategies a client might employ include making
the initial resolution part of the configuration, IP based URIs and
corresponding IP based certificates for HTTPS, or resolving the DNS
API Server's hostname via traditional DNS or another DOH server while
still authenticating the resulting connection via HTTPS.