Define interaction with DNS HTTPS resource record

This also makes everything go through "resolve an origin" and removes "resolve a domain" as we need the scheme sometimes.

Closes #1315.

Author: ericorth

fetch.bs

@@ -116,6 +116,12 @@ spec:websockets; type:attribute; text:bufferedAmount; for:WebSocket
         "href": "https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram",
         "publisher": "IETF",
         "title": "Using QUIC Datagrams with HTTP/3"
+    },
+    "SVCB": {
+        "authors": ["Ben Schwartz", "Mike Bishop", "Erik Nygren"],
+        "href": "https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https",
+        "publisher": "IETF",
+        "title": "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)"
     }
 }
 </pre>
@@ -2343,51 +2349,50 @@ functionality.
 
 <h3 id=resolving-domains>Resolving domains</h3>
 
-<p tracking-vector>To <dfn>resolve a domain</dfn>, given a <a for=/>network partition key</a>
-<var>key</var> and a <a for=/>domain</a> <var>domain</var>:
+<p tracking-vector>To
+<dfn export id=resolve-an-origin oldids=resolve-a-domain>resolve an origin</dfn>, given a
+<a for=/>network partition key</a> <var>key</var> and an <a for=/>origin</a> <var>origin</var>:
+<!-- Should we assert the scheme here to be an HTTP(S) scheme or a WebRTC scheme? -->
 
 <ol>
- <li><p>If <var>domain</var> is a <a for=/>host</a> whose <a for=host>public suffix</a> is
+ <li><p>If <var>origin</var>'s <a for=origin>host</a> is an <a for=/>IP address</a>, then return
+ « <var>origin</var>'s <a for=origin>host</a> ».
+
+ <li><p>If <var>origin</var>'s <a for=origin>host</a>'s <a for=host>public suffix</a> is
  "<code>localhost</code>", then return « <code>::1</code>, <code>127.0.0.1</code> ».
 
- <li><p>Perform an <a>implementation-defined</a> operation to turn <var>domain</var> into a
- <a for=/>set</a> of one or more <a for=/>IP addresses</a>. If this operation succeeds, return the
- <a for=/>set</a> of <a for=/>IP addresses</a>.
+ <li>
+  <p>Perform an <a>implementation-defined</a> operation to turn <var>origin</var> into a
+  <a for=/>set</a> of one or more <a for=/>IP addresses</a>.
+
+  <p>It is also <a>implementation-defined</a> whether other operations might be performed to get
+  connection information beyond just <a for=/>IP addresses</a>. For example, if <var>origin</var>'s
+  <a for=origin>scheme</a> is an <a>HTTP(S) scheme</a>, the implementation might perform a DNS query
+  for HTTPS RRs. [[SVCB]]
+
+  <p>If this operation succeeds, return the <a for=/>set</a> of <a for=/>IP addresses</a> and any
+  additional <a>implementation-defined</a> information.
+ </li>
 
  <li><p>Return failure.
 </ol>
 
-<p>The results of <a>resolve a domain</a> may be cached. If they are cached, <var>key</var> should
+<p>The results of <a>resolve an origin</a> may be cached. If they are cached, <var>key</var> should
 be used as part of the cache key.
 
 <div class=note>
  <p>Typically this operation would involve DNS and as such caching can happen on DNS servers without
  <var>key</var> being taken into account. Depending on the implementation it might also not be
  possible to take <var>key</var> into account locally. [[RFC1035]]
 
- <p>The order of the <a for=/>IP addresses</a> <a>resolve a domain</a> can return return can differ
- between invocations.
+ <p>The order of the <a for=/>IP addresses</a> that the <a>resolve an origin</a> algorithm can return
+ can differ between invocations.
 
  <p>The particulars (apart from the cache key) are not tied down as they are not pertinent to the
  system the Fetch Standard establishes. Other documents ought not to build on this primitive without
  having a considered discussion with the Fetch Standard community first.
 </div>
 
-<p>To <dfn>resolve an origin</dfn>, given a <a for=/>network partition key</a> <var>key</var> and an
-<a for=/>origin</a> <var>origin</var>:
-<!-- Should we assert the scheme here to be an HTTP(S) scheme or a WebRTC scheme? -->
-
-<ol>
- <li><p>If <var>origin</var>'s <a for=origin>host</a> is an <a for=/>IP address</a>, then return
- « <var>origin</var>'s <a for=origin>host</a> ».
-
- <li><p>Return the result of running <a>resolve a domain</a> given <var>key</var> and
- <var>origin</var>'s <a for=origin>host</a>.
-</ol>
-
-<p class=note>The same caveat applies. Do not build on this without having a considered discussion
-with the Fetch Standard community first.
-
 
 <h3 id=connections>Connections</h3>
 
@@ -2525,7 +2530,7 @@ steps:
     return it. Any other returned values that are <a>connections</a> may be closed.
 
     <p class=note>Essentially this allows an implementation to pick one or more
-    <a for=/>IP addresses</a> from the return value of <a>resolve a domain</a> (assuming
+    <a for=/>IP addresses</a> from the return value of <a>resolve an origin</a> (assuming
     <var>proxy</var> is "<code>DIRECT</code>") and race them against each other, favor
     <a for=/>IPv6 addresses</a>, retry in case of a timeout, etc.
 
@@ -4049,11 +4054,21 @@ steps:
    <li>Matching <var>request</var>'s <a for=request>current URL</a>'s <a for=url>host</a> per
    <a href=https://datatracker.ietf.org/doc/html/rfc6797#section-8.2>Known HSTS Host Domain Name Matching</a>
    results in either a superdomain match with an asserted <code>includeSubDomains</code> directive
-   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive).
-   [[!HSTS]]
+   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive) [[!HSTS]]; or
+   DNS resolution for the request finds a matching HTTPS RR per
+   <a href=https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-9.5>section 9.5</a>
+   of [[!SVCB]].
+   [[!HSTS]][[!SVCB]]
   </ul>
   <!-- Per Mike West HSTS happens "probably after" Referrer -->
 
+  <p class=note>As all DNS operations are generally <a>implementation-defined</a>, how it is
+  determined that DNS resolution contains an HTTPS RR is also <a>implementation-defined</a>. As DNS
+  operations are not traditionally performed until attempting to <a>obtain a connection</a>, user
+  agents might need to perform DNS operations earlier, consult local DNS caches, or wait until later
+  in the fetch algorithm and potentially unwind logic on discovering the need to change
+  <var>request</var>'s <a for=request>current URL</a>'s <a for=url>scheme</a>.
+
  <li><p>If <var>recursive</var> is false, then run the remaining steps <a>in parallel</a>.
 
  <li>
@@ -8240,6 +8255,7 @@ Eero Häkkinen,
 Ehsan Akhgari,
 Emily Stark,
 Eric Lawrence,
+Eric Orth,
 François Marier,
 Frank Ellerman,
 Frederick Hirsch,