HTTPS and SVCB Records Explained: Faster Connections and Encrypted SNI

SVCB and HTTPS resource records let a client learn how to connect to a service before it opens a single connection. Instead of doing an A or AAAA lookup, connecting, and only then negotiating the protocol, a client can read one DNS record that already names the supported protocols, an alternative port, address hints, and the public key needed to encrypt the TLS handshake. The result is fewer round trips, cleaner HTTP/3 discovery, and the foundation for hiding the server name you are visiting. Both record types are standardized in RFC 9460, published in November 2023.

What SVCB and HTTPS records are

These are two closely related resource record types defined by the same specification:

• SVCB (type 64) is the general-purpose Service Binding record. It works for any protocol that opts in, such as DNS-over-HTTPS.
• HTTPS (type 65) is a specialization of SVCB for the HTTP and HTTPS scheme. Because it is scheme-specific, a browser knows to query it automatically for any https:// origin without extra configuration.

The two records share an identical format and parameter set. HTTPS is simply the one web browsers query on their own, so most site owners spend their time on the HTTPS record. A useful mental model: an HTTPS record is a modern, extensible replacement for the old trick of stuffing connection hints into A records and CNAMEs, and it can legally sit at a zone apex where a CNAME cannot.

Two modes: AliasMode and ServiceMode

The first field of the record is a 16-bit priority number, and its value decides the mode.

• AliasMode is signaled by priority 0. It points the name at another target, similar to a CNAME, but it is legal at the apex of a zone. This lets you alias example.com itself to a provider hostname, which classic CNAME rules forbid.
• ServiceMode is signaled by any priority of 1 or higher. This is the form that carries the connection parameters (protocols, port, address hints, and the encryption key).

Within one record set you should keep every record in the same mode. If a set contains an AliasMode record, resolvers must ignore any ServiceMode records mixed in with it. When you publish several ServiceMode records, the lower priority number is preferred, exactly like MX records, and records at equal priority are treated as equivalent alternatives.

The record syntax: priority, target, and parameters

The presentation format used in a zone file is straightforward:

<owner> <TTL> IN HTTPS <priority> <target> <key=value params>

The target is a hostname, and a single dot . means "use the owner name itself as the endpoint." A minimal, common ServiceMode record for an apex looks like this:

example.com.   3600  IN  HTTPS  1 . alpn="h2,h3" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

An AliasMode record that redirects the apex to a provider looks like this:

example.com.   3600  IN  HTTPS  0 svc.provider.example.

You can also point a subdomain at a different endpoint and advertise a non-standard port:

www.example.com.  3600  IN  HTTPS  1 svc.example.net. alpn="h2" port=8443

The SvcParams you will actually use

Parameters are written as space-separated key=value pairs. RFC 9460 defines the core set:

• alpn lists the Application-Layer Protocol Negotiation identifiers the endpoint supports, such as h2 for HTTP/2 and h3 for HTTP/3. Advertising h3 here is the cleanest way to tell a browser it can go straight to HTTP/3 without waiting for an Alt-Svc header. This is by far the most used parameter in the wild.
• no-default-alpn removes the protocol a client would otherwise assume by default. Use it only when you truly do not support the default.
• port overrides the default port for the scheme, useful for services that do not listen on 443.
• ipv4hint and ipv6hint carry one or more IP addresses so a client can start connecting without a separate A or AAAA lookup. They are hints, not authoritative address records, and a client may still resolve A or AAAA for the target.
• ech carries the ECHConfigList, the base64 public key material that makes Encrypted Client Hello possible.
• mandatory lists parameters a client must understand or it should ignore the whole record. Use it sparingly, since it can make a record invisible to clients that lack a given feature.

Note that the ech key is registered alongside the other SvcParamKeys in RFC 9460, but its value format is defined by the separate Encrypted Client Hello specification, so treat its exact contents as coming from your TLS provider rather than something you hand-craft.

How ECH uses the record to hide the SNI

In a normal TLS 1.3 handshake the Server Name Indication (SNI) travels in plaintext inside the ClientHello. Anyone on the path can read which hostname you are requesting even though the rest of the session is encrypted. Encrypted Client Hello (ECH) closes that gap by encrypting the inner ClientHello, including the SNI and the ALPN list, to a public key the server publishes ahead of time.

DNS is where that public key lives. The server publishes an ech value in its HTTPS or SVCB record. A client fetches the record, encrypts its true ClientHello to that key, and wraps it in an outer ClientHello that names a shared, non-sensitive front. Two conditions matter for this to actually protect anything:

• The DNS lookup that retrieves the ech value must itself be encrypted, using DNS-over-HTTPS or DNS-over-TLS. If the record is fetched in cleartext, an observer simply reads the target name from the query instead.
• Both the client and the origin (or the CDN in front of it) must support ECH. ECH is defined by an IETF draft that is still evolving, not a finalized RFC, so support and configuration formats can change.

Firefox supports ECH when a DoH resolver is configured, and other major browsers have shipped or experimented with it. Because the specification is still a draft, treat ECH as a real but maturing feature and let your CDN or TLS provider generate and rotate the ech value for you.

Publishing at the apex and on subdomains

Publishing an HTTPS record is the same process as any other record in Valla DNS or a comparable manager: choose the name, set the type to HTTPS (or SVCB for non-HTTP services), and enter the priority, target, and parameters. A few practical rules:

• At the apex, prefer a ServiceMode record with target . alongside your existing A and AAAA records, or use an AliasMode record if you need CNAME-like behavior at the root.
• On a subdomain like www, you can use ServiceMode to advertise HTTP/3 and address hints without disturbing your A record.
• Keep the TTL modest, for example 3600 seconds, so you can adjust ALPN or ECH values without a long wait. Lower it to 300 before a planned change.
• Do not let the HTTPS record contradict your A and AAAA records. The address hints should point at the same service.

Verifying with dig

Recent versions of dig understand these types by name. Query the HTTPS record directly:

dig example.com HTTPS

A healthy answer section looks like this:

;; ANSWER SECTION:
example.com.  3600  IN  HTTPS  1 . alpn="h2,h3" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

For a compact view, add +short:

dig example.com HTTPS +short
1 . alpn="h2,h3" ipv4hint=192.0.2.1

On an older resolver that does not know the mnemonic, query by numeric type instead:

dig example.com TYPE65

Always confirm the change at your authoritative nameserver first, then compare against a public resolver such as 1.1.1.1 or 8.8.8.8 to gauge how far the record has propagated.

Support and caveats to set expectations

• Browser support is good but not universal. Modern Chrome, Firefox, and Safari query HTTPS records. Older clients ignore them and fall back to A and AAAA, so the record should be additive, never a replacement for your address records.
• ECH is still a draft. It works today on cooperating CDNs and browsers, but the specification and formats can shift. Rely on your provider to manage the key.
• Not every DNS host supports these types yet. Confirm your manager can store type 64 and 65 records before you plan around them.
• Address hints are hints. They speed up the first connection but do not replace correct A and AAAA records.

Frequently asked questions

Do I need an HTTPS record for my site to work?

No. Sites work fine with only A and AAAA records. An HTTPS record is a performance and privacy enhancement that lets capable clients connect faster and, with ECH, hide the server name.

What is the difference between SVCB and HTTPS records?

They share one format. HTTPS (type 65) is the HTTP-specific version browsers query automatically, while SVCB (type 64) is the general form for other protocols that opt in.

Can I put an HTTPS record at my domain apex?

Yes. Unlike a CNAME, an HTTPS record is allowed at the apex, in either AliasMode (priority 0) or ServiceMode (priority 1 or higher).

Does ECH work without encrypted DNS?

Not meaningfully. If the DNS lookup that fetches the ech value is unencrypted, an on-path observer can still read the requested name. ECH depends on DNS-over-HTTPS or DNS-over-TLS to deliver its benefit.

How do I check my HTTPS record?

Run dig yourdomain.com HTTPS (or dig yourdomain.com TYPE65 on older tools) against your nameserver, then against a public resolver to confirm propagation.

SVCB and HTTPS records are the current, standardized way to hand clients everything they need to connect quickly and, increasingly, privately. If you want to publish, edit, and verify HTTPS records, ALPN and address hints, and provider-managed ECH values from one place, you can manage all of it with Valla DNS.