How do you read an SVCB or HTTPS DNS record?

A record type for connection hints, not just addresses

Every record type covered in how to read a DNS lookup result — A, AAAA, CNAME, MX, TXT, NS — answers a narrow question: an address, an alias, a mail destination, free-form text, or a zone’s authority. RFC 9460 defines a type that answers a different question entirely: not just “where is this service,” but “how should I actually connect to it.” SVCB (Service Binding) and HTTPS records let a zone publish, in the DNS answer itself, which application protocols a service speaks, which port it listens on, fallback addresses, and even TLS handshake material — hints a client would otherwise only discover after already opening a connection and negotiating.

HTTPS is a fixed specialization of the general SVCB record for web traffic specifically: a client resolving https://example.com queries the HTTPS type at that name, while SVCB stays available for other schemes that define their own use of it in the future. Both share the same wire format defined in RFC 9460, so everything below about reading the fields applies to either type.

AliasForm vs. ServiceForm: what the priority field decides

Every SVCB/HTTPS record starts with a 16-bit SvcPriority field, and its value changes what the rest of the record means:

• Priority 0 — AliasForm. The record carries only a TargetName and no parameters. It tells the client “the service hints you want live at this other name, not here” — the client re-resolves SVCB/HTTPS at the target instead. This is conceptually similar to how a CNAME record redirects a lookup to another name, though it is its own distinct mechanism specific to this record type, not a CNAME.
• Priority 1 or higher — ServiceForm. The record applies directly to the name queried and carries a list of SvcParams — the actual connection hints. A name can publish several ServiceForm records at different priorities; a client tries the lowest priority number first, falling back to higher numbers if that connection attempt fails, the same lower-number-wins convention MX priority uses for mail.

Reading the SvcParams

The parameters are where the useful information lives. IANA’s Service Binding (SVCB) Parameter Registry, maintained alongside RFC 9460, defines the common keys:

• alpn — the ALPN protocol IDs the service supports, such as h2 or h3. This is the headline use case: a client can see a server supports HTTP/3 over QUIC before ever opening a TCP connection to negotiate it the slower way, inside a TLS handshake, as ALPN (RFC 7301) normally requires.
• no-default-alpn — a flag telling the client not to assume plain HTTP/1.1 is also offered alongside whatever alpn lists.
• port — a non-default port the service actually listens on, letting a client skip straight to the right port instead of assuming 443.
• ipv4hint / ipv6hint — addresses the client can try directly, avoiding a separate A/AAAA lookup round trip for the common case.
• ech — an Encrypted Client Hello configuration, letting the TLS handshake’s SNI field itself be encrypted rather than sent in the clear.

None of these are mandatory, and a record can mix and match whichever subset the operator wants to publish.

Checking for one today

AdminKit’s live DNS lookup tool resolves A, AAAA, MX, TXT, NS, CAA, PTR, SOA and CNAME — SVCB and HTTPS are newer types it doesn’t support yet, and a request for either is rejected before reaching the upstream resolver rather than returning a misleading empty result. Until that support ships, check for one directly with a command-line resolver:

dig example.com HTTPS
dig example.com SVCB

An empty answer section means the domain hasn’t published one, which is completely normal — the record is optional and additive, and most domains still don’t publish it. If you’re confirming a server’s actual TLS behavior rather than what it advertises in DNS, AdminKit’s live SSL/TLS check completes a real handshake against the host and reports the certificate and negotiated protocol version it presents.

Why publishing one is safe for every client, old or new

RFC 9460 is explicit that both types are designed to be additive: a resolver or client that has never heard of SVCB or HTTPS simply doesn’t ask for the type, or ignores an answer it happens to receive, and falls back to resolving A/AAAA the way it always has. This is what has let large, high-traffic operators start publishing HTTPS records — mainly to advertise HTTP/3 and ECH support — without needing to wait for every browser, library and resolver on the internet to support the new type first. If a change you’ve made doesn’t show up yet in a dig query, see DNS propagation and TTL explained for how long a cached answer can linger before resolvers re-check.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.