What Are HTTPS and SVCB Records in DNS?

For most of the web's history, DNS gave a browser exactly one piece of information about a website: its IP address. Everything else, such as whether the server speaks HTTP/3, whether it requires HTTPS, or which TLS settings it supports, had to be discovered after connecting, often through extra round trips, redirects or a second connection. The HTTPS and SVCB record types change that. They let you publish connection details in DNS so clients can make the right choice from the very first packet. They also offer a standards-based way to alias a root domain and are the delivery mechanism for Encrypted ClientHello. This article explains what the two record types are, how to read and write them, which parameters matter, and how well they are supported today. If you need a refresher on record types in general, start with What Are DNS Records?

What Are SVCB and HTTPS Records?

SVCB (Service Binding, type 64) is a general-purpose record that describes how to connect to a service: which host to use, which port, which application protocols, and other parameters. HTTPS (type 65) is SVCB specialised for the web. It has the same format but is looked up at the website's own hostname, such as example.com, and its parameters are interpreted for HTTPS.

Both are defined in RFC 9460, published in November 2023. The idea is that a client can ask for the HTTPS record at the same time as the A and AAAA records and, by the time the address arrives, also know how best to talk to the server.

Record	Type code	Typical owner name	Used for
SVCB	64	_service._proto style, e.g. _dns.resolver.example	Any protocol that defines an SVCB mapping
HTTPS	65	The site hostname, e.g. example.com	Web browsers and HTTP clients

SVCB is the foundation. Other protocols can define their own SVCB usage; for example, RFC 9461 defines how DNS resolvers advertise DNS over HTTPS and DNS over TLS endpoints with SVCB, which is the basis of encrypted resolver discovery.

Record Format

Both record types share one wire and presentation format:

owner  TTL  IN  HTTPS  SvcPriority  TargetName  SvcParams...

• SvcPriority decides the record's mode. 0 means AliasMode. Any value of 1 or higher means ServiceMode, and lower numbers are preferred, like MX priorities.
• TargetName is the host the client should actually connect to. A single dot (.) in ServiceMode means "the owner name itself."
• SvcParams are key-value pairs describing the service. They are only allowed in ServiceMode.

ServiceMode example

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

This says: "connect to example.com itself, it supports HTTP/3 and HTTP/2, and here are its addresses as a hint." A browser seeing this can try HTTP/3 over QUIC immediately rather than starting with HTTP/2 over TCP and waiting for an Alt-Svc header.

AliasMode example

example.com.  3600  IN  HTTPS  0 myapp.example-cdn.net.

This says: "for HTTPS service at example.com, look up the HTTPS records of myapp.example-cdn.net instead." Unlike a CNAME, AliasMode only affects HTTPS lookups. It does not stop example.com from having SOA, NS, MX and TXT records, so it is legal at the zone apex. That makes it a standards-based answer to the problem described in Can You Use a CNAME Record on the Root Domain? The catch, as we will see, is client support.

Multiple endpoints

You can publish several ServiceMode records with different priorities, for example to prefer a CDN and fall back to an origin:

example.com.  300  IN  HTTPS  1 edge.example-cdn.net. alpn="h3,h2"
example.com.  300  IN  HTTPS  2 origin.example.com.   alpn="h2" port=8443

The client tries edge.example-cdn.net first, and if it cannot connect, falls back to origin.example.com on port 8443 using HTTP/2.

The SvcParams You Will Actually Use

RFC 9460 defines these keys, and others can be registered with IANA:

Key	Meaning
alpn	Application protocols supported, such as h3, h2, http/1.1
no-default-alpn	Do not assume the protocol's default ALPN (for HTTPS, http/1.1) is supported
port	Port to connect on, if not the default 443
ipv4hint	IPv4 addresses the client may use before A records arrive
ipv6hint	IPv6 addresses the client may use before AAAA records arrive
ech	Encrypted ClientHello configuration, base64-encoded
mandatory	Keys the client must understand to use this record

A few practical notes:

1. alpn drives HTTP/3 adoption. Advertising h3 lets browsers attempt QUIC on the first connection.
2. Hints are hints. Clients should still prefer real A and AAAA records when they have them. If your hints go stale, clients may try a wrong IP first. Keep them in sync with your AAAA records and A records, or leave them out.
3. ech carries the public key clients use to encrypt the TLS ClientHello, hiding the server name from network observers. Your CDN or TLS server generates this value; you should not hand-write it.
4. mandatory protects against old clients misusing a record whose parameters they do not understand.

A Side Effect: HTTPS Upgrades

If a client finds an HTTPS record for a hostname, RFC 9460 says it should treat any http:// URL for that name as https://. That is similar to HSTS: the existence of the record signals the site supports HTTPS. Do not publish an HTTPS record unless your site serves valid TLS on the advertised endpoints.

How to Look Up HTTPS and SVCB Records

Recent versions of dig (BIND 9.18 and later) understand the types by name:

dig example.com HTTPS +noall +answer

example.com.   300   IN   HTTPS   1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10

Older versions that do not recognise the type name can still query it by number:

dig example.com TYPE65 +noall +answer

The answer will be shown in a generic hexadecimal format, but its presence tells you a record exists. For SVCB, use SVCB or TYPE64. For more on dig syntax, see How to Use the dig Command for DNS Lookups.

In Python, dnspython 2.1 and later parses the record fully:

import dns.resolver
import dns.rdtypes.svcbbase

answer = dns.resolver.resolve("example.com", "HTTPS")
for rdata in answer:
    mode = "AliasMode" if rdata.priority == 0 else "ServiceMode"
    print(f"{mode} priority={rdata.priority} target={rdata.target}")
    for key, value in rdata.params.items():
        print(f"  {dns.rdtypes.svcbbase.key_to_text(key)} = {value.to_text()}")

This resolves the HTTPS record, prints its mode, priority and target, and lists each parameter with its value. A domain with no record raises dns.resolver.NoAnswer.

Publishing HTTPS Records

How you publish depends on where your DNS lives.

On a CDN that manages them

Some CDNs generate HTTPS records automatically. Cloudflare, for example, publishes HTTPS records for proxied hostnames, with alpn reflecting whether HTTP/3 is enabled and, when ECH is active, an ech parameter. In that case you do not need to do anything, and adding your own may conflict. If you use Cloudflare, see How to Set Up Cloudflare DNS for Your Website.

In a managed DNS dashboard

Many managed DNS providers now list HTTPS and SVCB in their record type menus. You typically fill in priority, target and a parameters string. Check that your provider validates the parameter syntax, because a malformed record may be ignored by clients.

In a BIND zone file

$ORIGIN example.com.
$TTL 3600
@     IN  A      203.0.113.10
@     IN  AAAA   2001:db8::10
@     IN  HTTPS  1 . alpn="h3,h2"
www   IN  HTTPS  1 . alpn="h3,h2"
www   IN  A      203.0.113.10
www   IN  AAAA   2001:db8::10

This publishes ServiceMode records for both the apex and www advertising HTTP/3 and HTTP/2, without address hints, so clients rely on the normal A and AAAA records. Validate before loading:

named-checkzone example.com /etc/bind/db.example.com

named-checkzone will reject malformed SvcParams before they reach production.

Non-default ports

For a service on a non-standard port, HTTPS records live at a prefixed name: a site at https://example.com:8443 is looked up at _8443._https.example.com.

_8443._https.example.com.  3600  IN  HTTPS  1 . alpn="h2"

Browser and Client Support

Support has grown steadily but is still uneven, so treat HTTPS records as an enhancement on top of A and AAAA records, never a replacement.

1. Apple platforms query HTTPS records in the system resolver and use them in Safari and other apps.
2. Chrome and Firefox use HTTPS records, notably to discover HTTP/3 support and ECH configurations. Some behaviour depends on whether the browser is using its built-in secure DNS, as described in What Is DNS over HTTPS?
3. AliasMode at the apex is the least consistently supported part of the specification. Do not rely on it alone to make your root domain reachable; keep A and AAAA records, an ALIAS, or flattening in place as well. Those options are compared in What Is an ALIAS or ANAME Record?
4. Command-line tools and libraries such as curl and most HTTP client libraries generally do not use HTTPS records yet unless built with specific options.

Common Mistakes

1. Advertising h3 without working QUIC. Clients will try UDP 443 first and waste time falling back. Make sure your firewall allows UDP 443 and your server actually speaks HTTP/3.
2. Stale address hints. If you change IPs and forget the ipv4hint and ipv6hint values, some clients will try the old addresses first.
3. Hand-editing ech values. ECH keys rotate. Let the software that manages them publish the record.
4. Publishing for a site without valid HTTPS. The record implies HTTPS support and triggers upgrades.
5. Mixing AliasMode and ServiceMode at the same name. If an AliasMode record exists, ServiceMode records at that name should not.

---

HTTPS and SVCB Records FAQ

Conclusion

HTTPS and SVCB records move connection setup information into DNS, where clients can get it alongside the IP address. That lets browsers start with HTTP/3, pick up ECH keys for better privacy, find alternative endpoints and ports, and, in time, alias root domains without breaking the rules that apply to CNAMEs. They are standardised in RFC 9460 and increasingly published automatically by CDNs.

For most site owners, the right approach is to let your CDN or DNS provider publish them if it can, and to treat them as an addition to your existing A and AAAA records rather than a substitute. If you publish them yourself, keep them simple, advertise only protocols you actually serve, and validate the syntax before going live.

Here are some useful references for going deeper on HTTPS and SVCB records:

1. RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) — the specification defining both record types and their parameters.
2. RFC 9461: Service Binding Mapping for DNS Servers — how SVCB advertises encrypted DNS endpoints.
3. RFC 9114: HTTP/3 — the protocol most commonly advertised through the alpn parameter.
4. Cloudflare Docs: DNS documentation — includes how Cloudflare manages HTTPS records for proxied hostnames.
5. BIND 9 Documentation: BIND 9 Administrator Reference Manual — zone-file syntax and validation tools that support SVCB and HTTPS.