Choose compatible bound records
04A low priority is useful only if the client can use the entire record.
Separate negative record: mandatory=key65444 without key65444. It is not self-consistent. The client MUST reject the record and MAY reject the RRset.
Key idea: Ignore an incompatible record rather than borrowing its pieces.
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
Ignore an incompatible record rather than borrowing its pieces.
- A ServiceMode RR is compatible when the client recognizes all mandatory keys and their values allow a successful connection. Ignore incompatible records; sort compatible records by ascending SvcPriority (§§3,8).
- The mandatory key lists extra required keys. For self-consistency, listed keys MUST be present; mandatory MUST NOT list itself. Its wire list is strictly increasing with no repeats (§8).
- Unknown non-mandatory parameters are ignored unless a protocol mapping says otherwise. HTTPS automatically requires understanding port and no-default-alpn when present; mandatory itself is always automatically mandatory (§§2.4.3,8,9).
- Clients MUST reject a record whose recognized parameters are not self-consistent and MAY reject the whole RRset. Clients SHOULD try higher-priority alternatives first, with fallback to lower-priority alternatives. Equal-priority records SHOULD be shuffled; §§5.1–5.2 permit specified connection-reuse/incomplete-response optimizations.
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.