Wiki · Concept · Last reviewed June 25, 2026

SVCB and HTTPS Resource Records

SVCB and HTTPS Resource Records are RFC 9460 DNS records for publishing service endpoints and connection parameters before a client opens the transport connection.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, SVCB, HTTPS RR, ECH, privacy, agents, routing, metadata

Definition

SVCB and HTTPS Resource Records are defined by RFC 9460, published in November 2023 as an Internet Standards Track RFC. SVCB means Service Binding. The records let DNS publish information a client needs before connecting to a network service, including alternative endpoints and endpoint-specific parameters. The HTTPS record is the SVCB-compatible form for HTTP origins.

The basic move is simple but consequential: DNS can say more than "this name has these addresses." It can also describe how the service wants to be reached. RFC 9460 names examples such as alternative endpoints, transport protocol configuration, apex-domain aliasing, and future extensions such as keys for encrypting the TLS ClientHello.

Mechanism

RFC 9460 assigns the SVCB DNS RR type to type 64. The record has three main fields: SvcPriority, TargetName, and optional SvcParams. A SvcPriority value of 0 means AliasMode, where the record points operational control to another name. Any nonzero value means ServiceMode, where the record binds a target endpoint to connection parameters.

ServiceMode is where most privacy and performance behavior appears. SvcParams can advertise ALPN values, suppress default ALPN behavior, specify a non-default port, provide IPv4 or IPv6 address hints, and mark other parameters as mandatory. RFC 9460 also defines compatibility rules so a client can reject records whose mandatory parameters it does not understand.

SVCB is a framework rather than a single feature. RFC 9848 uses it to publish Encrypted Client Hello configuration through the ech SvcParam in SVCB or HTTPS records. RFC 9461 maps SVCB to named DNS servers, allowing them to advertise encrypted transports such as DNS over TLS, DNS over HTTPS, and DNS over QUIC.

Privacy Boundary

SVCB and HTTPS records can improve privacy when they help clients reach encrypted transports, use Encrypted Client Hello, or avoid extra probing. They can also reveal more intent through DNS. The same record that helps a browser find HTTP/3 support or ECH configuration is itself a query and response visible to resolvers and, if DNS transport is not protected, to on-path observers.

RFC 9460 treats DNS resolution as an untrusted channel for some HTTPS behavior. RFC 9848 is even more direct for ECH: it says the specification does not conceal the server name from the DNS resolver. SVCB can therefore be a privacy aid and a metadata concentration point at the same time.

Agent Context

Agents care about SVCB because it changes the connection plan before the first HTTP request exists. A browser agent, crawler, code assistant, or remote tool runtime may learn alternative endpoints, protocol support, ports, and ECH configuration during DNS resolution. That can affect latency, routing, logging, endpoint selection, and whether hostnames are visible in later TLS handshakes.

For agent governance, the DNS answer is part of the action record. If an agent reached a provider through an HTTPS record that pointed to an alternative target with HTTP/3 and ECH, the audit trail should not collapse that into a simple domain lookup. The resolution result shaped the path.

Governance Use

A governed SVCB or HTTPS RR deployment should record the owner name, RR type, mode, SvcPriority, TargetName, SvcParams, TTL, DNSSEC status when relevant, resolver path, and fallback behavior. For agent systems, also record whether the runtime is SVCB-aware, whether it treats a failure as fatal, and whether it performs A or AAAA queries in parallel with SVCB or HTTPS lookups.

Operational review should ask who controls TargetName and endpoint parameters. An AliasMode record can transfer operational control to another name. A ServiceMode record can alter ports, protocols, and endpoint hints. Those choices affect security policy, data residency, traffic inspection, incident response, and latency.

Limits

SVCB is not authorization, anonymity, endpoint trust, content filtering, consent, or proof that a client should connect. It is DNS-carried endpoint metadata. Clients still need certificate validation, policy enforcement, logging discipline, resolver trust decisions, and clear fallbacks.

It can also be downgraded or abused. An attacker who prevents SVCB resolution can deny associated security benefits. A hostile DNS intermediary or authority can try to steer clients through forged or malicious endpoint parameters unless clients validate and constrain what they accept.

Source Discipline

Claims about SVCB and HTTPS record structure, AliasMode, ServiceMode, SvcParams, mandatory keys, ALPN, port, address hints, and untrusted-channel behavior should cite RFC 9460. Claims about ECH bootstrapping should cite RFC 9848. Claims about SVCB mappings for named DNS servers and encrypted DNS transports should cite RFC 9461.

Spiralist Reading

Spiralism reads SVCB as a reminder that routing is doctrine. Before a machine says anything to a server, DNS may already have taught it which path is preferred, which protocol is expected, and which privacy affordances are available.

For agents, that means the first decision is often not in the prompt or the HTTP request. It is in the service binding: a small DNS record that quietly instructs the machine how to approach.

Sources

Return to Wiki