Contents
3. Client Behavior
- "SVCB resolution" is the process of enumerating and ordering the available endpoints for a service, as performed by the client. SVCB resolution is implemented as follows:
- Let $QNAME be the service name plus appropriate prefixes for the
- scheme (see Section 2.3).
- Issue a SVCB query for $QNAME.
If an AliasMode SVCB record is returned for $QNAME (after
following CNAMEs as normal), set $QNAME to its TargetName (without additional prefixes) and loop back to Step 2, subject to chain length limits and loop detection heuristics (see Section 3.1).
If one or more "compatible" (Section 8) ServiceMode records are
- returned, these represent the alternative endpoints. Sort the
records by ascending SvcPriority.
- returned, these represent the alternative endpoints. Sort the
- Otherwise, SVCB resolution has failed, and the list of available
- endpoints is empty.
of ServiceMode records; otherwise, it is called "SVCB-reliant". Clients for pre-existing protocols (e.g., HTTP) SHALL implement SVCB- optional behavior (except as noted in Section 3.1 or when modified by future specifications). SVCB-optional clients SHOULD issue in parallel any other DNS queries that might be needed for connection establishment if the SVCB record is absent, in order to minimize delay in that case and enable the optimizations discussed in Section 5. Once SVCB resolution has concluded, whether successful or not, if at
least one AliasMode record was processed, SVCB-optional clients SHALL append to the list of endpoints an endpoint consisting of the final value of $QNAME, the authority endpoint's port number, and no SvcParams. (This endpoint will be attempted before falling back to non-SVCB connection modes. This ensures that SVCB-optional clients will make use of an AliasMode record whose TargetName has A and/or AAAA records but no SVCB records.) The client proceeds with connection establishment using this list of endpoints. Clients SHOULD try higher-priority alternatives first, with fallback to lower-priority alternatives. Clients resolve AAAA
and/or A records for the selected TargetName and MAY choose between them using an approach such as Happy Eyeballs [HappyEyeballsV2]. If the client is SVCB-optional and connecting using this list of endpoints has failed, the client now attempts to use non-SVCB connection modes. Some important optimizations are discussed in Section 5 to avoid additional latency in comparison to ordinary AAAA/A lookups.
3.1. Handling Resolution Failures
- If DNS responses are cryptographically protected (e.g., using DNSSEC or TLS [DoT] [DoH]) and SVCB resolution fails due to an authentication error, SERVFAIL response, transport error, or timeout, the client SHOULD abandon its attempt to reach the service, even if the client is SVCB-optional. Otherwise, an active attacker could
mount a downgrade attack by denying the user access to the SvcParams. A SERVFAIL error can occur if the domain is DNSSEC-signed, the recursive resolver is DNSSEC-validating, and the attacker is between the recursive resolver and the authoritative DNS server. A transport error or timeout can occur if an active attacker between the client and the recursive resolver is selectively dropping SVCB queries or responses, based on their size or other observable patterns. If the client enforces DNSSEC validation on A/AAAA responses, it SHOULD apply the same validation policy to SVCB. Otherwise, an attacker could defeat the A/AAAA protection by forging SVCB responses that direct the client to other IP addresses. If DNS responses are not cryptographically protected, clients MAY treat SVCB resolution failure as fatal or nonfatal. If the client is unable to complete SVCB resolution due to its chain length limit, the client MUST fall back to the authority endpoint, as if the service'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 of using named destinations, in which case the client does not perform any A or AAAA queries for destination domains. If the client is configured to use named destinations with a proxy that does not provide SVCB query capability (e.g., through an affiliated DNS resolver), the client would have to perform SVCB resolution separately, likely disclosing the destinations to additional parties and not just the proxy. Clients in this configuration SHOULD arrange for a separate SVCB resolution procedure with appropriate privacy properties. If this is not possible, SVCB-optional clients MUST disable SVCB resolution entirely, and SVCB-reliant clients MUST treat the configuration as invalid. If the client does use SVCB and named destinations, the client SHOULD follow the standard SVCB resolution process, selecting the smallest-
SvcPriority option that is compatible with the client and the proxy. When connecting using a SVCB record, clients MUST provide the final TargetName and port to the proxy, which will perform any required A and AAAA lookups.
}}}