1.1.Goals

The goal of the SVCB RR is to allow clients to resolve a singleadditional DNS RR in a way that:¶

• Provides alternative endpoints that are authoritative for the service,along with parameters associated with each of these endpoints.¶
• Does not assume that all alternative endpoints have the same parametersor capabilities, or are evenoperated by the same entity. This is important, as DNS does notprovide any way to tie together multiple RRsets for the same name.For example, if "www.example.com" is a CNAME alias that switchesbetween one of three Content Delivery Networks (CDNs) or hosting environments, successive queriesfor that name may return records that correspond to different environments.¶
• Enables CNAME-like functionality at a zone apex (such as"example.com") for participating protocols and generallyenables extending operational authority for a service identifiedby a domain name to other instances with alternate names.¶

Additional goals specific to HTTPS RRs and the HTTP use cases include:¶

• Connecting directly to HTTP/3 (QUIC transport)alternative endpoints[HTTP/3].¶
• Supporting non-default TCP and UDP ports.¶
• Enabling SRV-like benefits (e.g., apex aliasing, as mentioned above) for HTTP,where SRV[SRV] has not been widely adopted.¶
• Providing an indication signaling that the "https" scheme should be used instead of "http" for all HTTP requests to this host and port, similar to HTTP Strict Transport Security[HSTS] (seeSection 9.5).¶
• Enabling the conveyance of Encrypted ClientHello keys[ECH] associatedwith an alternative endpoint.¶

1.2.Overview of the SVCB RR

This subsection briefly describes the SVCB RR with forward references tothe full exposition of each component. (As discussed inSection 6, this allapplies equally to the HTTPS RR, which sharesthe same encoding, format, and high-level semantics.)¶

The SVCB RR has two modes: 1) AliasMode (Section 2.4.2), which aliases a nameto another name and 2) ServiceMode (Section 2.4.3), which provides connectioninformation bound to a service endpoint domain. Placing both forms in a singleRR type allows clients tofetch the relevant information with a single query (Section 2.3).¶

The SVCB RR has two required fields and one optional field. The fields are:¶

SvcPriority (Section 2.4.1):

The priority of this record (relative to others,with lower values preferred). A value of 0 indicates AliasMode.¶

TargetName:

The domain name of either the alias target (forAliasMode) or the alternative endpoint (for ServiceMode).¶

SvcParams (optional):

A list of key=value pairsdescribing the alternative endpoint atTargetName (only used in ServiceMode and otherwise ignored).SvcParams are described inSection 2.1.¶

Cooperating DNS recursive resolvers will perform subsequent recordresolution (for SVCB, A, and AAAA records) and return them in theAdditional section of the response (Section 4.2). Clients either use responsesincluded in the Additional section returned by the recursive resolveror perform necessary SVCB, A, and AAAA record resolutions (Section 3). DNSauthoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAMErecords in the Additional section to responses for a SVCB query (Section 4.1).¶

In ServiceMode, the SvcParams of the SVCB RRprovide an extensible data model for describing alternativeendpoints that are authoritative for a service, along withparameters associated with each of these alternative endpoints (Section 7).¶

For HTTP use cases, the HTTPS RR (Section 9) enables many of the benefits of Alt-Svc[AltSvc]without waiting for a full HTTP connection initiation (multiple round trips)before learning of the preferred alternative,and without necessarily revealing the user'sintended destination to all entities along the network path.¶

1.3.Terminology

Terminology in this document is based on the common case where the SVCB record is used toaccess a resource identified by a URI whoseauthority field contains a DNShostname as thehost.¶

• The "service" is the information source identified by theauthority andscheme of the URI, capable of providing access to the resource. For "https"URIs, the "service" corresponds to an "origin"[RFC6454].¶
• The "service name" is thehost portion of the authority.¶
• The "authority endpoint" is the authority's hostname and a port number impliedby the scheme or specified in the URI.¶
• An "alternative endpoint" is a hostname, port number, and other associatedinstructions to the client on how to reach an instance of a service.¶

Additional DNS terminology intends to be consistentwith[DNSTerm].¶

SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR,and future RR types that share SVCB's formats and registry arecollectively known as SVCB-compatible RR types. The contraction "SVCB" is alsoused to refer to this system as a whole.¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1.Zone-File Presentation Format

The presentation format<RDATA> of the record ([RFC1035],Section 5.1) hasthe form:¶

SvcPriority TargetName SvcParams

The SVCB record is defined specifically withinthe Internet ("IN") Class ([RFC1035],Section 3.2.4).¶

SvcPriority is a number in the range 0-65535,TargetName is a<domain-name> ([RFC1035],Section 5.1),and the SvcParams are a whitespace-separated list with each SvcParamconsisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey.SvcParamKeys are registered by IANA (Section 14.3).¶

Each SvcParamKeySHALL appear at most once in the SvcParams.In presentation format, SvcParamKeys are lowercase alphanumeric strings.Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9", and "-".In ABNF[RFC5234],¶

alpha-lc      = %x61-7A   ; a-zSvcParamKey   = 1*63(alpha-lc / DIGIT / "-")SvcParam      = SvcParamKey ["=" SvcParamValue]SvcParamValue = char-string ; See Appendix A.value         = *OCTET ; Value before key-specific parsing

The SvcParamValue is parsed using thecharacter-string decoding algorithm (Appendix A), producing avalue.Thevalue is then validated and converted into wire format in a mannerspecific to each key.¶

When the optional "=" and SvcParamValue are omitted, thevalue isinterpreted as empty.¶

Arbitrary keys can be represented using the unknown-key presentation format"keyNNNNN" where NNNNN is the numericvalue of the key type without leading zeros.A SvcParam in this formSHALL be parsed as specified above, andthe decodedvalueSHALL be used as its wire-format encoding.¶

For some SvcParamKeys, thevalue corresponds to a list or set ofitems. Presentation formats for such keysSHOULD use a comma-separated list(Appendix A.1).¶

SvcParams in presentation formatMAY appear in any order, but keysMUST NOT berepeated.¶

2.2.RDATA Wire Format

The RDATA for the SVCB RR consists of:¶

• a 2-octet field for SvcPriority as an integer in networkbyte order.¶
• the uncompressed, fully qualified TargetName, represented asa sequence of length-prefixed labels perSection 3.1 of [RFC1035].¶
• the SvcParams, consuming the remainder of the record(so smaller than 65535 octets and constrained by the RDATAand DNS message sizes).¶

When the list of SvcParams is non-empty, it contains a series ofSvcParamKey=SvcParamValue pairs, represented as:¶

• a 2-octet field containing the SvcParamKey as aninteger in network byte order. (SeeSection 14.3.2 for the defined values.)¶
• a 2-octet field containing the length of the SvcParamValueas an integer between 0 and 65535 in network byte order.¶
• an octet string of this length whose contents are the SvcParamValue in aformat determined by the SvcParamKey.¶

SvcParamKeysSHALL appear in increasing numeric order.¶

ClientsMUST consider an RR malformed if:¶

• the end of the RDATA occurs within a SvcParam.¶
• SvcParamKeys are not in strictly increasing numeric order.¶
• the SvcParamValue for a SvcParamKey does not have the expected format.¶

Note that the second condition implies that there are no duplicateSvcParamKeys.¶

If any RRs are malformed, the clientMUST reject the entire RRset andfall back to non-SVCB connection establishment.¶

2.3.SVCB Query Names

When querying the SVCB RR, a service is translated into a QNAME by prependingthe service name with a label indicating the scheme, prefixed with an underscore,resulting in a domain name like "_examplescheme.api.example.com.". Thisfollows the Attrleaf naming pattern[Attrleaf], so the schemeMUST beregistered appropriately with IANA (seeSection 11).¶

Protocol mapping documentsMAY specify additional underscore-prefixed labelsto be prepended. For schemes that specify a port (Section 3.2.3 of [URI]), one reasonable possibility is to prepend the indicated portnumber if a non-default port number is specified. This document terms this behavior"Port Prefix Naming" and uses it in the examples throughout.¶

SeeSection 9.1 for information regarding HTTPS RR behavior.¶

When a prior CNAME or SVCB record has aliased toa SVCB record, each RRSHALL be returned under its own owner name, as inordinary CNAME processing ([RFC1034],Section 3.6.2). For details, seethe recommendations regarding aliases for clients (Section 3),servers (Section 4), and zones (Section 10).¶

Note that none of these forms alter the origin or authority for validationpurposes.For example, TLS clientsMUST continue to validate TLS certificatesfor the original service name.¶

As an example, the owner of "example.com" could publish this record:¶

_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.

This record would indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net".The owner of "example.net", in turn, could publish this record:¶

svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (    alpn="bar" port="8004" )

This record would indicate that these services are served on port number 8004,which supports the protocol "bar" and its associated transport inaddition to the default transport protocol for "foo://".¶

(Parentheses are used to ignore a line break in DNS zone-file presentationformat, perSection 5.1 of [RFC1035].)¶

2.4.Interpretation

_8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.

example.com. 3600 IN HTTPS 0 svc.example.net.

2.5.Special Handling of "." in TargetName

If TargetName has the value "." (represented in the wire format as azero-length label), special rules apply.¶

example.com.      7200  IN HTTPS 0 svc.example.net.svc.example.net.  7200  IN CNAME svc2.example.net.svc2.example.net. 7200  IN HTTPS 1 . port=8002svc2.example.net. 300   IN A     192.0.2.2svc2.example.net. 300   IN AAAA  2001:db8::2

3.1.Handling Resolution Failures

If DNS responses are cryptographically protected (e.g., using DNSSEC orTLS[DoT][DoH]) and SVCB resolution failsdue to an authentication error, SERVFAIL response, transport error, ortimeout, the clientSHOULD abandon its attempt to reach the service, evenif the client is SVCB-optional. Otherwise, an active attackercould mount a downgrade attack by denying the user access to the SvcParams.¶

A SERVFAIL error can occur if the domain is DNSSEC-signed, the recursiveresolver is DNSSEC-validating, and the attacker is between the recursiveresolver and the authoritative DNS server. A transport error or timeout canoccur if an active attacker between the client and the recursive resolver isselectively dropping SVCB queries or responses, based on their size orother observable patterns.¶

If the client enforces DNSSEC validation on A/AAAA responses, itSHOULDapply the same validation policy to SVCB. Otherwise, an attacker coulddefeat the A/AAAA protection by forging SVCB responses that direct theclient to other IP addresses.¶

If DNS responses are not cryptographically protected, clientsMAY treatSVCB resolution failure as fatal or nonfatal.¶

If the client is unable to complete SVCB resolution due to its chain lengthlimit, the clientMUST fall back to the authority endpoint, as if theservice's SVCB record did not exist.¶

3.2.Clients Using a Proxy

Clients using a domain-oriented transport proxy like HTTP CONNECT([RFC7231],Section 4.3.6) or SOCKS5[RFC1928] have the option ofusing named destinations, in which case the client does not performany A or AAAA queries for destination domains. If the client is configuredto use nameddestinations with a proxy that does not provide SVCB query capability(e.g., through an affiliated DNS resolver), the client would have to performSVCB resolution separately, likely disclosing the destinations to additional parties and not just the proxy.Clients in this configurationSHOULD arrange for a separate SVCB resolutionprocedure with appropriate privacy properties. If this is not possible,SVCB-optional clientsMUST disable SVCB resolution entirely, and SVCB-reliantclientsMUST treat the configuration as invalid.¶

If the client does use SVCB and named destinations, the clientSHOULD followthe standard SVCB resolution process, selecting the smallest-SvcPriorityoption that is compatible with the client and the proxy. When connectingusing a SVCB record, clientsMUST provide the final TargetName and port to theproxy, which will perform any required A and AAAA lookups.¶

This arrangement has several benefits:¶

• Compared to disabling SVCB:¶

  • It allows the client to use the SvcParams, if present, which areonly usable with a specific TargetName. The SvcParams mayinclude information that enhances performance (e.g., supported protocols) and privacy.¶
  • It allows a service on an apex domain to use aliasing.¶

• Compared to providing the proxy with an IP address:¶

  • It allows the proxy to select between IPv4 and IPv6 addresses for theserver according to its configuration.¶
  • It ensures that the proxy receives addresses based on its networkgeolocation, not the client's.¶
  • It enables faster fallback for TCP destinations with multiple addressesof the same family.¶

4.1.Authoritative Servers

When replying to a SVCB query, authoritative DNS serversSHOULD returnA, AAAA, and SVCB records in the Additional section for any TargetNamesthat are in the zone. If the zone is signed, the serverSHOULD alsoinclude DNSSEC records authenticating the existence or nonexistence of these recordsin the Additional section.¶

SeeSection 4.4 for exceptions.¶

4.2.Recursive Resolvers

Whether the recursive resolver is aware of SVCB or not, the normal responseconstruction process used for unknown RR types[RFC3597]generates the Answer section of the response.Recursive resolvers that are aware of SVCBSHOULD help the client toexecute the procedure inSection 3 with minimum overalllatency by incorporating additional useful information into theAdditional section of the response as follows:¶

1. Incorporate the results of SVCB resolution. If the recursive resolver'slocal chain length limit (which may be different from the client's limit) hasbeen reached, terminate.¶

2. If any of the resolved SVCB records are in AliasMode, choose one of themat random, and resolve SVCB, A, and AAAA records for itsTargetName.¶

   • If any SVCB records are resolved, go to Step 1.¶
   • Otherwise, incorporate the results of A and AAAA resolution, andterminate.¶
3. All the resolved SVCB records are in ServiceMode. Resolve A and AAAAqueries for each TargetName (or for the owner name if TargetNameis "."), incorporate all the results, and terminate.¶

In this procedure, "resolve" means the resolver's ordinary recursiveresolution procedure, as if processing a query for that RRset.This includes following any aliases that the resolver would ordinarilyfollow (e.g., CNAME, DNAME[DNAME]). Errors or anomalies inobtaining additional recordsMAY cause this process to terminate butMUST NOT themselves cause the resolver to send a failure response.¶

SeeSection 2.4.2 for additional safeguards for recursive resolversto implement to mitigate loops.¶

SeeSection 5.2 for possible optimizations of this procedure.¶

4.3.General Requirements

Recursive resolversMUST be able to convey SVCB records with unrecognizedSvcParamKeys. ResolversMAY accomplish this by treatingthe entire SvcParams portion of the record as opaque, even if the contentsare invalid. If a recognized SvcParamKey is followed by a value that isinvalid according to the SvcParam's specification, a recursive resolverMAY report an error such as SERVFAIL instead of returningthe record.For complex value types whose interpretation might differbetween implementations or have additional futureallowed values added (e.g., URIs or "alpn"), resolversSHOULD limit validation to specified constraints.¶

When responding to a query that includes the DNSSEC OK bit[RFC3225],DNSSEC-capable recursive and authoritative DNS serversMUST accompanyeach RRset in the Additional section with the same DNSSEC-related recordsthat they would send when providing that RRset as an Answer (e.g., RRSIG, NSEC,NSEC3).¶

According toSection 5.4.1 of [RFC2181], "Unauthenticated RRs receivedand cached from ... the additional data section ... should not be cached insuch a way that they would ever be returned as answers to a received query.They may be returned as additional information where appropriate."Recursive resolvers thereforeMAY cache records from the Additional sectionfor use in populating Additional section responses andMAY cache themfor general use if they are authenticated by DNSSEC.¶

4.4.EDNS Client Subnet (ECS)

The EDNS Client Subnet (ECS) option[RFC7871] allows recursiveresolvers to request IP addresses that are suitable for a particular clientIP range. SVCB records may contain IP addresses (in ipv*hint SvcParams)or direct users to a subnet-specific TargetName, so recursive resolversSHOULD include the same ECS option in SVCB queries as in A/AAAA queries.¶

According toSection 7.3.1 of [RFC7871], "Any records from [theAdditional section]MUST NOT be tied to a network." Accordingly,when processing a response whose QTYPE is SVCB-compatible,resolversSHOULD treat any records in the Additional section as havingSOURCE PREFIX-LENGTH set to zero and SCOPE PREFIX-LENGTH as specifiedin the ECS option. Authoritative serversMUST omit such records if they arenot suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH tozero. This will cause the resolver to perform a follow-up query that canreceive a properly tailored ECS. (This is similar to the usage of CNAME withthe ECS option as discussed in[RFC7871],Section 7.2.1.)¶

Authoritative servers that omit Additional records can avoid the addedlatency of a follow-up query by following the advice inSection 10.2.¶

5.1.Optimistic Pre-connection and Connection Reuse

If an address response arrives before the corresponding SVCB response, theclientMAY initiate a connection as if the SVCB query returned NODATA butMUST NOT transmit any information that could be altered by the SVCB responseuntil it arrives. For example, future SvcParamKeys could be defined thatalter the TLS ClientHello.¶

Clientsimplementing this optimizationSHOULD wait for 50 milliseconds beforestarting optimistic pre-connection, as per the guidance in[HappyEyeballsV2].¶

A SVCB record is consistent with a connectionif the client would attempt an equivalent connection when making use ofthat record. If a SVCB record is consistent with an active or in-progressconnection C, the clientMAY prefer that record and use C as its connection.For example, suppose the client receives this SVCB RRset for a protocolthat uses TLS over TCP:¶

_1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (    ipv6hint=2001:db8::1 port=1234 )                               SVCB 2 svc2.example.net. (    ipv6hint=2001:db8::2 port=1234 )

If the client has an in-progress TCP connection to[2001:db8::2]:1234,itMAY proceed with TLS on that connection, eventhough the other record in the RRset has higher priority.¶

If none of the SVCB records are consistentwith any active or in-progress connection,clients proceed with connection establishment as described inSection 3.¶

5.2.Generating and Using Incomplete Responses

When following the procedure inSection 4.2, recursiveresolversMAY terminate the procedure early and produce a reply that omitssome of the associated RRsets. This isREQUIRED when the chain length limitis reached (Step 1 inSection 4.2) but might also be appropriatewhen the maximum response size is reached or when responding before fullychasing dependencies would improve performance. When omitting certainRRsets, recursive resolversSHOULD prioritize information forsmaller-SvcPriority records.¶

As discussed inSection 3, clientsMUST be able to fetch additionalinformation that is required to use a SVCB record, if it is not includedin the initial response. As a performance optimization, if some of the SVCBrecords in the response can be used without requiring additional DNS queries,the clientMAY prefer those records, regardless of their priorities.¶

7.1."alpn" and "no-default-alpn"

The "alpn" and "no-default-alpn" SvcParamKeys togetherindicate the set of Application-Layer Protocol Negotiation (ALPN)protocol identifiers[ALPN]and associated transport protocols supported by this service endpoint (the"SVCB ALPN set").¶

As with Alt-Svc[AltSvc], each ALPN protocol identifier is used toidentify the application protocol and associated suiteof protocols supported by the endpoint (the "protocol suite").The presence of an ALPN protocol identifier in the SVCB ALPN set indicates that thisservice endpoint, described by TargetName and the other parameters (e.g.,"port"), offers service with the protocol suite associated with this ALPN identifier.¶

Clients filter the set of ALPN identifiers to match the protocol suites theysupport, and this informs the underlying transport protocol used (suchas QUIC over UDP or TLS over TCP). ALPN protocol identifiers that do not uniquelyidentify a protocol suite (e.g., an Identification Sequence thatcan be used with both TLS and DTLS) are not compatible with thisSvcParamKey andMUST NOT be included in the SVCB ALPN set.¶

alpn-id = 1*255OCTET

7.2."port"

The "port" SvcParamKey defines the TCP or UDP portthat should be used to reach this alternative endpoint.If this key is not present, clientsSHALL use the authority endpoint's portnumber.¶

The presentationvalue of the SvcParamValue is a single decimal integerbetween 0 and 65535 in ASCII. Any othervalue (e.g., an empty value)is a syntax error. To enable simpler parsing, this SvcParamValueMUST NOT containescape sequences.¶

The wire format of the SvcParamValueis the corresponding 2-octet numeric value in network byte order.¶

If a port-restricting firewall is in place between some client and the serviceendpoint, changing the port number might cause that client to lose access tothe service, so operators should exercise caution when using this SvcParamKeyto specify a non-default port.¶

7.3."ipv4hint" and "ipv6hint"

The "ipv4hint" and "ipv6hint" keys convey IP addresses that clientsMAY use toreach the service. If A and AAAA records for TargetName are locallyavailable, the clientSHOULD ignore these hints. Otherwise, clientsSHOULD perform A and/or AAAA queries for TargetName perSection 3, and clientsSHOULD use the IP address in thoseresponses for future connections. ClientsMAY opt to terminate anyconnections using the addresses in hints and instead switch to theaddresses in response to the TargetName query. Failure to use A and/orAAAA response addresses could negatively impact load balancing or othergeo-aware features and thereby degrade client performance.¶

The presentationvalueSHALL be a comma-separated list (Appendix A.1)of one or more IP addresses of the appropriatefamily in standard textual format[RFC5952][RFC4001]. To enable simpler parsing,this SvcParamValueMUST NOT contain escape sequences.¶

The wire format for each parameter is a sequence of IP addresses in networkbyte order (for the respective address family).Like an A or AAAA RRset, the list of addresses represents anunordered collection, and clientsSHOULD pick addresses to use in a random order.An empty list of addresses is invalid.¶

When selecting between IPv4 and IPv6 addresses to use, clients may use anapproach such as Happy Eyeballs[HappyEyeballsV2].When only "ipv4hint" is present, NAT64 clients may synthesizeIPv6 addresses as specified in[RFC7050] or ignore the "ipv4hint" key andwait for AAAA resolution (Section 3).For best performance, server operatorsSHOULD include an "ipv6hint" parameterwhenever they include an "ipv4hint" parameter.¶

These parameters are intended to minimize additional connection latencywhen a recursive resolver is not compliant with the requirements inSection 4 andSHOULD NOT be included if most clients are usingcompliant recursive resolvers. When TargetName is the service nameor the owner name (which can be written as "."), server operatorsSHOULD NOT include these hints, because they are unlikely to convey anyperformance benefit.¶

7.4."mandatory"

SeeSection 8.¶

9.1.Query Names for HTTPS RRs

The HTTPS RR uses Port Prefix Naming (Section 2.3),with one modification: if the scheme is "https" and the port is 443,then the client's original QNAME isequal to the service name (i.e., the origin's hostname),without any prefix labels.¶

By removing the Attrleaf labels[Attrleaf]used in SVCB, this construction enables offline DNSSEC signing ofwildcard domains, which are commonly used with HTTP. Using theservice name as the owner name of the HTTPS record, without prefixes,also allows the targets of existing CNAME chains(e.g., CDN hosts) to start returning HTTPS RR responses withoutrequiring origin domains to configure and maintain an additionaldelegation.¶

The procedure for following HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB (as described in Sections 2.4.2 and3).¶

Clients always convert "http" URLs to "https" before performing anHTTPS RR query using the process described inSection 9.5, so domain ownersMUST NOT publish HTTPS RRs with a prefix of "_http".¶

Note that none of these forms alter the HTTPS origin or authority.For example, clientsMUST continue to validate TLS certificatehostnames based on the origin.¶

9.2.Comparison with Alt-Svc

Publishing a ServiceMode HTTPS RR in DNS is intendedto be similar to transmitting an Alt-Svc field value overHTTP, and receiving an HTTPS RR is intended to be similar toreceiving that field value over HTTP. However, there are somedifferences in the intended client and server behavior.¶

9.3.Interaction with Alt-Svc

Clients that implement support for both Alt-Svc and HTTPS records andare making a connection based on a cached Alt-Svc responseSHOULDretrieve any HTTPS records for the Alt-Svc alt-authority and ensure thattheir connection attempts are consistent with both the Alt-Svc parametersand any received HTTPS SvcParams. If present, the HTTPS record's TargetNameand port are used for connection establishment (perSection 3).For example, suppose that"https://example.com" sends an Alt-Svc field value of:¶

Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443"

The client would retrieve the following HTTPS records:¶

alt.example.              IN HTTPS 1 . alpn=h2,h3 foo=...alt2.example.             IN HTTPS 1 alt2b.example. alpn=h3 foo=..._8443._https.example.com. IN HTTPS 1 alt3.example. (    port=9443 alpn=h2,h3 foo=... )

Based on these inputs, the following connection attempts would always beallowed:¶

• HTTP/2 toalt.example:443¶
• HTTP/3 toalt3.example:9443¶
• Fallback to the client's non-Alt-Svc connection behavior¶

The following connection attempts would not be allowed:¶

• HTTP/3 toalt.example:443 (not consistent with Alt-Svc)¶
• Any connection toalt2b.example (no ALPN ID consistent with both the HTTPSrecord and Alt-Svc)¶
• HTTPS over TCP to any port onalt3.example (not consistent with Alt-Svc)¶

Suppose that "foo" is a SvcParamKey that renders the client SVCB-reliant.The following Alt-Svc-only connection attempts would be allowed only ifthe client does not support "foo", as they rely on SVCB-optional fallbackbehavior:¶

• HTTP/2 toalt2.example:443¶
• HTTP/3 toexample.com:8443¶

Alt-authoritiesSHOULD carry the same SvcParams as the origin unlessa deviation is specifically known to be safe.As noted inSection 2.4 of [AltSvc], clientsMAY disallow any Alt-Svcconnection according to their own criteria, e.g., disallowing Alt-Svcconnections that lack support for privacy features that are available onthe authority endpoint.¶

9.4.Requiring Server Name Indication

ClientsMUST NOT use an HTTPS RR response unless theclient supports the TLS Server Name Indication (SNI) extension andindicates the origin name in the TLS ClientHello (which might beencrypted via a future specification such as[ECH]).This supports the conservation of IP addresses.¶

Note that the TLS SNI (and also the HTTP "Host" or ":authority") will indicatethe origin, not the TargetName.¶

9.5.HTTP Strict Transport Security (HSTS)

An HTTPS RR directs the client to communicate with this host only over asecure transport, similar to HSTS[HSTS].Prior to making an "http" scheme request, the clientSHOULD perform a lookupto determine if any HTTPS RRs exist for that origin. To do so,the clientSHOULD construct a corresponding "https" URL as follows:¶

1. Replace the "http" scheme with "https".¶
2. If the "http" URL explicitly specifies port 80, specify port 443.¶
3. Do not alter any other aspect of the URL.¶

This construction is equivalent toSection 8.3 of [HSTS], Step 5.¶

If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS RRsor any compatible ServiceMode HTTPS RRs (seeSection 8), the clientSHOULD behave as if it has received an HTTP 307 (Temporary Redirect) status codewith this "https" URL in the "Location" field. (Receipt of an incompatible ServiceMode RR does nottrigger the redirect behavior.)Because HTTPS RRs are received over an often-insecure channel (DNS),clientsMUST NOT place any more trust in this signal than if theyhad received a 307 (Temporary Redirect) response over cleartext HTTP.¶

Publishing an HTTPS RR can potentially lead to unexpected resultsor a loss in functionality in cases where the "http" resource neitherredirects to the "https" resource nor references the same underlying resource.¶

When an "https" connection fails due to an error in the underlying securetransport, such as an error in certificate validation, some clientscurrently offer a "user recourse" that allows the user to bypass thesecurity error and connect anyway.When making an "https" scheme request to an origin with an HTTPS RR,either directly or via the above redirect, such a clientMAY remove the userrecourse option. Origins that publish HTTPS RRs thereforeMUST NOT relyon user recourse for access. For more information, see Sections8.4 and12.1 of[HSTS].¶

9.6.Use of HTTPS RRs in Other Protocols

All HTTP connections to named origins are eligible to use HTTPS RRs, evenwhen HTTP is used as part of another protocol or without an explicit HTTP-related URIscheme (Section 4.2 of [HTTP]). For example, clients thatsupport HTTPS RRs and implement[WebSocket] using the alteredopening handshake from[FETCH-WEBSOCKETS]SHOULD use HTTPS RRsfor therequestURL.¶

When HTTP is used in a context where URLs or redirects are not applicable(e.g., connections to an HTTP proxy), clients that find a corresponding HTTPS RRSHOULD implement security upgrade behavior equivalent to thatspecified inSection 9.5.¶

Such protocolsMAY define their own SVCB mappings, whichMAYbe defined to take precedence over HTTPS RRs.¶

10.1.Structuring Zones for Flexibility

Each ServiceMode RRset can only serve a single scheme. The scheme is indicatedby the owner name and the RR type. For the generic SVCB RR type, this means thateach owner name can only be used for a single scheme. The underscore prefixingrequirement (Section 2.3) ensures that this is true for the initial query,but it is the responsibility of zone owners to choose names that satisfy thisconstraint when using aliases, including CNAME and AliasMode records.¶

When using the generic SVCB RR type with aliasing, zone ownersSHOULD choose aliastarget names that indicate the scheme in use (e.g., "foosvc.example.net" for"foo" schemes). This will help to avoid confusion when another scheme needs tobe added to the configuration. When multiple port numbers are in use, it may behelpful to repeat the prefix labels in the alias target name (e.g.,"_1234._foo.svc.example.net").¶

10.2.Structuring Zones for Performance

To avoid a delay for clients using a non-conforming recursive resolver,domain ownersSHOULD minimize the use of AliasMode records andSHOULDchoose TargetName according to a predictable convention that is knownto the client, so that clients can issue A and/or AAAA queries for TargetNamein advance (seeSection 5). Unless otherwise specified, theconvention is to set TargetName to the service name for an initialServiceMode record, or to "." if it is reached via an alias.¶

$ORIGIN example.com. ; Originfoo                  3600 IN CNAME foosvc.example.net._8080._foo.foo       3600 IN CNAME foosvc.example.net.bar                   300 IN AAAA 2001:db8::2_9090._bar.bar       3600 IN SVCB 1 bar key65444=...$ORIGIN example.net. ; Service provider zonefoosvc               3600 IN SVCB 1 . key65333=...foosvc                300 IN AAAA 2001:db8::1

Domain ownersSHOULD avoid using a TargetName that is below a DNAME, asthis is likely unnecessary and makes responses slower and larger.Also, zone structures that require following more than eight aliases(counting both AliasMode and CNAME records) areNOT RECOMMENDED.¶

10.3.Operational Considerations

Some authoritative DNS servers may not allow A or AAAA records on namesstarting with an underscore (e.g.,[BIND-CHECK-NAMES]).This could create an operational issue when the TargetName contains an Attrleaf label,or when using a TargetName of "." if the owner name contains an Attrleaf label.¶

10.4.Examples

$ORIGIN simple.example. ; Simple example zone@ 300 IN A    192.0.2.1         AAAA 2001:db8::1

@ 7200 IN HTTPS 1 . alpn=h3

_8443._https 7200 IN HTTPS 1 . alpn=h3

$ORIGIN aliased.example. ; A zone that is using a hosting service; Subdomain aliased to a high-performance server poolwww             7200 IN CNAME pool.svc.example.; Apex domain on fixed IPs because CNAME is not allowed at the apex@                300 IN A     192.0.2.1                     IN AAAA  2001:db8::1

@               7200 IN HTTPS 0 pool.svc.example.

$ORIGIN svc.example. ; A hosting providerpool  7200 IN HTTPS 1 . alpn=h2,h3              HTTPS 2 backup alpn=h2 port=8443pool   300 IN A        192.0.2.2              AAAA     2001:db8::2backup 300 IN A        192.0.2.3              AAAA     2001:db8::3

 ; This zone contains/returns different CNAME records ; at different points in time.  The RRset for "www" can ; only ever contain a single CNAME. ; Sometimes the zone has: $ORIGIN customer.example.  ; A multi-CDN customer domain www 900 IN CNAME cdn1.svc1.example. ; and other times it contains: $ORIGIN customer.example. www 900 IN CNAME customer.svc2.example. ; and yet other times it contains: $ORIGIN customer.example. www 900 IN CNAME cdn3.svc3.example. ; With the following remaining constant and always included: $ORIGIN customer.example.  ; A multi-CDN customer domain ; The apex is also aliased to www to match its configuration. @     7200 IN HTTPS 0 www ; Non-HTTPS-aware clients use non-CDN IPs.               A    203.0.113.82               AAAA 2001:db8:203::2 ; Resolutions following the cdn1.svc1.example ; path use these records. ; This CDN uses a different alternative service for HTTP/3. $ORIGIN svc1.example.  ; domain for CDN 1 cdn1     1800 IN HTTPS 1 h3pool alpn=h3                  HTTPS 2 . alpn=h2                  A    192.0.2.2                  AAAA 2001:db8:192::4 h3pool 300 IN A 192.0.2.3            AAAA 2001:db8:192:7::3 ; Resolutions following the customer.svc2.example ; path use these records. ; Note that this CDN only supports HTTP/2. $ORIGIN svc2.example. ; domain operated by CDN 2 customer 300 IN HTTPS 1 . alpn=h2           60 IN A    198.51.100.2                 A    198.51.100.3                 A    198.51.100.4                 AAAA 2001:db8:198::7                 AAAA 2001:db8:198::12 ; Resolutions following the cdn3.svc3.example ; path use these records. ; Note that this CDN has no HTTPS records. $ORIGIN svc3.example. ; domain operated by CDN 3 cdn3      60 IN A    203.0.113.8                 AAAA 2001:db8:113::8

_8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.

14.1.SVCB RR Type

IANA has registered the following new DNS RR type in the "Resource Record (RR) TYPEs"registry on the "Domain Name System (DNS) Parameters" page:¶

Type:

SVCB¶

Value:

64¶

Meaning:

General-purpose service binding¶

Reference:

RFC 9460¶

14.2.HTTPS RR Type

IANA has registered the following new DNS RR type in the "Resource Record (RR) TYPEs" registry on the "Domain Name System (DNS) Parameters" page:¶

Type:

HTTPS¶

Value:

65¶

Meaning:

SVCB-compatible type for use with HTTP¶

Reference:

RFC 9460¶

14.3.New Registry for Service Parameters

IANA has created the "Service Parameter Keys (SvcParamKeys)"registry in the "Domain Name System (DNS) Parameters" categoryon a new page entitled "DNS Service Bindings (SVCB)". This registrydefines the namespacefor parameters, including string representations and numericSvcParamKey values. This registry is shared with other SVCB-compatibleRR types, such as the HTTPS RR.¶

14.4.Other Registry Updates

Per[Attrleaf], the following entry has been added to the DNS "Underscored and Globally Scoped DNS Node Names" registry:¶

A.1.Decoding a Comma-Separated List

In order to represent lists of items in zone files, this specification usescomma-separated lists. When the allowed items in the list cannot contain ","or "\", this is trivial. (For simplicity, empty items are not allowed.)A value-list parser that splits on "," and prohibits items containing "\"is sufficient to comply with all requirements in this document. Thiscorresponds to thesimple-comma-separated syntax:¶

; item-allowed is OCTET minus "," and "\".item-allowed           = %x00-2B / %x2D-5B / %x5D-FFsimple-item            = 1*item-allowedsimple-comma-separated = [simple-item *("," simple-item)]

For implementations that allow "," and "\" in item values, the followingescaping syntax applies:¶

item            = 1*OCTETescaped-item    = 1*(item-allowed / "\," / "\\")comma-separated = [escaped-item *("," escaped-item)]

Decoding of value-lists happens after character-string decoding.For example, consider thesechar-string SvcParamValues:¶

"part1,part2,part3\\,part4\\\\"part1\,\p\a\r\t2\044part3\092,part4\092\\

These inputs are equivalent: character-string decoding either of them wouldproduce the samevalue:¶

part1,part2,part3\,part4\\

Applying comma-separated list decoding to thisvalue would produce a listof threeitems:¶

part1part2part3,part4\

C.1.Differences from the SRV RR Type

An SRV record[SRV] can perform a function similarto that of the SVCB record,informing a client to look in a different location for a service.However, there are several differences:¶

• SRV records are typically mandatory, whereas SVCB is intended to be optionalwhen used with pre-existing protocols.¶
• SRV records cannot instruct the client to switch or upgradeprotocols, whereas SVCB can signal such an upgrade (e.g., toHTTP/2).¶
• SRV records are not extensible, whereas SVCB and HTTPS RRscan be extended with new parameters.¶
• SRV records specify a "weight" for unbalanced randomized load balancing.SVCB only supports balanced randomized load balancing, although weightscould be added via a future SvcParam.¶

C.2.Differences from the Proposed HTTP Record

Unlike[HTTP-DNS-RR], this approach isextensible to cover Alt-Svc and Encrypted ClientHello use cases. Like thatproposal, this addresses the zone-apex CNAME challenge.¶

Like that proposal, it remains necessary to continue to includeaddress records at the zone apex for legacy clients.¶

C.3.Differences from the Proposed ANAME Record

Unlike[ANAME-DNS-RR], this approach is extensible tocover Alt-Svc and Encrypted ClientHello use cases. This approach also does notrequire any changes or special handling on either authoritative orprimary servers, beyond optionally returning in-bailiwick additional records.¶

Like that proposal, this addresses the zone-apex CNAME challengefor clients that implement this.¶

However, with this SVCB proposal, it remains necessary to continueto include address records at the zone apex for legacy clients.If deployment of this standard is successful, the number of legacy clientswill fall over time. As the number of legacy clients declines, the operationaleffort required to serve these users without the benefit of SVCB indirectionshould fall. Server operators can easily observe how much traffic reaches thislegacy endpoint and may remove the apex's address records if the observed legacytraffic has fallen to negligible levels.¶

C.4.Comparison with Separate RR Types for AliasMode and ServiceMode

Abstractly, functions of AliasMode and ServiceMode are independent,so it might be tempting to specify them as separate RR types. However,this would result in serious performance impairment, because clientscannot rely on their recursive resolver to follow SVCB aliases (unlikeCNAME). Thus, clients would have to issue queries for both RR typesin parallel, potentially at each step of the alias chain. Recursiveresolvers that implement the specification would, upon receipt of aServiceMode query, emit both a ServiceMode query and an AliasMode query tothe authoritative DNS server. Thus, splitting the RR type would double, or insome cases triple, the load on clients and servers, and would notreduce implementation complexity.¶

D.1.AliasMode

example.com.   HTTPS   0 foo.example.com.\# 19 (00 00                                              ; priority03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target)\x00\x00                                           # priority\x03foo\x07example\x03com\x00                      # target

D.2.ServiceMode

example.com.   SVCB   1 .\# 3 (00 01      ; priority00         ; target (root label))\x00\x01   # priority\x00       # target (root label)

example.com.   SVCB   16 foo.example.com. port=53\# 25 (00 10                                              ; priority03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target00 03                                              ; key 300 02                                              ; length 200 35                                              ; value)\x00\x10                                           # priority\x03foo\x07example\x03com\x00                      # target\x00\x03                                           # key 3\x00\x02                                           # length 2\x00\x35                                           # value

example.com.   SVCB   1 foo.example.com. key667=hello\# 28 (00 01                                              ; priority03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target02 9b                                              ; key 66700 05                                              ; length 568 65 6c 6c 6f                                     ; value)\x00\x01                                           # priority\x03foo\x07example\x03com\x00                      # target\x02\x9b                                           # key 667\x00\x05                                           # length 5hello                                              # value

example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"\# 32 (00 01                                              ; priority03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target02 9b                                              ; key 66700 09                                              ; length 968 65 6c 6c 6f d2 71 6f 6f                         ; value)\x00\x01                                           # priority\x03foo\x07example\x03com\x00                      # target\x02\x9b                                           # key 667\x00\x09                                           # length 9hello\xd2qoo                                       # value

example.com.   SVCB   1 foo.example.com. (                      ipv6hint="2001:db8::1,2001:db8::53:1"                      )\# 55 (00 01                                              ; priority03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target00 06                                              ; key 600 20                                              ; length 3220 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01    ; first address20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01    ; second address)\x00\x01                                           # priority\x03foo\x07example\x03com\x00                      # target\x00\x06                                           # key 6\x00\x20                                           # length 32\x20\x01\x0d\xb8\x00\x00\x00\x00     \x00\x00\x00\x00\x00\x00\x00\x01              # first address\x20\x01\x0d\xb8\x00\x00\x00\x00     \x00\x00\x00\x00\x00\x53\x00\x01              # second address

example.com.   SVCB   1 example.com. (                        ipv6hint="2001:db8:122:344::192.0.2.33"                        )\# 35 (00 01                                              ; priority07 65 78 61 6d 70 6c 65 03 63 6f 6d 00             ; target00 06                                              ; key 600 10                                              ; length 1620 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21    ; address)\x00\x01                                           # priority\x07example\x03com\x00                             # target\x00\x06                                           # key 6\x00\x10                                           # length 16\x20\x01\x0d\xb8\x01\x22\x03\x44     \x00\x00\x00\x00\xc0\x00\x02\x21              # address

example.com.   SVCB   16 foo.example.org. (                      alpn=h2,h3-19 mandatory=ipv4hint,alpn                      ipv4hint=192.0.2.1                      )\# 48 (00 10                                              ; priority03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target00 00                                              ; key 000 04                                              ; param length 400 01                                              ; value: key 100 04                                              ; value: key 400 01                                              ; key 100 09                                              ; param length 902                                                 ; alpn length 268 32                                              ; alpn value05                                                 ; alpn length 568 33 2d 31 39                                     ; alpn value00 04                                              ; key 400 04                                              ; param length 4c0 00 02 01                                        ; param value)\x00\x10                                           # priority\x03foo\x07example\x03org\x00                      # target\x00\x00                                           # key 0\x00\x04                                           # param length 4\x00\x01                                           # value: key 1\x00\x04                                           # value: key 4\x00\x01                                           # key 1\x00\x09                                           # param length 9\x02                                               # alpn length 2h2                                                 # alpn value\x05                                               # alpn length 5h3-19                                              # alpn value\x00\x04                                           # key 4\x00\x04                                           # param length 4\xc0\x00\x02\x01                                   # param value

example.com.   SVCB   16 foo.example.org. alpn="f\\\\oo\\,bar,h2"example.com.   SVCB   16 foo.example.org. alpn=f\\\092oo\092,bar,h2\# 35 (00 10                                              ; priority03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target00 01                                              ; key 100 0c                                              ; param length 1208                                                 ; alpn length 866 5c 6f 6f 2c 62 61 72                            ; alpn value02                                                 ; alpn length 268 32                                              ; alpn value)\x00\x10                                           # priority\x03foo\x07example\x03org\x00                      # target\x00\x01                                           # key 1\x00\x0c                                           # param length 12\x08                                               # alpn length 8f\oo,bar                                           # alpn value\x02                                               # alpn length 2h2                                                 # alpn value

D.3.Failure Cases

This subsection contains test vectors that are notcompliant with this document. The various reasons for non-complianceare explained with each example.¶

example.com.   SVCB   1 foo.example.com. (                       key123=abc key123=def                       )

example.com.   SVCB   1 foo.example.com. mandatoryexample.com.   SVCB   1 foo.example.com. alpnexample.com.   SVCB   1 foo.example.com. portexample.com.   SVCB   1 foo.example.com. ipv4hintexample.com.   SVCB   1 foo.example.com. ipv6hint

example.com.   SVCB   1 foo.example.com. no-default-alpn=abc

example.com.   SVCB   1 foo.example.com. mandatory=key123

example.com.   SVCB   1 foo.example.com. mandatory=mandatory

example.com.   SVCB   1 foo.example.com. (                      mandatory=key123,key123 key123=abc                      )