Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
Extracted elements (31)
AliasMode and ServiceMode are combined in a single RR type so that clients can fetch all relevant service-binding information in a single DNS query. Separate RR types would require querying multiple types to determine which mode applies, adding latency.
The HTTPS RR (type 65) omits the Attrleaf underscore-label prefix required by SVCB for the https/port-443 case, enabling compatibility with wildcard domains and existing CNAME chains widely used with HTTP. This allows CDN target hosts to return HTTPS RRs without requiring origin domains to configure extra delegation records.
Clients supporting both Alt-Svc and HTTPS RRs SHOULD retrieve HTTPS records for each Alt-Svc alt-authority and ensure connection attempts are consistent with both sets of parameters. The HTTPS record's TargetName and port govern connection establishment per Section 3.
DNS64 resolvers SHOULD synthesize AAAA records for TargetName when populating the Additional section, but MUST NOT apply DNS64 synthesis to the IP hints in 'ipv4hint'/'ipv6hint' SvcParams, as doing so would break DNSSEC validation for the SVCB record.
Publishing a ServiceMode HTTPS RR resembles transmitting an Alt-Svc field value, but with key differences: HTTPS RRs are not authenticated (DNSSEC optional), there is no 'persist' SvcParamKey (unsafe on untrusted channel), there is no 'ma' parameter (TTL serves that purpose), and all clients in the same DNS scope receive the same SvcParams.
Before making an 'http' scheme request, clients SHOULD look up HTTPS RRs for the origin. If any AliasMode or compatible ServiceMode HTTPS RRs are found, the client SHOULD behave as if it received an HTTP 307 redirect to the 'https' URL. Clients MUST NOT place more trust in this signal than a cleartext HTTP 307 response.
Clients and recursive resolvers MUST impose a limit on the total number of SVCB AliasMode records they will follow per resolution request. This limit MUST NOT be zero; implementations MUST be able to follow at least one AliasMode record.
Clients for pre-existing protocols (e.g., HTTP) SHALL implement SVCB-optional behavior. After SVCB resolution, if at least one AliasMode record was processed, SVCB-optional clients SHALL append the final $QNAME with the authority endpoint's port and no SvcParams to the list of endpoints to try.
Clients MUST consider an RR malformed if the RDATA ends within a SvcParam, if SvcParamKeys are not in strictly increasing numeric order, or if a SvcParamValue does not have the expected format. If any RR in an RRset is malformed, the client MUST reject the entire RRset and fall back to non-SVCB connection establishment.
Clients MUST NOT perform SVCB queries or accept SVCB responses for 'https' or 'http' schemes; the HTTPS RR type (65) MUST be used instead for those schemes.
Clients MUST NOT use an HTTPS RR response unless the client supports the TLS SNI extension and indicates the origin name in the ClientHello. The SNI and HTTP Host/:authority headers indicate the origin, not the TargetName.
Clients using a proxy that does not provide SVCB query capability SHOULD arrange a separate SVCB resolution procedure with appropriate privacy. If that is not possible, SVCB-optional clients MUST disable SVCB resolution entirely, and SVCB-reliant clients MUST treat the configuration as invalid.
If DNS responses are cryptographically protected (DNSSEC or TLS) and SVCB resolution fails due to an authentication error, SERVFAIL, transport error, or timeout, clients SHOULD abandon their connection attempt even if SVCB-optional, to prevent downgrade attacks.
Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys, treating the SvcParams as opaque if needed. When responding to a DNSSEC OK query, DNSSEC-capable resolvers MUST accompany each Additional section RRset with the same DNSSEC records they would send in the Answer.
To establish an ALPN-negotiated connection, clients MUST compute the intersection of the SVCB ALPN set with client-supported protocols, determine implied transports, and for each transport construct a ProtocolNameList containing all client-supported protocols for that transport (not restricted to the SVCB ALPN set).
When a proxy is used with SVCB, clients MUST provide the final TargetName and port to the proxy; the proxy performs any required A/AAAA lookups. Clients SHOULD follow standard SVCB resolution to select the smallest-SvcPriority compatible option.
SVCB queries additionally reveal the user's intent to use a particular protocol, beyond the domain name already revealed by standard address queries. This information is visible to the recursive resolver and to many other parties when plaintext DNS transport is used.
AliasMode (SvcPriority=0) delegates operational control by aliasing a service to TargetName, enabling CNAME-like functionality at zone apices where CNAME is prohibited. Recipients MUST ignore any SvcParams present in AliasMode records.
ServiceMode (SvcPriority>0) associates an alternative endpoint with its connection parameters via SvcParams. Clients MUST ignore unrecognized SvcParamKeys unless the 'mandatory' key requires them; an RR whose recognized SvcParams are not self-consistent MUST be rejected.
SvcPriority is a 2-octet integer (0–65535). A value of 0 places the record in AliasMode; any non-zero value places it in ServiceMode. Lower values are preferred over higher ones when selecting among ServiceMode records in an RRset.
The 'alpn' SvcParamKey (key 1) indicates ALPN protocol identifiers supported by the endpoint. Wire format: one or more alpn-ids, each prefixed by a single-octet length, concatenated to exactly fill the SvcParamValue. ALPN IDs that do not uniquely identify a protocol suite MUST NOT be included.
The 'ipv4hint' (key 4) and 'ipv6hint' (key 6) SvcParamKeys provide IP address hints. Wire format: a sequence of 4-byte IPv4 or 16-byte IPv6 addresses in network byte order; an empty list is invalid. Clients SHOULD ignore hints when A/AAAA records for TargetName are locally available.
The 'mandatory' SvcParamKey (key 0) lists additional SvcParamKeys that must be understood for the RR to be usable; a client considers an RR 'compatible' only if it recognizes all mandatory keys. 'mandatory' is itself always automatically mandatory and MUST NOT appear in its own value list. Wire format: numeric key values in network byte order in strictly increasing order.
The 'no-default-alpn' SvcParamKey (key 2) signals that the scheme's default ALPN protocol set is not supported at this endpoint. Its presentation and wire-format values MUST be empty; when present, 'alpn' must also appear for the RR to be self-consistent.
The 'port' SvcParamKey (key 3) specifies the TCP or UDP port for the alternative endpoint. Wire format: a 2-octet value in network byte order. If absent, clients SHALL use the authority endpoint's port. The presentation value must not contain escape sequences.
IANA created the 'Service Parameter Keys (SvcParamKeys)' registry under Expert Review policy. Initial entries: 0=mandatory, 1=alpn, 2=no-default-alpn, 3=port, 4=ipv4hint, 5=ech (reserved for Encrypted ClientHello), 6=ipv6hint; 65280–65534 reserved for Private Use; 65535 reserved as 'Invalid key'.
IANA registered SVCB (RR type 64) as 'General-purpose service binding' and HTTPS (RR type 65) as 'SVCB-compatible type for use with HTTP' in the DNS Resource Record (RR) TYPEs registry.
A hostile DNS intermediary can block SVCB resolution to perform a downgrade attack, preventing the 'https' upgrade provided by HTTPS RRs and disabling SvcParam-based protections. Section 3.1 recommends clients abandon connection attempts when downgrade attacks are detected via authentication errors or transport failures.
A hostile DNS intermediary can forge SVCB records pointing to arbitrary IP addresses and ports, including internal network addresses, potentially enabling server-side request forgery if the attacker can influence the client's payload. SVCB mapping documents SHOULD specify appropriate port number restrictions.
SVCB/HTTPS RRs are distributed over untrusted channels and DNSSEC is OPTIONAL. Clients MUST ensure their DNS cache is partitioned per local network or flushed on network changes to prevent a local adversary from implanting forged DNS records that persist after the user leaves that network.
The SVCB RDATA consists of a 2-octet SvcPriority in network byte order, a fully qualified uncompressed TargetName encoded as length-prefixed labels per RFC 1035, and zero or more SvcParams. Each SvcParam is a 2-octet SvcParamKey, a 2-octet SvcParamValue length, and the value bytes; SvcParamKeys MUST appear in strictly increasing numeric order.