Service Binding Mapping for DNS Servers
Extracted elements (24)
This document concerns only DNS transport and does not affect the construction or interpretation of DNS messages. It does not indicate whether a service is a recursive or authoritative server — clients must determine intended use from context. Not all transports will be applicable in all contexts, and implementors are not obligated to implement all defined transports.
When a binding authority specifies a non-default port, Port Prefix Naming encodes the port in an additional label prefix (e.g., _9953._dns.dns1.example.com). This allows two DNS services on the same host but different ports to independently advertise different SVCB configurations without conflict.
Where resolution speed is a high priority, the SVCB TargetName SHOULD follow the convention in Section 10.2 of the SVCB specification, and AliasMode records are NOT RECOMMENDED, because AliasMode introduces an additional lookup round-trip.
If the "alpn" set contains protocols with different default ports and no "port" key is specified, each protocol is contacted separately on its default port. In this configuration, ALPN negotiation does not defend against cross-protocol downgrade attacks because no single port constrains the negotiation.
If the authentication name is received over an insecure channel (e.g., a glue NS record), this specification cannot prevent the client from connecting to an attacker. The security of this mechanism depends on the integrity of the channel used to obtain the authentication name.
Clients SHOULD NOT query for HTTPS RRs when using "dohpath"; instead, the SvcParams and address records associated with the SVCB record SHOULD be used for the HTTPS connection. However, service operators SHOULD publish an equivalent HTTPS RR for consistency.
Clients SHOULD NOT support the "port" key unless: they trust the DNS server not to exploit port confusion, operate in a context where implicit elevated access cannot apply, or restrict allowed TCP port values to exclude ports susceptible to confusion attacks (e.g., using the "bad ports" list).
If the "alpn" SvcParam indicates any HTTP versions (e.g., "h2", "h3"), the record indicates DoH support and the "dohpath" key MUST be present. All SvcParamKeys valid for HTTPS records are also permissible and apply to the resulting HTTP connection.
If the "alpn" SvcParamKey is absent, the client MUST treat the SVCB record as "incompatible" unless some other recognized SvcParam indicates a supported protocol. There is no default protocol for the "dns" scheme, so "no-default-alpn" does not apply.
If the "port" key is omitted, the client SHALL use the default port number for each transport protocol: 853 for DoT and DoQ, 443 for DoH.
Multiple DNS services MUST NOT share a hostname identifier (as defined in Section 3) unless they are sufficiently similar that allowing an attacker to choose between them is safe. Sharing a hostname enables a redirection adversary to substitute one service for another.
To mitigate redirection attacks, a client of this SVCB mapping MUST NOT identify or authenticate itself when performing DNS queries, except to servers it specifically knows are not vulnerable to redirection attacks. If an endpoint sends an invalid DNS response, the client SHOULD NOT send further queries to that endpoint and MAY log the error.
When using a SVCB record with "dohpath", the client MUST send DoH requests to the HTTP origin identified by the "https" scheme, the authentication name, and the port from the "port" SvcParam (if present). HTTP requests MUST be directed to the resource resulting from DoH URI Template expansion of the "dohpath" value.
"dohpath" is a new single-valued SvcParamKey whose value MUST be a URI Template in relative form (RFC 6570) encoded in UTF-8. It is required when the "alpn" SvcParam indicates HTTP support. The URI Template MUST contain a "dns" variable and MUST produce a valid HTTP ":path" value after DoH URI Template expansion.
SVCB record names for DNS services are formed using Port Prefix Naming with a scheme of "dns". For a DNS service at dns1.example.com, records are queried at _dns.dns1.example.com. When a non-default port is specified (e.g., port 9953), an additional port prefix is added: _9953._dns.dns1.example.com.
The "port" key is automatically mandatory for the "dns" SVCB binding. A client that does not respect the "port" key MUST ignore any SVCB record containing this key, as defined by the SVCB "automatically mandatory" semantics.
The SvcParamKeys "mandatory", "ipv4hint", and "ipv6hint" from the base SVCB specification apply to the "dns" scheme without modification. Future SvcParamKeys may also apply.
Two identity concepts are distinguished: the "binding authority" (service name and optional port used as input to Port Prefix Naming) and the "authentication name" (used for secure transport authentication). The authentication name MUST be a DNS hostname or literal IP address, and defaults to the service name from the binding authority.
IANA added entry number 7, name "dohpath", to the "Service Parameter Keys (SvcParamKeys)" registry. Meaning: DNS-over-HTTPS path template. Format reference: RFC 9461. Change controller: IETF.
IANA added the entry "_dns" with RR Type SVCB to the DNS "Underscored and Globally Scoped DNS Node Names" registry (per RFC 8552/BCP 222), enabling use of _dns as the Port Prefix Naming label for DNS services.
An adversary on the query path can forge a response indicating SVCB records do not exist. For SVCB-reliant clients this results in denial of service only. SVCB-optional clients will fall back to insecure DNS, exposing all DNS traffic to surveillance and manipulation.
An adversary on the query path can manipulate transport, port number, and "dohpath" value to redirect DNS queries to arbitrary ports and paths on the legitimate hostname. If shared TLS or HTTP state (e.g., client certificates, cookies) exists, the client may be correctly authenticated to a malicious endpoint, enabling data exfiltration or unexpected service interactions.
An adversary on the transport path can modify traffic between the client and the alternative service TargetName. For SVCB-reliant clients this causes only denial of service; for SVCB-optional clients it enables a downgrade to unencrypted DNS. Accordingly, when SVCB use is optional, clients SHOULD switch to SVCB-reliant behavior if SVCB resolution succeeds.
During secure transport establishment, clients MUST authenticate the server to its authentication name, which is not influenced by SVCB record contents. This authentication requirement prevents impersonation even if the SVCB record is forged. DNSSEC is not mandated because the authentication name provides an independent trust anchor.