Records

HTTPS / SVCB: service binding hints

A modern record that lets DNS hand a client the parameters needed to start a TLS connection in one round trip: ALPN, port, IP hints, even ECH keys. HTTPS is just SVCB specialized for https:// URLs.

In one line:

example.com.    HTTPS    1 . alpn="h2,h3" ipv4hint=192.0.2.1
└── this name ┘ └type─┘  └── speaks these protocols; race these hints


Type number	65 (HTTPS) · 64 (SVCB)
RFC	9460
RDATA	priority · target · key=value pairs

What it holds#

Three slots:

Field	Purpose
Priority	`0` = "alias mode" (treat target as a CNAME-replacement). `>0` = "service mode": these are real hints.
Target	The hostname providing the service. In service mode, `.` (a single dot) means "this name itself." In alias mode, `.` means "this service does not exist" (RFC 9460 s2.5).
Parameters	`key=value` pairs the client uses to set up the connection.

The big parameters:

Key	Carries
`alpn`	Supported ALPN protocols, e.g., `h2`, `h3`
`port`	Override the default port
`ipv4hint`	IPv4 addresses the client can skip A lookups for
`ipv6hint`	Same for v6
`ech`	Encrypted Client Hello config: opaque base64 blob the client uses

A real example, live on the demo name:

svcb.example.isitdns.net.   HTTPS  1 . alpn="h2,h3" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

Before even connecting, a browser learns: this service speaks HTTP/2 and HTTP/3, and here are hint addresses to race while the A/AAAA lookups finish.

Browsers reading that know, before they open a TCP connection, that:

The server speaks HTTP/2 and HTTP/3.
The addresses are 192.0.2.1 and 2001:db8::1: no waiting on separate A/AAAA lookups before it can connect.

This site itself (isitdns.net) also publishes a live HTTPS record with real ECH data. See the dig example section below for a runnable proof.

When to use it#

For any production web service. Modern browsers (Safari, Chrome, Firefox all support it) save a round trip when HTTPS hints are present.
To advertise ALPN+ECH together: required for the new privacy-preserving TLS handshake (Encrypted Client Hello).
To express "use port 8443" without resorting to a URL-with-port: port=8443 in the HTTPS record.

When not to use it#

For non-web services: use SVCB with its own service binding scheme, not HTTPS.
When your authoritative server cannot emit it. Older server versions lack native HTTPS/SVCB support; fall back to publishing the underlying A/AAAA + ALPN hints as separate records, or stand up the record as a generic typed RR (TYPE65) by hex-encoding the RDATA.
When the parameters change frequently: every change is a TTL-cache rollout.

dig example#

dig 9.10.x (stock macOS) does NOT know the name HTTPS as a query type. If you write dig example.com HTTPS, dig 9.10.x treats HTTPS as a second hostname and queries for the A record of the literal name HTTPS. instead. Use TYPE65 (the numeric form) on any dig older than BIND 9.16.21, the release that taught dig and nslookup both record types.

dig @1.1.1.1 svcb.example.isitdns.net TYPE65 +short

1 . alpn="h2,h3" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

On an older dig the same command returns raw generic RDATA instead (add +unknownformat to reproduce this hex view on a dig that already decodes the type):

\# 41 0001000001000602683202683300040004C00002010006001020010D B8000000000000000000000001

That hex is the raw RDATA of the HTTPS record. A dig that understands HTTPS (9.16.21 or newer) decodes it into 1 . alpn="h2,h3" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1. The ipv4hint and ipv6hint here are documentation addresses (192.0.2.1 from TEST-NET-1, 2001:db8::1 from the IPv6 documentation prefix); this demo name publishes no A or AAAA records of its own, only the HTTPS record carrying the hints. The mechanism they demonstrate is real: on a production name the hints carry the actual edge IPs, kept in sync with the name's A/AAAA, so the client can open the connection without a separate address lookup.

Whether nslookup decodes SVCB/HTTPS depends on its BIND version, same as dig. BIND 9.16.21 added parsing and printing for both record types, so a modern nslookup shows the parameters. Older builds (like the 9.10-era stock macOS one) return raw hex just like dig 9.10.x; there, use dig 9.18+ or curl DoH instead.

nslookup -type=TYPE65 svcb.example.isitdns.net 1.1.1.1

A modern nslookup (9.18.39 shown, checked live against the demo name) decodes the record:

Server:    1.1.1.1
Address:   1.1.1.1#53

Non-authoritative answer:
svcb.example.isitdns.net  rdata_65 = 1 . alpn="h2,h3" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

Authoritative answers can be found from:

An nslookup older than 9.16.21 prints the same answer as raw hex:

svcb.example.isitdns.net  rdata_65 = \# 41 0001000001000602683202683300040004C00002010006001020010D B8000000000000000000000001

Proof with curl DoH#

curl is the most portable way to query HTTPS/SVCB from any machine, and it reports the AD bit so you can see whether the answer is DNSSEC-validated. Cloudflare and Google both return type 65 in presentation format now, so the pair is a straight cross-check that the same parameters came back on two independent paths:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=svcb.example.isitdns.net&type=HTTPS' \
  | jq .Answer

The TTL counts down from the zone's 300 while the answer sits in the resolver's cache; a cache miss shows the full 300.

[
  {
    "name": "svcb.example.isitdns.net",
    "type": 65,
    "TTL": 300,
    "data": "1 . alpn=h2,h3 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1"
  }
]

This changed in 2026. Cloudflare used to return type 65 as RFC 3597 generic hex, "\\# 41 00 01 00 00 01 00 06 02 68 32 ...". A July 2026 rollout moved SVCB and HTTPS, with seven other types, to presentation format. Captured over DoH 2026-09-04.

Google returns the same string (note that both skip the quotes around alpn that dig adds):

curl -s 'https://dns.google/resolve?name=svcb.example.isitdns.net&type=65' | jq -r '.Answer[].data'

1 . alpn=h2,h3 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

ECH in the wild: isitdns.net itself#

isitdns.net publishes a live HTTPS record that includes an ECH key blob and real Cloudflare edge addresses. You can fetch it with:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=isitdns.net&type=HTTPS' \
  | jq '{AD: .AD, Answer: .Answer}'

The data line is long on purpose: the base64 ech config is most of it, so it stays unwrapped. Let it scroll. Cloudflare rotates that key often enough that Cloudflare and Google handed back two different ech values minutes apart on the day this was captured, so yours will differ from this one (taken 2026-09-04):

{
  "AD": true,
  "Answer": [
    {
      "name": "isitdns.net",
      "type": 65,
      "TTL": 300,
      "data": "1 . alpn=h3,h2 ipv4hint=104.21.56.211,172.67.155.242 ech=AEX+DQBBzAAgACBdjRR/DoyyCPlNhdkvfShbyxStYZAQ4f9msm08MZwIJQAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3032::6815:38d3,2606:4700:3036::ac43:9bf2"
    }
  ]
}

AD: true means the resolver validated the DNSSEC chain and is asserting that over the DoH connection (RFC 4035 §3.2.3). Four SvcParams are set: alpn (h3 then h2), ipv4hint, ech (an opaque config the client hands to TLS, base64 in this format and 71 bytes on the wire), and ipv6hint. That is what a real production HTTPS record with ECH looks like.

DoH query over HTTPS transport#

DoH is DNS-over-HTTPS, documented in dot-doh. The curl commands above already use DoH through Cloudflare's JSON API. dig 9.18+ can speak the binary wire format from RFC 8484 directly with +https:

dig @1.1.1.1 +https svcb.example.isitdns.net HTTPS +short

1 . alpn="h2,h3" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1

+https requires dig 9.18+ and is not available in the system dig on macOS (9.10.x).

nslookup can't issue DoH or DoT queries at any version. Use curl (shown above) or kdig from the knot-dnsutils package.

See it live: isitdns.net/#dig?name=svcb.example.isitdns.net&qtype=HTTPS

RFC: RFC 9460 defines SVCB and HTTPS, the SvcParam keys, and the split between alias mode and service mode (s2.4).

Gotchas#

Alias mode (priority 0) is a cname alternative at the apex. Useful because, unlike CNAME, HTTPS records can coexist with other apex records. Some managed DNS providers use this in front of proxied apex names.
ECH support requires the matching key at the origin. The published ech blob is the public half of a key config; the server must hold the private half. Do not publish ech=... until the server actually accepts it; some clients hard-fail rather than fall back.
Older resolvers may not pass HTTPS records through. EDNS UDP buffer size matters; large parameter blobs can truncate. See query-types for more on EDNS.
Browser support is good but not universal. Always still publish A/AAAA: HTTPS is additional hint data, not a replacement.
The ipv4hint/ipv6hint values must match the A/AAAA, or clients get inconsistent answers. They are hints, not gospel: RFC 9460 s7.3 tells clients to ignore them when A/AAAA answers are already in hand and to switch to the real addresses once they arrive. Managed DNS providers that auto-publish HTTPS records keep them in sync; for manually published records, you own the synchronization.
dig 9.10.x (stock macOS) silently ignores your intent. Writing dig example.com HTTPS on an older dig queries the A record for example.com and then the A record for the literal hostname HTTPS.. Always use TYPE65 on older dig, or see nslookup-and-dig for a newer dig.