← Back to Blog

For most of DNS history, pointing a client at a service meant a simple chain: an A or AAAA record gave an address, and everything else, which port, which protocol, whether encryption was available, was either assumed, hardcoded, or discovered through extra round trips. Two newer record types, SVCB and HTTPS, change that. They let a domain publish how a service should be reached, not just where, in a single DNS lookup. The result is faster connections, cleaner configuration, and a foundation for privacy features that were previously awkward to deliver.

These records are still unfamiliar to many teams, partly because they arrived recently and partly because their parameter syntax looks more intimidating than it is. This guide explains what SVCB and HTTPS records are, shows what they actually look like, walks through how to add one, and covers what to watch for when monitoring them.

What SVCB and HTTPS Records Are

SVCB, short for Service Binding, is a general-purpose DNS record type for describing how to connect to a service. HTTPS is a specialized form of SVCB built specifically for web services, and it carries DNS record type number 65. They are close siblings: HTTPS is essentially SVCB with web conventions baked in, which is why they are almost always discussed together and share the same structure.

Both records have three parts, in this order: a priority, a target name, and an optional set of service parameters (called SvcParams). A minimal HTTPS record in standard zone-file format looks like this:

example.com.   3600   IN   HTTPS   1   .   alpn="h3,h2"   ipv4hint=203.0.113.1

Reading that left to right: the owner name (example.com.), the TTL (3600), the class and type (IN HTTPS), then the three parts, priority 1, target . (a dot meaning "the same name as the owner"), and two service parameters. The alpn parameter advertises that the service supports HTTP/3 and HTTP/2, and ipv4hint supplies an address so the client can skip a separate A lookup.

The Two Modes: Alias and Service

The priority value determines which of two modes the record is in, and this is the most important concept to grasp.

AliasMode (priority 0) makes the record behave like a CNAME, redirecting resolution to another name, but with one crucial advantage: unlike CNAME, it is allowed at the zone apex (the bare domain). This finally solves the long-standing problem of pointing a bare domain at a provider. It looks like this:

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

Here priority 0 signals AliasMode, and the target cdn.provider.net. is where resolution is delegated. No service parameters are used in this mode.

ServiceMode (priority greater than 0) describes an actual endpoint and its connection parameters. You can publish multiple ServiceMode records, and clients prefer the lowest priority number first, which lets you express primary and backup endpoints:

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

A client tries priority 1 first, falling back to the backup endpoint at priority 2 if needed.

The Service Parameters Worth Knowing

The SvcParams are where the useful configuration lives. The ones you will encounter most:

  • alpn: the application protocols the endpoint supports, such as h3 (HTTP/3) and h2 (HTTP/2). This lets a client skip protocol negotiation and connect using the best available protocol immediately.
  • port: an alternative port, if the service does not use the default.
  • ipv4hint and ipv6hint: address hints that let a client avoid a separate A or AAAA lookup, saving a round trip.
  • ech: Encrypted ClientHello configuration, which supports encrypting the server name during the TLS handshake. This is one of the privacy features these records were designed to enable.
  • mandatory: marks other parameters that a client must understand, or else ignore the record.

One syntax rule that catches people out: service parameters must appear in ascending order by their key number, not in an arbitrary order. The key numbers include mandatory=0, alpn=1, port=3, ipv4hint=4, and ipv6hint=6. Ordering strictly by that numeric key value keeps the record valid:

; CORRECT: ascending by key number (alpn=1, ipv4hint=4, port=3 would be wrong order)
example.com.   IN   HTTPS   1   .   alpn="h3"   port=443   ipv4hint=203.0.113.1

; WRONG: keys out of numeric order, may cause parse errors
example.com.   IN   HTTPS   1   .   ipv4hint=203.0.113.1   alpn="h3"

Most provider editors sort the parameters for you, which is one good reason to use them rather than hand-authoring raw records.

How to Add One

There are two realistic paths, and for most teams the first is both easier and safer.

Through your DNS provider, which most now support. Cloudflare, AWS Route 53, Google Cloud DNS, Akamai, and others support SVCB and HTTPS records. In a typical provider UI the steps are:

  • Open your domain's DNS management page and choose to add a record.
  • Select HTTPS (or SVCB) from the record type list.
  • For the name, leave it blank or use @ for the zone apex on the standard HTTPS port.
  • Set the priority: 0 for AliasMode, or 1 (or higher) for ServiceMode.
  • Set the target: the alias target for AliasMode, or . to mean the owner name itself in ServiceMode.
  • Add the service parameters (alpn, ipv4hint, and so on) in the parameter fields. A good editor validates these and previews the result as you type.

Through infrastructure-as-code, if you manage DNS that way. Tools such as DNSControl express the same record compactly, for example an apex HTTPS record advertising HTTP/3 and HTTP/2 with an address hint on port 443. The three parts, priority, target, and parameters, map directly onto whatever your tool's syntax is.

Whichever path you use, keep your existing A and AAAA records in place. Which brings us to the reassuring part of adoption.

Adoption Is Additive and Low-Risk

SVCB and HTTPS records are designed to be backward compatible. You do not remove your address records to adopt them. Clients that understand the new records use them; clients that do not simply fall back to the A and AAAA records they already know. Nothing is taken away from older clients, so the risk of adoption is low.

The main caution is correctness. Because a malformed record can be ignored or, worse, cause SVCB-aware clients to attempt connections that fail, test before rolling out widely, and use a low TTL during initial deployment so you can correct mistakes quickly. This is a good moment to apply the general principles in our guide to DNS TTL best practices. One DNSSEC interaction is worth knowing: for a signed zone, an invalid record is not silently skipped the way it might be otherwise, so getting the syntax right matters more when DNSSEC is in play.

Monitoring Considerations

Once these records are live, they become part of your DNS surface that deserves the same attention as any other record.

Track changes to them. An HTTPS or SVCB record that changes unexpectedly matters for the same reason any record change does: it affects how clients reach your service, and an unexpected change can indicate a misconfiguration or tampering. Change monitoring should cover these record types, not only the traditional ones.

Validate that published records are well-formed. Because these records influence connection behavior, a malformed or stale record can degrade performance or cause failures for clients that honor it. Confirming records are valid and current is worth building into your review process.

Keep them consistent with your other configuration. HTTPS records can carry information that overlaps with your TLS and CDN setup. Keeping them aligned avoids the situation where DNS advertises one thing and the service delivers another.

Where This Sits in the Bigger Picture

SVCB and HTTPS records are part of a broader trend of DNS taking on a richer role, carrying not just addresses but service and security parameters. That expanded role is exactly why keeping DNS continuously monitored matters more than it used to, a theme at the center of DNS posture management. As DNS carries more meaning, more can go wrong in it quietly.

DNS Assistant treats these newer record types as part of the DNS surface it monitors: it detects changes across record types and surfaces them in real time, so a change to an HTTPS or SVCB record is visible the same way any other record change would be. That is the accurate scope here: these records are one more part of the configuration worth keeping under continuous watch, alongside the dangling-record, email-authentication, and DNSSEC checks that make up a fuller posture picture.

Getting Started

To see what records a domain currently publishes, including whether HTTPS records are already present, inspect it with the free DNS lookup tool or a Free Domain Risk Report.

To keep your full set of DNS records, newer types included, continuously monitored for change, start free at dnsassistant.com.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.

Sign Up Free