DNS Service Binding (SVCB) and HTTPS Records: A Practical Guide | Simon Painter
Skip to main content<br>In my previous post on encrypted DNS, I mentioned SVCB and HTTPS records together. For encrypted DNS discovery specifically, it is SVCB, used with the DNS-server mapping in RFC 9461 and DDR in RFC 9462, that lets supporting clients discover encrypted resolver transports without a manually entered DoH URL. I got several follow-up questions asking what these records actually are, how they work, what problems they solve, and what new problems they create.
This is a deep dive into both. I'll explain the mechanics, show you how they work with real examples you can test, walk through their legitimate use cases, and then discuss the operational challenges they present, especially for organisations trying to maintain control over encrypted DNS at their perimeter.
I make no secret of the fact that I love DNS. I think it's one of the most fascinatingly simple yet powerful protocols in the internet stack. The strength of DNS is its flexibility to do things that the original designers never imagined, while its biggest weakness is its flexibility to do things that the original designers never imagined. SVCB and HTTPS records are a perfect example of both sides of that coin.
SVCB and HTTPS records are fundamentally different from the DNS records you're used to. They're not just another way to signpost from a domain to a server IP address. They're a service metadata layer that lets DNS tell clients which endpoints to use, which protocols those endpoints support, and how to connect to them. That flexibility is powerful. It's also why they've become a vector for unexpected behaviour in networks trying to enforce encrypted DNS policies.
Let's start with what they are and how they work.
The Problem
Before RFC 9460 (November 2023), connecting to HTTPS services was surprisingly inefficient. Here's what happened:
Many sites still serve HTTP on port 80 and redirect to HTTPS. So your browser makes an HTTP request, gets a 301 redirect to https://example.com, then opens a TLS connection on port 443. That's already two round trips before any data flows.
Then the browser connects on HTTP/2, the server responds with an Alt-Svc header saying "hey, I also support HTTP/3", and the browser opens a new connection on QUIC. That's a third round trip. Multiple negotiations when one should have done the job.
Zone apex caused another headache. You couldn't use CNAME at example.com, only subdomains worked. This meant delegating your whole domain to a CDN was complicated. You had to either break your email routing or use hacky workarounds. The SVCB/HTTPS family fixed this for participating clients.
SVCB and HTTPS records let you move a lot of that connection metadata into DNS. Capable clients can learn supported protocols, preferred endpoints, and sometimes address hints before they connect. That can reduce redirects, avoid the Alt-Svc dance, and cut down on some follow-up lookups, but it does not magically eliminate every extra query in every implementation.
How They Work
The Basic Structure
A generic SVCB record looks like this:
_dns.resolver.example.com. 3600 IN SVCB 1 resolver.example.com. alpn="h2,h3" dohpath="/dns-query{?dns}"
Three key parts:
Priority (the 1 here) tells clients which record to try first. Lower numbers win. Priority 0 is special: it means "use this as an alias" (we'll get to that).
Endpoint (the resolver.example.com part) is where the service actually lives.
Parameters (the alpn="h2,h3" and dohpath="/dns-query{?dns}" bits) tell clients what protocols the endpoint supports and, for DoH, which URI template to use.
The important relationship is this: SVCB is the generic mechanism, while HTTPS is the SVCB-compatible RR type specialized for HTTPS origins. Because HTTPS already implies the https scheme, web clients query the origin name directly:
example.com. IN HTTPS 1 . alpn="h3,h2"
Two useful bits of shorthand: RR type 65 is HTTPS, so dig HTTPS example.com is the readable way to query it. And in DNS-server SVCB records, key7 is the parameter code for dohpath.
Generic SVCB is service-agnostic, so its owner name comes from the protocol mapping for that service, usually with underscored labels such as _dns.resolver.example.com.
Understanding Prefix Labels and Service Names
SVCB query names come from the protocol mapping for the service you are describing. A common pattern is an underscored scheme label, and sometimes an extra port prefix for non-default ports:
_.<br>_._.
Examples:
_dns.resolver.example.com - SVCB records for a resolver named resolver.example.com
_9953._dns.dns1.example.com - a DNS service on non-default port 9953
_8443._https.example.com - HTTPS on non-default port 8443
The underscore prefix prevents conflicts with ordinary hostnames. A client looking for _dns.resolver.example.com will not accidentally match resolver.example.com itself. This service-awareness means you can describe...