SVCB and HTTPS Records Explained: What DNS Type 65 Tells a Browser

Type a hostname into a browser and something happens before a single packet reaches the server. The browser asks DNS a question that has nothing to do with addresses: which protocols does this host speak, on which port, are there addresses worth trying straight away, and does it publish a key for concealing the name being requested?

The answer arrives in a record type most people have never looked at. It is HTTPS, DNS type 65, along with its general-purpose sibling SVCB, type 64. Both are defined in RFC 9460, published in November 2023, and both exist to move information out of the connection attempt and into the lookup that comes first.

The lookup that happens before the connection#

Without these records, a browser discovers a server's capabilities by trying things. It looks up an address, opens a TCP connection, negotiates TLS, and only when the first response arrives does it learn from an Alt-Svc header that the server would have preferred HTTP/3 elsewhere. The good connection is the second one. Everything before it was the cost of finding out.

RFC 9460 turns that around. It says that before making a request with the https scheme, a client should look up the HTTPS record for the name. Browsers now send that query alongside the ordinary A and AAAA queries rather than after them, so the capability answer and the address answer arrive together. Safari has been asking for type 65 since late 2020, and Chromium-based browsers rolled support out over the Chrome 96 era. Firefox has the support too, tied to having DNS over HTTPS switched on.

This is also why these records tend to be invisible. Our general DNS records lookup queries the seven types people ask for by name (A, AAAA, MX, NS, TXT, CNAME and SOA) and type 65 is not among them, which is exactly why the SVCB and HTTPS record lookup is a separate tool. A record your browser reads on every visit is one you will never see in a lookup that does not ask for it.

Two record types, one format#

SVCB is the generic form, usable by any service that defines a mapping for it, which by now includes DNS resolvers and Oblivious HTTP services. HTTPS is the web-specific form, and the one browsers query automatically. The two share a wire format and a parameter registry, and differ mainly in who is expected to ask for them.

That split matters when you are checking a zone rather than serving it. A domain might publish type 65 and nothing else, or type 64 for a non-web service, and a check that queries only one of them reports the wrong answer with total confidence. It is the same trap as concluding a record type you never asked about does not exist.

A record in presentation format looks like this:

1 . alpn="h3,h2" ipv4hint=104.16.132.229 ech=AEX+DQBB...

Three parts: a priority, a target, and then any number of key=value parameters. Everything interesting is in the third part, but the first two decide whether the third is read at all.

Reading a record left to right#

The priority selects the mode. A priority of 0 puts the record in AliasMode: it does not describe an endpoint, it points at another name. Any other value puts it in ServiceMode, where the record describes a usable endpoint and its parameters apply. Among several ServiceMode records, a smaller number is the one the domain owner recommends, in the same direction as MX preference. Lower wins.

The target names the endpoint. A hostname here means the service lives at that name. A bare . is the single easiest part to misread, because it means opposite things in the two modes. In ServiceMode, a target of . means the record's own owner name is the endpoint, which is the normal case for a site publishing its own capabilities. In AliasMode, a target of . means the service is not available at this name at all.

The parameters describe the endpoint. They are unordered, and a client that meets a key it does not recognise normally ignores it and carries on. Normally, but not always, which is what mandatory exists to change.

The parameters, and what each one changes#

Parameter keys live in an IANA registry, each with a number and a name. RFC 9460 registered the first set and reserved key 5 for Encrypted Client Hello, which a later specification filled in. These are the ones you will meet in a web zone:

Registered SvcParamKeys 0–8. The registry continues past 8 with keys for specialised transports; nothing a browser needs.

alpn is the one that changes the most for the least effort. The values are TLS application-layer protocol identifiers, so h3 is HTTP/3 and h2 is HTTP/2. Publishing alpn=h3,h2 lets a browser open an HTTP/3 connection on its first attempt rather than discovering the option after an earlier round trip. For the https scheme, the default protocol set when no alpn is given is just http/1.1, and no-default-alpn is how a server says even that is not on offer.

port is worth a note because it is the only parameter that redirects the connection itself. Without it, clients use the scheme's default, which for https is port 443. A record carrying port=8443 sends clients somewhere other than where they would otherwise have gone.

AliasMode and the apex problem#

Anyone who has put a site behind a CDN has run into this. A CNAME record cannot coexist with other records at the same name, and a zone apex necessarily carries SOA and NS records, so example.com cannot be a CNAME to a provider's hostname while www.example.com can. The workarounds have been provider-specific: flattened CNAMEs, ALIAS records, ANAME records, each one a nonstandard behaviour implemented inside a nameserver.

AliasMode is the standardised version of that. RFC 9460 states plainly that its primary purpose is to allow aliasing at the zone apex, where CNAME is not allowed. A priority of 0 and a target of the provider's hostname delegates the apex in a record type resolvers and browsers understand, rather than one vendor's clever trick. It sits alongside SOA and NS without conflict, which is the whole point, and it explains a good deal of the CDN plumbing you may have configured by hand. One rule comes with it: an AliasMode record carries no parameters, and clients are required to ignore any that appear.

Address hints are only hints#

ipv4hint and ipv6hint look like they replace A and AAAA lookups. They do not, and the specification is unusually direct about it. The hints exist to save a round trip when a recursive resolver does not return the address records alongside the answer. A client should still query A and AAAA for the target name, and if it already has those answers to hand it should ignore the hints entirely.

They also carry no authority. If connections to a hinted address fail, a client may drop them and switch to the addresses the real query returned. Treat the hints as a latency optimisation, not as a second place to record where your service lives. The hints expire on the HTTPS record's own TTL rather than the A record's, so after a migration the two can fall out of step in caches in ways that are irritating to reproduce.

What Encrypted Client Hello hides#

The ech parameter carries a base64-encoded ECHConfigList, the server's public configuration for Encrypted ClientHello. RFC 9460 reserved the key; RFC 9848, published in March 2026, defines how that configuration is bootstrapped through these records.

The problem it addresses is a gap in TLS. Even on a fully encrypted connection, the Server Name Indication in the opening handshake message travels in the clear, so anyone on the path can see which hostname you asked for, if not what you did there. That holds in TLS 1.3 as much as in the version before it. ECH encrypts that inner handshake using the key published in DNS, which is why the key has to reach the client before the handshake begins, and why a DNS record is where it lives.

Two limits are worth stating, because ECH gets described as anonymity more often than it deserves. The specification itself notes that an observer may still infer the server from traffic analysis or from the DNS queries themselves, so a plaintext lookup for the same name gives back much of what was gained, which is the argument for pairing it with encrypted DNS transport. And ECH hides the name from the network, not from the server, and not from anything with a view of the destination address.

When a client cannot use the record#

The mandatory key names other keys in the same record that are critical to using it correctly. If a client meets a mandatory key it does not understand, it must not guess: it ignores the entire record set and falls back to ordinary connection establishment. That makes mandatory a safety catch and a foot-gun in one. Listing a key the record does not actually set renders it unusable rather than merely odd.

Similarly, when no-default-alpn is set and a client supports none of the listed protocols, it should not attempt that endpoint at all. There is nothing there it can speak.

One more thing decides how much any of this is worth: DNSSEC signing and validation are optional for SVCB and HTTPS records. An unsigned record advertising an ECH key or an address hint is only as trustworthy as the resolution path that delivered it, so if these records carry security-relevant configuration, check that the zone is signed. Our post on how DNS gets a chain of trust covers what signing does and does not promise.

Checking what a domain publishes#

From a terminal, dig HTTPS example.com and dig SVCB example.com return the raw presentation strings, which you then read by hand. Our SVCB and HTTPS record lookup runs both queries in one go, over DNS-over-HTTPS, and does the reading for you. It leads with the three findings that change what a browser does (whether HTTP/3 is advertised, whether an ECH configuration is published, and how many address hints are present), then breaks each record into priority, mode, target and parameters with a note on what each key means. The parsing runs in your browser rather than on our servers.

It also flags the authoring mistakes above: an AliasMode record carrying parameters, a mandatory list naming a key that is not set, a flag key given a value. And it separates NXDOMAIN from an empty answer. A name that does not exist and a name that exists but publishes nothing of this type are different problems with different fixes.

These records are quietly becoming load-bearing. They are how a browser learns about HTTP/3 without a wasted round trip, how a zone apex finally aliases like every other name, and how the key that hides your hostname in the handshake reaches a client. Worth knowing what yours say.