Records

HTTPS / SVCB: service binding hints

A record that hands a client the parameters to start a TLS connection: ALPN, port, IP hints, even ECH keys (RFC 9460 s1). HTTPS is SVCB specialized for https:// URLs.

In one line:

example.com.    HTTPS    1 svc.example.net. alpn="h2,h3" ipv4hint=192.0.2.1
└── this name ┘ └type─┘  └── served by svc.example.net, speaks these protocols, hint for its address


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, `.` 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 (RFC 9460 s7.2)
`ipv4hint`	IPv4 addresses to try while the A lookup finishes (RFC 9460 s7.3)
`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"

Before connecting, a client reading that knows the server speaks HTTP/2 and HTTP/3. It carries no address hints: its TargetName is the owner name ., where hints do not belong (RFC 9460 s7.3).

When to use it#

For any production web service. HTTPS hints let a client skip a round trip before upgrading to HTTP/2, HTTP/3, or ECH (RFC 9460 s1).
To advertise ALPN and ECH together for the privacy-preserving TLS handshake.
To express "use port 8443" without 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 typed HTTPS/SVCB RDATA: publish it as generic type TYPE65 instead (see Gotchas).
When the parameters change frequently: every change is a TTL-cache rollout.

dig example#

Asks for the connection hints a browser should use before it connects.

$ dig @1.1.1.1 svcb.example.isitdns.net HTTPS

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> @1.1.1.1 svcb.example.isitdns.net HTTPS

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20947

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;svcb.example.isitdns.net. IN HTTPS

;; ANSWER SECTION:

svcb.example.isitdns.net. 300 IN HTTPS 1 . alpn="h2,h3"

;; Query time: 36 msec

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

;; WHEN: Sat Oct 10 19:54:03 CDT 2026

;; MSG SIZE rcvd: 78

GO NOERROR and one HTTPS record carrying alpn

NO GO NOERROR with no answer, which means the browser falls back to A and AAAA

run this query in the dig tool →

what each part of this output means →

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

DoH query (HTTPS)#

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

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

Gotchas#

Alias mode (priority 0) is a cname alternative at the apex, and unlike CNAME it can coexist with other apex records (RFC 9460 s1).
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 accepts it.
Large parameter sets can hit the EDNS UDP buffer and truncate. See query-types for more on EDNS.
ipv4hint/ipv6hint are hints, not gospel. RFC 9460 s7.3 tells clients to ignore them once real A/AAAA answers are in hand, and to use the real addresses for the connection. Keep the hints in sync with the actual A/AAAA, or clients get inconsistent answers.
Publish A/AAAA regardless. Legacy clients never read HTTPS/SVCB, so service operators still need fallback A/AAAA records alongside it (RFC 9460 s2.4.2).
dig older than BIND 9.16.21 does not know the query type HTTPS. dig example.com HTTPS on that dig queries the A record of the literal hostname HTTPS. instead. Use TYPE65 (the numeric form) on any older dig, or see nslookup-and-dig for a current one.