Keep origin security and fallback rules
06Alternative connection coordinates do not change the HTTPS identity the client must authenticate.
Separate case: an authenticated DNS transport times out during SVCB resolution. The client SHOULD abandon the service attempt instead of silently downgrading. This is a SHOULD, not a universal MUST.
Key idea: Authenticate the origin and distinguish absence from protected lookup failure.
Terms
- Service binding
- A DNS record associates a service endpoint with that endpoint’s connection parameters.
- Origin
- The scheme, host and port identifying the HTTP service. An alternative endpoint does not replace this identity.
- ALPN
- Application-Layer Protocol Negotiation: protocol identifiers used with transports such as TLS or QUIC.
- RRset
- Resource records with the same owner name, class and type; an unordered set.
Rules & examples
Authenticate the origin and distinguish absence from protected lookup failure.
- HTTPS RR clients MUST support SNI and indicate the origin name in ClientHello. SNI and HTTP Host/:authority identify the origin, not TargetName. Certificate hostname validation remains based on the original origin (§§2.3,9.1,9.4).
- SVCB/HTTPS can travel over untrusted DNS. Clients are REQUIRED to verify the alternative endpoint is authoritative for the service. DNSSEC is optional for this mechanism; a DNS hint is not a certificate (§§9.2.2,12).
- Pre-existing protocols such as HTTP SHALL be SVCB-optional, subject to §3.1 and future specifications. After following aliases, append a no-parameter endpoint at the final query name and authority port; try it before non-SVCB fallback. Absent compatible records and exhausted connection alternatives can lead to ordinary fallback (§3).
- If cryptographically protected DNS fails with authentication error, SERVFAIL, transport error or timeout, clients SHOULD abandon the service attempt to resist downgrade. Unprotected failures MAY be fatal or nonfatal. Malformed-RRset and alias-limit fallback rules are specified separately (§§2.2,3.1).
- Before http requests, clients SHOULD query the corresponding https URL (explicit 80 becomes 443). AliasMode or compatible ServiceMode HTTPS answers SHOULD trigger temporary-redirect-equivalent upgrade, with no more trust than a cleartext 307. Incompatible ServiceMode alone does not trigger it (§9.5).
Fictional names and documentation addresses. This is a bounded connection-discovery illustration, not a DNS server, TLS implementation or full deployment recipe.
Sources
New to this? Start hereA quick picture + helpful background
Read one endpoint’s instruction card
Imagine a service offering several entrances, each with its own instructions. Keep each card intact: an entrance address and its required equipment belong together. DNS service binding works similarly, but the client must still verify the service’s identity when connecting.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.