Summary

  • SVCB and HTTPS records bind alternative endpoints to per-endpoint parameters and let the publisher recommend an order. DNSSEC can authenticate that recommendation, but it does not establish client compatibility, reachability, TLS identity or application success.
  • The client remains the execution authority: it rejects malformed and incompatible records, interprets mandatory keys, randomizes ties, applies proxy and address policy, attempts connections, falls back where permitted, and validates the original service identity.

Imagine a signed HTTPS RRset with two ServiceMode records. Priority 1 names an HTTP/3 endpoint and carries a parameter the publisher regards as essential. Priority 2 offers HTTP/2 on a different port. A current mobile client understands the first bundle and reaches it over IPv6. A managed desktop behind a named-destination proxy cannot perform the required private SVCB resolution, so it disables SVCB. A third client already has a compatible connection to the priority-2 endpoint and reuses it.

The zone was not contradictory. The clients were not necessarily nonconforming. One authenticated statement produced three legitimate running outcomes because the statement described options, while the clients inhabited different capability, policy and network realities.

RFC 9460 gives this arrangement its vocabulary. SVCB is DNS RR type 64, a general-purpose service-binding record. HTTPS is type 65, a SVCB-compatible record with HTTP-specific handling. Both were standardized in November 2023 to let a service publish useful connection information before a client spends round trips on a suboptimal default path.

The design has two modes. SvcPriority zero means AliasMode: the service is delegated to a TargetName. A positive value means ServiceMode: the TargetName identifies an alternative endpoint, and the SvcParams in the same record describe how that endpoint is offered. The distinction matters because binding is the feature. A protocol, port and hint set attached to one endpoint should not be assembled from independently rotating RRsets that may describe different deployments.

AliasMode is narrower than CNAME. It applies only to the queried SVCB-compatible RR type, does not rewrite every other type at the owner name, and ignores SvcParams under the current specification. It can support apex delegation, but aware clients must follow its bounded alias chain while legacy clients may continue to depend on ordinary A and AAAA records. An apex HTTPS alias can therefore improve the path for participating clients without erasing the old path by decree.

ServiceMode delegates a different kind of discretion. The publisher specifies admissible endpoint bundles; the client constructs the set it can actually use. It first rejects malformed or self-inconsistent records. It ignores an unknown parameter unless that parameter is marked mandatory. If a mandatory key is unknown, or its value makes successful establishment impossible for that client, the record is incompatible and is ignored.

That rule is an extensibility bargain, not a weakness. Older clients can ignore optional innovations. A publisher can also say that ignoring a particular feature would make this endpoint function incorrectly. But “mandatory” has an operational cost: it deliberately removes the record from the eligible set of clients that do not understand the key. It should describe a real functional requirement, not the publisher's hope that every client will upgrade.

The live IANA DNS SVCB registry shows why compatibility cannot be assumed. The original keys cover mandatory, ALPN, default-ALPN suppression, port and IPv4/IPv6 hints. By its 2026-06-25 update, the registry also included ECH configuration, a DoH path, OHTTP, TLS supported groups, a DNS-over-CoAP path, provisioning-domain configuration and an operator-confidence parameter for nameserver transports. Registration provides a stable code point and meaning. It does not prove that a given client implements the key or that the key applies safely to every protocol mapping.

Priority is similarly bounded. A smaller positive SvcPriority is the domain owner's recommendation. Records with equal priority are not processed in zone-file order; the client should shuffle the tied group randomly for uniform load distribution. There is no SRV-style weight. RFC 9460's comparison with SRV makes the difference explicit: SVCB is extensible, can signal protocol upgrades and is generally optional for pre-existing protocols, while equal-priority selection is balanced randomization.

Even the recommended ordering has documented exceptions. A client should try higher-priority compatible alternatives first and fall back to lower priorities. It may also try several options in parallel, prefetch several TargetNames, prefer an option whose associated data avoids another DNS query, or continue a compatible connection already in progress even when another record has the smaller priority number. SvcPriority shapes the choice; it does not provide a packet-level prophecy.

ALPN illustrates the remaining work. The alpn parameter advertises the protocol suites offered at an endpoint, but a client filters that list against the suites it supports. RFC 7301 then governs negotiation inside the TLS handshake. An RR containing h3 says that the endpoint offers the corresponding suite. It does not prove that this client has QUIC enabled, that the network passes UDP, or that the server will negotiate and serve the origin correctly at that moment.

Address hints are also invitations, not address authority. RFC 9460 says ipv4hint and ipv6hint may reduce latency when associated address data is not already available. If A or AAAA answers are local, the client should ignore the hints. Otherwise it should query the TargetName and can switch away from a hinted address when the real address answer arrives. Persisting with a hint can defeat geography-aware routing or load distribution.

Once addresses exist, the client may choose among them with an approach such as Happy Eyeballs Version 2. Which family wins depends on the client, delay schedule and current path. The service owner has supplied a coherent candidate. The network decides which candidate is reachable quickly enough to matter, and the client turns that observation into a route.

DNSSEC strengthens only one link in this chain. RFC 9460 does not make HTTPS records inherently authentic; it models DNS as potentially controlled by an attacker and makes DNSSEC signing and validation optional. If a client enforces DNSSEC for A and AAAA, the RFC says it should apply the same policy to SVCB so a forged binding cannot bypass protected address data. RFC 4035 supplies the validation machinery.

A Secure SVCB RRset means the validating chain attributes that RRset to the signed zone without detected modification. It still cannot say whether the endpoint is up, whether a proxy allows it, whether the client recognizes its mandatory parameters, or whether the certificate is valid. Cryptographic authenticity prevents one category error only if operators resist making another: authenticated recommendation is not authenticated connection success.

The strongest boundary is service identity. RFC 9460 says its aliases and TargetNames do not alter the origin or validation authority. For HTTPS, TLS SNI and HTTP Host or :authority continue to name the original origin, not the TargetName. RFC 9525 confirms that using SVCB or HTTPS connection information does not change existing PKIX validation requirements for HTTP or DNS-over-TLS.

This is why operational delegation does not silently transfer identity authority. A CDN endpoint named by DNS may receive the connection, but it must still authenticate and serve the original origin. A successful TCP or QUIC handshake to the alternative's own name is not enough. The route has changed; the service claim has not.

The comparison with HTTP Alternative Services clarifies the point. Alt-Svc can change host, port and protocol while leaving the origin intact, and a client selects among alternatives according to its own security criteria. HTTPS RRs can expose similar information before the first HTTP exchange. Alt-Svc uses its own ma freshness value; HTTPS RRs use DNS TTL. RFC 9460 deliberately omits an Alt-Svc-like persistence key because DNS is treated as an untrusted channel.

RFC 9110 anchors the HTTP side of the separation: the origin and authority identify the resource context even when connection routing changes. When DNS and Alt-Svc advertisements interact, RFC 9460 limits the client to combinations consistent with both. Consistency narrows the option set. It still does not make an option compulsory.

Fallback is where availability and security incentives collide. For pre-existing protocols such as HTTP, clients normally implement SVCB-optional behavior. They can issue ordinary address queries in parallel, try compatible higher and lower priorities, then use non-SVCB connection behavior after the advertised endpoints fail. That protects reachability when authoritative servers, recursive resolvers, clients and endpoints are upgraded at different times.

It can also become a downgrade. If the preferred endpoint carries HTTP/3, ECH or another privacy property, blocking that path may push an optional client toward a connection without it. RFC 7838 warns about the same failure pattern for alternative services. Operators must decide which properties are accelerators and which are security floors. The DNS record cannot make that risk decision for every client's environment.

Proxies expose an additional authority boundary. A named-destination proxy may perform A and AAAA resolution on the client's behalf. If the client separately resolves SVCB through an unrelated resolver, it can disclose the destination beyond the intended proxy path. RFC 9460 therefore requires an optional client to disable SVCB when it cannot arrange a resolution procedure with suitable privacy; a SVCB-reliant client must reject the configuration. Where SVCB is used, compatibility includes the proxy, and the proxy may choose the address family from its own network position.

The non-HTTP mapping in RFC 9461 reinforces the structure. It uses SVCB to describe DNS-over-TLS, DNS-over-HTTPS and DNS-over-QUIC services, with mapping-specific parameters and downgrade considerations. The shared wire format does not erase protocol semantics. Each mapping defines which keys are meaningful and safe, and the client still has to validate the service it is trying to reach.

Heng Lu's distinctions among running-code primacy, a minimum initial specification with localized future decision, and reality layers are operationally useful here. The specification defines a narrow shared syntax and algorithm. The zone publishes a bounded statement. The resolver transmits some view of it. The client interprets it under local policy. TLS negotiates a connection. The application proves whether the original service was actually delivered.

An audit that stops at dig HTTPS stops too early. It should retain the RRset and DNSSEC state, the client and proxy mode, recognized and mandatory keys, chosen record, address attempts, ALPN result, certificate identity, fallback reason and final application response. The publisher can truthfully say what it offered. Only the running client can say which offer became a secure connection.