What are HTTPS and SVCB DNS records?

HTTPS and SVCB records are DNS record types, defined in RFC 9460, that tell a client how to connect to a service, not just where it is. An SVCB (Service Binding) record can say which protocols a server supports, such as HTTP/3, which port to use, which IP addresses to try, and which keys to use for Encrypted Client Hello. The HTTPS record is the same format specialised for websites. When a browser looks up your site, it can fetch the HTTPS record alongside the A and AAAA records and start the best possible connection straight away, instead of discovering those details over several round trips.

These records also solve a long-standing DNS problem by allowing an alias at the root of a domain in a standard way. In this article you'll learn why HTTPS and SVCB records were created, how their two modes work, what each parameter means, how to write them in a zone file, how browsers and resolvers use them today, how to query them, and what to watch out for when publishing your own.

Why HTTPS and SVCB Records Exist

Before these records, a browser visiting example.com knew almost nothing about the server until it connected. That caused a few problems:

• HTTP/3 discovery was slow: A server could only advertise HTTP/3 through an Alt-Svc header on an existing HTTP/1.1 or HTTP/2 connection, so the first visit couldn't use it.
• Plain HTTP came first: Typing example.com without https:// often started with an unencrypted request that was then redirected, unless the site was on the HSTS preload list.
• No standard apex alias: You couldn't put a CNAME at the zone apex, which pushed providers into proprietary workarounds such as ALIAS records and CNAME flattening.
• Encrypted Client Hello needed a key: To encrypt the server name in the TLS handshake, the client needs the server's ECH configuration before it connects. DNS is the natural place to publish it.

SVCB is a general record for any service, and HTTPS is the version for https:// URLs, so browsers only need to query one well-known type.

The Two Modes: AliasMode and ServiceMode

Every HTTPS or SVCB record starts with a priority number, which decides its mode.

AliasMode (Priority 0)

A priority of 0 means AliasMode. The record simply says "look up this other name instead", much like a CNAME, but only for clients that understand HTTPS records:

example.com.    3600    IN    HTTPS    0 site.cdn.example.net.

Unlike a CNAME, an AliasMode record can sit at the zone apex next to SOA, NS, MX and TXT records, because it only affects HTTPS lookups. Clients that support it follow the alias to site.cdn.example.net and use that name's HTTPS, A and AAAA records.

Clients that don't understand HTTPS records ignore it completely, so you still need A and AAAA records at the apex for them.

ServiceMode (Priority 1 or Higher)

A priority of 1 or more means ServiceMode. The record describes an actual endpoint and its connection parameters:

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

• 1: The priority. When there are several ServiceMode records, clients prefer the lowest number.
• .: The target name. A single dot means "the same name as the record", here example.com itself.
• alpn="h3,h2": The server supports HTTP/3 and HTTP/2.
• ipv4hint / ipv6hint: Addresses the client can start connecting to before its A and AAAA lookups finish.

You can publish multiple ServiceMode records to describe alternative endpoints in order of preference:

example.com.  3600  IN  HTTPS  1 . alpn="h3,h2"
example.com.  3600  IN  HTTPS  2 backup.example.net. alpn=h2

The SvcParams Explained

The key-value pairs after the target are called SvcParams. RFC 9460 defines these:

Parameter	Example	What it does
alpn	alpn="h3,h2"	Application protocols the endpoint supports, such as h3, h2 and http/1.1
no-default-alpn	no-default-alpn	The protocol's default ALPN (HTTP/1.1 for HTTPS records) is not supported
port	port=8443	Connect on this port instead of the default
ipv4hint	ipv4hint=192.0.2.10	IPv4 addresses the client may use while waiting for A records
ipv6hint	ipv6hint=2001:db8::10	IPv6 addresses the client may use while waiting for AAAA records
ech	ech="AEX+DQBB..."	The Encrypted Client Hello configuration, base64-encoded
mandatory	mandatory=alpn	Keys the client must understand, or it should skip this record

A few details are worth knowing:

• HTTP/1.1 is assumed for HTTPS records unless no-default-alpn is present, so alpn="h2" means "HTTP/2 and HTTP/1.1".
• Hints are only hints. If the name has A and AAAA records, clients should use those once they arrive. Keep hints in sync with your address records, or leave them out.
• The ech value is generated by your TLS stack or CDN. You don't write it by hand, and it must be rotated when the server's ECH keys change.

The RFC 9461 extension adds a dohpath parameter for DNS-over-HTTPS servers, used with SVCB records, which you'll see later in this article.

How Browsers Use HTTPS Records

When a browser that supports HTTPS records opens example.com, it sends three queries in parallel: A, AAAA and HTTPS. With the ServiceMode record from earlier, the browser learns:

1. The site supports HTTPS: The mere existence of an HTTPS record tells clients to use https://, even if the user typed http://. This gives a similar effect to HSTS on the very first visit.
2. HTTP/3 is available: The browser can try QUIC immediately rather than waiting for an Alt-Svc header.
3. Where to connect: It can use the IP hints to start connecting early.
4. How to encrypt the handshake: If an ech parameter is present, it can encrypt the server name it's asking for.

Safari on Apple platforms, Chrome and Firefox all support HTTPS records, though the details differ. Some browsers only query them when using their built-in encrypted DNS, and support for ECH in particular has rolled out gradually. Because an HTTPS record is always an optional improvement, clients that don't use it simply fall back to normal A and AAAA lookups.

Writing HTTPS Records in a Zone File

A Simple Site With HTTP/3

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

www   3600  IN  CNAME  example.com.

A CNAME at www is followed for HTTPS queries as usual, so www picks up the apex's HTTPS record. Only add h3 if your server or CDN really serves HTTP/3 on UDP port 443.

An Apex Alias to a CDN

$ORIGIN example.com.
@     3600  IN  HTTPS  0 site.cdn.example.net.
@     300   IN  A      203.0.113.20
@     300   IN  AAAA   2001:db8:20::20
@     3600  IN  MX     10 mx1.example.com.

Supporting browsers follow the AliasMode record to the CDN's name. Everything else uses the A and AAAA records, which you keep in line with the CDN's documented apex addresses.

A Service on a Non-Standard Port

For an https:// URL with an explicit port, the HTTPS record lives at a special prefixed name: _<port>._https.<host>.

_8443._https.api.example.com.  3600  IN  HTTPS  1 api-backend.example.net. alpn=h2

A client opening https://api.example.com:8443/ looks this up. You can also use the port parameter to send default-port traffic to a different port:

api.example.com.  3600  IN  HTTPS  1 . alpn=h2 port=8443

Checking Your Syntax

BIND's named-checkzone understands HTTPS and SVCB records in current releases. If you prefer Python, dnspython can parse a zone file and show you how each record is interpreted:

import sys

import dns.zone
from dns.rdtypes.svcbbase import ParamKey

zone = dns.zone.from_file(sys.argv[1], origin=sys.argv[2])

for name, rdataset in zone.iterate_rdatasets():
    if rdataset.rdtype not in (dns.rdatatype.HTTPS, dns.rdatatype.SVCB):
        continue
    for rdata in rdataset:
        mode = "AliasMode" if rdata.priority == 0 else "ServiceMode"
        print(f"{name}  {dns.rdatatype.to_text(rdataset.rdtype)}  "
              f"priority={rdata.priority} ({mode})  target={rdata.target}")
        for key, value in rdata.params.items():
            print(f"    {ParamKey.to_text(key).lower()} = {value.to_text()}")

pip install dnspython
python check_svcb.py db.example.com example.com.

@  HTTPS  priority=1 (ServiceMode)  target=.
    alpn = "h3,h2"
    ipv4hint = "192.0.2.10"
    ipv6hint = "2001:db8::10"

A syntax error, such as an unknown parameter name or a malformed address, raises an exception that points at the offending line.

SVCB for Other Services

The SVCB record is the general-purpose version. Protocols opt in by defining how their names and parameters work. The most visible use today is discovering encrypted DNS resolvers.

RFC 9461 defines SVCB records for DNS servers, published at _dns.<resolver name>, which advertise DNS over HTTPS, DNS over TLS or DNS over QUIC:

_dns.dns.example.com.  3600  IN  SVCB  1 dns.example.com. alpn=h2 dohpath=/dns-query{?dns}
_dns.dns.example.com.  3600  IN  SVCB  2 dns.example.com. alpn=dot port=853

RFC 9462, Discovery of Designated Resolvers (DDR), builds on this. A device that has been given a resolver's IP address, for example through DHCP, can ask that resolver for the special name _dns.resolver.arpa to find out whether it also offers an encrypted endpoint. You can try it against Cloudflare's public resolver with Python:

import dns.resolver

resolver = dns.resolver.Resolver(configure=False)
resolver.nameservers = ["1.1.1.1"]
for rdata in resolver.resolve("_dns.resolver.arpa", "SVCB"):
    print(rdata)

1 one.one.one.one. alpn="h2,h3" port="443" ipv4hint="1.1.1.1,1.0.0.1" ipv6hint="2606:4700:4700::1111,2606:4700:4700::1001" dohpath="/dns-query{?dns}"
2 one.one.one.one. alpn="dot" port="853" ipv4hint="1.1.1.1,1.0.0.1" ipv6hint="2606:4700:4700::1111,2606:4700:4700::1001"

The answer says the resolver supports DoH over HTTP/2 and HTTP/3 at /dns-query, and DoT on port 853. Operating systems that support DDR, including recent versions of Windows and Apple's platforms, can use this to upgrade to encrypted DNS automatically.

Querying HTTPS and SVCB Records

With dig

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

dig example.com HTTPS +noall +answer

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

Older versions, such as the dig 9.10 that still ships with macOS, don't recognise the HTTPS keyword. They treat it as part of the name and quietly look up an A record instead. Use the numeric type to get the raw data:

dig example.com TYPE65 +short

\# 41 0001000001000602683302683200040004C000020A000600102001 0DB8000000000000000000000010

That hexadecimal output is the record in wire format. Install a current BIND or Knot DNS toolset, for example with brew install bind or brew install knot, to see it decoded.

With kdig

Knot's kdig supports both types as well:

kdig example.com HTTPS +short

Checking From the Browser

In Chrome, you can see how the browser resolved a host, including HTTPS records, at chrome://net-internals/#dns. In Firefox, about:networking#dns shows the DNS cache. These pages change between versions, but they're useful for confirming that a browser actually picked up your record.

Publishing HTTPS Records Safely

If You Use a CDN

Many CDNs publish HTTPS records for you. Cloudflare, for example, automatically serves HTTPS records for proxied hostnames, including alpn values, IP hints, and ECH keys where enabled. In that case, don't add your own records for the same names, as they'd conflict with what the CDN generates.

If You Publish Them Yourself

1. Only advertise what works: Listing h3 when UDP 443 is blocked by a firewall makes browsers try QUIC first and fall back, which slows things down.
2. Keep hints in sync: If you change your A or AAAA records, update or remove the hints at the same time.
3. Remember the HTTPS upgrade: Publishing any HTTPS record tells supporting clients to use https://. Make sure TLS works on every name that has one.
4. Use short TTLs at first: Start with a TTL of a few minutes so you can correct mistakes quickly, then raise it once you're confident.
5. Don't hand-write ECH keys: Let your server software or CDN publish and rotate them, because a stale ECH configuration can cause connection failures until clients retry.
6. Check your DNS provider supports the types: Some providers still don't offer HTTPS or SVCB in their dashboard or API. If yours doesn't, you can't publish them there.

---

FAQ: HTTPS and SVCB Records

---

Conclusion

HTTPS and SVCB records let DNS describe how to connect to a service, not just where it lives. A single lookup can tell a browser that your site supports HTTP/3, that it should use TLS, which addresses to try first, and how to encrypt its Client Hello, while AliasMode finally gives the zone apex a standard way to point at another hostname.

They're an optional layer on top of your existing records, so nothing breaks for clients that ignore them. If your CDN publishes them for you, let it. If you publish them yourself, advertise only the protocols you really support, keep hints in step with your address records, and check the results with a current version of dig or kdig.