Use protocol and address hints
05ALPN hints select possible transports; address hints can start a connection while normal address queries continue.
A response supplies 192.0.2.2 for the same target. The client SHOULD use returned addresses for future connections; switching an existing hinted connection is optional.
Key idea: Hints inform establishment; the handshake still negotiates.
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
Hints inform establishment; the handshake still negotiates.
- For HTTPS, the default ALPN set is http/1.1. Add the alpn list unless no-default-alpn is present. no-default-alpn has an empty value and requires alpn for self-consistency (§§7.1,9).
- Intersect the SVCB ALPN set with client support to determine possible transports. For each selected transport, the ClientHello MUST offer all client-supported ALPN protocols for that transport, not just the DNS intersection. The handshake negotiates independently (§7.1.2).
- With alpn=h3 and no no-default-alpn, an HTTPS endpoint advertises both HTTP/3 and default HTTP/1.1. A client supporting h2 can also offer h2 alongside http/1.1 on TLS over TCP. HTTP/3 uses QUIC; port applies to the selected transport (§§7.1–7.2).
- Clients MAY use ipv4hint/ipv6hint. If local A/AAAA are available they SHOULD ignore hints; otherwise they SHOULD query TargetName and SHOULD use response addresses for future connections. Hint lists must be nonempty and correctly sized. DNS64 resolvers MUST NOT synthesize inside hints (§§4.2.1,7.3).
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.