Summary

  • A lower SVCB priority expresses preference only among records a client can actually use. Malformed, inconsistent or incompatible records are rejected first; an unknown mandatory key can therefore make the apparent first choice ineligible.
  • AliasMode delegates discovery without changing the origin. ServiceMode binds a target to connection parameters, but hints, advertised ALPN and even authenticated DNS remain inputs; A/AAAA resolution, TLS validation for the original name, negotiated protocol and application response provide later proof.

The record at the front of the line

Consider an origin that publishes two HTTPS ServiceMode records. Priority 1 points to a new edge and includes an experimental parameter marked mandatory. Priority 2 points to the existing edge with parameters the installed client understands. Both records are syntactically valid. The operator's dashboard calls priority 1 the preferred endpoint.

For that client, it is not an endpoint at all.

RFC 9460 requires a client to ignore a ServiceMode record when it does not recognize every mandatory key. The client therefore evaluates priority 2 and may connect successfully. Nothing has inverted the priority rule. Eligibility was decided before preference was applied.

This analytical scenario is not a report about a named browser or CDN. It exposes a recurrent governance error: treating a published ordering as if it were an executed command. The DNS owner can describe candidate connection plans. It cannot make every client capable of interpreting them, make every address reachable, make a server negotiate the advertised protocol or make a certificate authenticate the origin.

Two modes allocate different authority

RFC 9460 defines SVCB record type 64 and the HTTPS-compatible type 65. Each record carries a priority, a target name and optional service parameters. Priority zero means AliasMode. A nonzero value means ServiceMode.

AliasMode delegates service discovery to another name. Its central operational benefit is service-specific aliasing at a zone apex, where a CNAME cannot normally replace the name. The limit matters: the alias applies to this SVCB-compatible service, not to every RR type at the name. Its parameters are ignored. Implementations must bound alias chains, because delegation without a stopping rule becomes a loop.

Most importantly, aliasing does not rewrite the origin. A client following an HTTPS AliasMode record to a provider target still authenticates the original service name. TLS SNI and the HTTP Host or :authority value identify that origin, not the target label. The domain owner has delegated a route to service, not transferred the reader to a new identity.

ServiceMode allocates a different power. One RR binds TargetName, port, protocol set, address hints and later extensions into one candidate plan. This binding solves a real problem: independent lookups can otherwise combine the endpoint of one provider with the parameters of another. In a multi-CDN design, each provider can publish a plan matching its own capabilities.

The record is still a proposal to compatible clients. It does not certify that the target is alive or that its current deployment matches the zone.

Rejection comes before selection

The selection algorithm has gates. A malformed wire record can invalidate the entire RRset and return the client to non-SVCB connection behavior. A recognized parameter conflict makes a record internally inconsistent and unusable. An unknown ordinary parameter may be ignored, but an unknown mandatory parameter makes that record incompatible.

Only the surviving records enter priority selection. Lower numbers are tried before higher numbers. Records at the same priority are shuffled, giving balanced random distribution rather than SRV's operator-assigned weight. A low number therefore means “prefer this compatible plan,” not “obey this target.”

The mandatory parameter is often described too loosely. It does not compel the server to implement a feature and does not upgrade the client. It declares that ignoring a listed key would make this record unsafe or meaningless. The client either understands every listed requirement or excludes the record. The list must refer to keys present in the same record and cannot include mandatory itself.

For HTTPS, port and no-default-alpn are automatically mandatory when present. This makes sense: ignoring a changed port sends traffic to the wrong listener, while ignoring removal of the default protocol can negotiate something the endpoint did not offer. These small rules prevent graceful extensibility from becoming silent reinterpretation.

Advertised protocol is not negotiated protocol

The alpn parameter describes protocol suites offered at an alternative endpoint. It lets a client prepare HTTP/2 over TLS/TCP or HTTP/3 over QUIC without first visiting a default endpoint. But the DNS list is not the handshake result.

The client constructs an appropriate connection attempt, and ALPN negotiation still occurs with the server. A zone can be ahead of a deployment, an edge can lag, a firewall can block UDP, or one address can serve a different generation. Investigation must retain both values: the ALPN set received in DNS and the protocol actually selected in the handshake.

The same discipline applies to port. The record can nominate a non-default port, but client policy or a network firewall can reject it. Publication proves what the domain's DNS path said. A socket result proves whether that path was usable from one vantage point.

A hint is allowed to be temporary

ipv4hint and ipv6hint exist to reduce latency when the resolver has not supplied the target's addresses. They are deliberately weaker than a replacement for A and AAAA. If TargetName address data are locally available, the client should ignore the hints. Otherwise it still resolves TargetName and should prefer those authoritative address answers for future connections.

This distinction permits optimistic work without turning an optimization into durable routing authority. A client may start against a hint and later switch to an address answer. Geo-aware steering may change the set. DNS64 may synthesize an AAAA answer but must not rewrite the signed IPv6 hint inside the SVCB data.

An audit that records only “connected to 192.0.2.8” loses the decision. Was the address a hint, an A answer, resolver additional data, a cached result or proxy-side resolution? Which TTL and network applied? The answer determines whether a mismatch is stale DNS, an intended race, a provider split or unauthorized redirection.

The original name survives every detour

RFC 9460 assumes SVCB and HTTPS records may travel through an untrusted DNS channel. DNSSEC signing and validation can authenticate the RRset, but they are optional. Safety therefore cannot depend on the DNS answer alone.

The alternative endpoint must still prove authority for the original service. In HTTPS, the client sends the origin name in SNI and validates the certificate against that name. The HTTP request keeps the original authority. A certificate valid only for the provider's TargetName is insufficient, even if the DNS owner published the alias and every DNSSEC signature validates.

This is a precise separation of powers. DNS controls discovery. The TLS service-identity rules control authenticated endpoint identity. ALPN records what the two peers negotiated. HTTP controls the origin-level request and response. One successful stage cannot attest for the others.

Fallback is a policy, not a footnote

HTTP predates SVCB, so clients are generally SVCB-optional. They can make parallel address queries and may fall back to ordinary connection behavior when SVCB is absent or unusable. That preserves deployment freedom, but it also creates a downgrade boundary.

If an authenticated SVCB lookup fails through SERVFAIL, authentication error, protected transport failure or timeout, the client should abandon the connection attempt rather than silently discard protected parameters. If ordinary unauthenticated DNS fails, the client may treat the event as fatal or nonfatal. The difference means a monitoring system must record not just “no SVCB result” but why the result was unavailable and what protection the query had.

Optimistic preconnection has a similar limit. If an address arrives before the SVCB response, the client may begin connecting, but it must not send information whose form the pending parameters could change. Speed is permitted; irreversible disclosure is not.

Multi-provider DNS produces split evidence

SVCB was designed for services spread across independent operators. Bound plans let one CDN advertise HTTP/3 while another exposes only HTTP/2, each with its own targets and ports. Yet DNS answers can still be produced at different times or views. A CNAME lookup can select one provider while an HTTPS lookup and a later A lookup observe another.

The RFC explicitly anticipates this and requires clients to fetch the addresses corresponding to the selected TargetName. Hints can reduce the delay but cannot prove that independently obtained RRsets share one generation. Operators need release identifiers or fingerprints across DNS and edge configurations if they want to explain a mismatch.

This is where Running-Code Primacy becomes practical. A zone-file declaration has value because compatible software interprets it. The smallest legitimate common rule is the one needed to keep independently operated clients, resolvers and endpoints interoperable. It is not a mandate for a DNS publisher to govern every client fallback or for a client vendor to rewrite the domain owner's service policy.

Sources