SVCB and HTTPS DNS Records (RFC 9460)

1. Two questions, one lookup

DNS has traditionally answered two independent questions. Where is the service? How should a client connect to it?

Earlier record types answer only the first question. An A record maps a name to an IPv4 address, an AAAA record to an IPv6 address, an MX record to a mail exchanger. None of them say anything about the port to use, the protocols the endpoint supports, or how to encrypt the handshake.

RFC 9460 introduces a standardized way to answer the second question, in the same lookup.

A single SVCB or HTTPS record can carry the port, the ALPN protocols the endpoint supports, IP address hints, and key material for encrypting the TLS handshake. The record type also permits aliasing at a zone apex, something CNAME has never allowed.

Two required fields and one optional field carry all of this.

Field	Purpose
SvcPriority	A number from 0 to 65535. A value of 0 means AliasMode. Any other value means ServiceMode
TargetName	The alias target in AliasMode, or the alternative endpoint’s hostname in ServiceMode
SvcParams	Key-value pairs describing the endpoint. Only meaningful in ServiceMode

The rest of this article covers the resolution rules, failure modes, and DNSSEC interactions that matter once these records are running in a real zone.

2. How resolution proceeds

The RFC defines a specific client algorithm, independent of whether the recursive resolver in between understands SVCB at all.

Query for TargetName
        |
        v
  AliasMode record?
   /            \
  yes            no
   |              |
   v              v
follow TargetName   ServiceMode records
   |               (compatible ones only)
   v                     |
back to query               v
                    sort by priority
                            |
                            v
                    connect to endpoint

1. Build the query name: the service name, plus a scheme prefix for generic SVCB records, or the plain hostname for HTTPS records on the default port.
2. Issue the query.
3. If an AliasMode record comes back, set the query name to its TargetName and repeat from step 2, up to a chain length limit.
4. If one or more compatible ServiceMode records come back, sort them by ascending priority. These are the candidate endpoints.
5. If none of the above resolves anything usable, SVCB resolution has failed, and the client proceeds according to the rules covered later in this article.

A resolver with no SVCB awareness at all still returns the record correctly, through the standard unknown-type handling defined in RFC 3597. It just skips the optimizations a SVCB-aware resolver can add, covered later on.

A/AAAA lookups and SVCB lookups are separate queries. In some configurations they resolve to different endpoints within the same session. That specific case is covered in the multi-CDN section below.

3. AliasMode and ServiceMode are not two flavors of the same behavior

SvcPriority is not a preference weight the way it might look at first glance. A value of exactly 0 switches the entire record into a different processing mode.

	AliasMode (SvcPriority = 0)	ServiceMode (SvcPriority > 0)
Purpose	Delegates to another name, similar to CNAME but usable at a zone apex	Binds connection parameters to a specific endpoint
SvcParams	Present or not, always ignored by the recipient	Interpreted normally
Multiple records at one name	Should be a single record. If several exist, clients pick one at random	Multiple allowed, sorted by ascending priority
Recommended TargetName	Never equal to the owner name, since that creates a loop	May be a single dot, meaning use the owner name itself

The SvcParams row is the one worth pausing on.

example.com  (HTTPS, priority 0, AliasMode)
        |
        v
svc.example.net  (TargetName)
        |
        v
  HTTPS / A / AAAA records resolved here

In AliasMode, the client resolves SVCB, A, and AAAA records for the TargetName instead of the original name. The RFC requires the recipient to ignore any SvcParams present on an AliasMode record. Zone-file tooling may warn about this, but it is not required to.

The record below has its port and alpn values discarded, with no error from the resolver, the client, or, in many zone editors, the zone file validator itself:

; SvcPriority is 0, so this is AliasMode.
; port=8443 and alpn=h2 are parsed but then discarded entirely.
example.com.  3600  IN HTTPS  0 svc.example.net. port=8443 alpn=h2

Publishing connection parameters requires a positive priority.

The most common way this record appears is a copy-paste from an AliasMode apex-aliasing example into a record that also needed to carry parameters. The apex-aliasing example correctly has no SvcParams. The priority gets left at 0 without anyone noticing.

3.1 Mixing modes in one RRset

A second consequence follows from mixing modes at the same name. The RFC requires that if an RRset contains any AliasMode record, the recipient ignores any ServiceMode records in that same set.

; Both records share the owner name example.com and record type HTTPS,
; so they are one RRset. The ServiceMode record below is ignored
; entirely, because an AliasMode record is present in the set.
example.com.  3600  IN HTTPS  0 svc.example.net.
example.com.  3600  IN HTTPS  1 backup.example.net. port=443

Adding a ServiceMode record alongside an existing AliasMode record, expecting both to be considered as alternatives, does not produce that behavior. Any conforming client drops the ServiceMode record entirely, silently.

3.2 AliasMode compared to CNAME and to ANAME proposals

AliasMode closes a gap CNAME could never close: CNAME records are not permitted at a zone apex, and the ANAME record type proposed to solve the same problem never reached standardization.

	CNAME	ANAME (proposal, not standardized)	AliasMode
Usable at zone apex	No	Yes	Yes
Affects all record types at the name	Yes	No, address records only	No, only the specific SVCB-compatible RR type queried
Requires special authoritative server logic	No	Yes, synthesizes A/AAAA at query time	No, works with ordinary in-bailiwick records
Extensible with connection parameters	No	No	Yes, via ServiceMode records at the target

AliasMode only affects the specific record type being queried. A domain can have an AliasMode HTTPS record at its apex while still serving A and AAAA records directly at that same name, for clients that do not understand HTTPS records at all.

4. Malformed records take down the whole RRset, not just the bad record

A record is malformed if any of the following is true:

• SvcParamKeys do not appear in strictly increasing numeric order within the record.
• A parameter’s value does not match the format expected for its key.
• The RDATA ends partway through a parameter.

Any of these conditions requires the client to reject the entire RRset and fall back to non-SVCB connection establishment. Not just the one bad record. The whole set, at that name and type.

RRset at example.com (6 records)
        |
        v
  one record malformed
        |
        v
 entire RRset discarded
        |
        v
 fall back to plain A/AAAA

A zone can have five correctly formatted ServiceMode records and one record with a duplicate SvcParamKey. Every conforming client discards all six and proceeds as if no HTTPS record existed at all.

This failure is invisible from the outside. A resolver returning NOERROR with an RRset present looks identical, from a basic reachability test, to a resolver serving well-formed records. The client falls back to plain A/AAAA and the connection still succeeds.

The only symptom is that none of the benefits the record was published for, HTTP/3, ECH, an alternate port, are ever used. Nothing in typical monitoring says why.

Checking the raw wire format directly is the reliable way to catch this:

dig +short example.com HTTPS

A modern dig build, BIND 9.16.6 and later, prints the parsed presentation format directly.

Unparsed hex, or a generic record display resembling the following, indicates either an unrecognized record type on the resolver’s part, or in rarer cases a value dig itself cannot parse cleanly:

\# 25 (
00 10                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 03                                              ; key 3 (port)
00 02                                              ; length 2
00 35                                              ; value (53)
)

Reading this by hand: the first two octets are the priority as a 16-bit integer. Then a length-prefixed sequence of labels for the target name. Then repeating groups of a 2-octet key number, a 2-octet value length, and the value bytes.

Confirming the key numbers appear in increasing order, and that each declared length matches the actual remaining bytes, is the manual equivalent of the malformed-record check a conforming client runs automatically.

5. Mandatory keys change one record’s fate, not the whole set

Section 8 of the RFC defines a narrower failure mode than the malformed-record case above. A SvcParamKey is automatically mandatory if the protocol mapping for that scheme requires it. For HTTPS records, port and no-default-alpn are automatically mandatory. Anything else can be added explicitly with a mandatory parameter.

A client that does not recognize every mandatory key on a given record treats that one record as incompatible. It skips that record without touching the rest of the RRset.

That is the key difference from the malformed-record case above.

Failure mode	Scope of rejection
Malformed record (bad wire format, out-of-order keys, bad value)	The entire RRset at that name and type is discarded
Unrecognized mandatory key	Only that one record is treated as incompatible and skipped

; If a client doesn't recognize the ech key, and ech is not listed as
; mandatory here, the client ignores ech and uses the rest of the
; record normally.
example.com.  3600  IN HTTPS  1 . alpn=h2,h3 ech=AEX+DQBB...

; If ech were added to mandatory, any client that doesn't recognize
; the key discards this entire record as incompatible, even though it
; could have connected fine by ignoring ech.
example.com.  3600  IN HTTPS  1 . alpn=h2,h3 ech=AEX+DQBB... mandatory=ech

Listing a key as mandatory is appropriate exactly when ignoring that key would break the connection attempt, not merely make it less optimal.

Marking a key mandatory when it is safe to ignore removes that endpoint entirely for any client or resolver version that predates support for the key. That is a real cost during a rollout window when client support is uneven.

6. DNSSEC is optional, until one specific case makes it load-bearing

Section 12 of the RFC states that DNSSEC signing and validation are optional for SVCB and HTTPS records.

The reasoning: these records are designed for delivery over an untrusted channel, and the client independently validates the TLS certificate for the actual origin regardless of what the record says. An attacker who tampers with an unsigned record can at most steer a client toward a bad connection attempt. Impersonating the origin is not possible, because certificate validation still has to succeed against the real hostname.

6.1 When fallback stops being graceful

Section 3.1 describes a narrower, separate scenario, and this is the part with the sharpest operational consequence.

HTTPS query issued
        |
        v
  SERVFAIL / auth error / timeout?
   /                          \
  no                          yes
   |                            |
   v                            v
resolution succeeds     DNS response cryptographically
or fails normally        protected? (DNSSEC / DoT / DoH)
                          /              \
                        yes              no
                         |                |
                         v                v
                abandon connection   fatal or nonfatal,
                (anti-downgrade)     client's discretion

If DNS responses are cryptographically protected, through a DNSSEC-validating resolver or a transport like DNS over TLS or DNS over HTTPS, and SVCB resolution fails due to an authentication error, a SERVFAIL, a transport error, or a timeout, the client is directed to abandon the connection attempt entirely. This holds even if the client would otherwise be SVCB-optional and capable of falling back to plain A/AAAA.

The reason is anti-downgrade protection. Silently falling back in this situation would let an active attacker deny the client access to the SvcParams while letting everything else through, undetected.

Failure condition	Required client behavior
SVCB resolution hits its alias-chain-length limit	Must fall back to the authority endpoint, as if no SVCB record existed
DNS responses are not cryptographically protected and SVCB resolution fails outright (NODATA, or the query is unanswered)	May treat this as fatal or nonfatal, at the client’s discretion
DNS responses are cryptographically protected (DNSSEC validation active, or DoT/DoH in use) and SVCB resolution fails due to an authentication error, SERVFAIL, transport error, or timeout	Should abandon the connection attempt, per the anti-downgrade guidance in Section 3.1

That third row is the one that produces silent, hard-to-reproduce outages.

6.2 How this failure actually happens

A zone can sign its A and AAAA records correctly and rotate keys without incident, while its HTTPS RRset falls out of sync with the rest of the signing pipeline. Common causes:

• The record was added to the zone after the last full re-sign.
• An automation script does not include the newer record type in its resigning pass.
• The RRSIG covering the HTTPS RRset expires on a different schedule than the rest of the zone.

Every A/AAAA-only DNS check against that zone shows a fully healthy, correctly signed domain.

Clients that do not validate DNSSEC, or that sit behind resolvers that do not validate, connect normally. They see only the plain A/AAAA path and never attempt SVCB resolution at all.

A client enforcing DNSSEC validation, or sitting behind a validating resolver, gets a SERVFAIL specifically on the HTTPS query. Per the RFC’s own guidance, it is expected to abandon the connection rather than fall back.

The failure reaches only the subset of traffic doing DNSSEC validation. That is exactly the subset least likely to appear in an ad hoc manual test run from a machine with a non-validating stub resolver.

6.3 How to verify validation

Testing SVCB resolution specifically with validation enabled, rather than only checking that the record resolves, isolates this failure.

# Confirm the record itself resolves and is well formed.
dig +short example.com HTTPS

# Confirm the RRSIG exists and check its expiration.
dig example.com HTTPS +dnssec | grep RRSIG

# Explicitly ask a validating resolver to check the AD (Authenticated
# Data) bit for this specific query. A missing AD bit where one is
# expected, or an outright SERVFAIL, indicates the failure this
# section describes.
dig +dnssec +cd example.com HTTPS @1.1.1.1
dig +dnssec example.com HTTPS @1.1.1.1

Comparing the result from a known-validating resolver against one known not to validate isolates whether a given HTTPS record failure is DNSSEC-specific. Cloudflare’s 1.1.1.1 and Quad9’s 9.9.9.9 both validate by default.

The RFC also states that a client enforcing DNSSEC validation on its A/AAAA lookups should apply the same policy to SVCB lookups. Without that consistency, an attacker who cannot forge signed A/AAAA records could instead forge an unsigned SVCB record redirecting the client elsewhere, defeating the protection DNSSEC provides on the address records.

7. AliasMode’s dot target as a targeted blocking vector

A TargetName of a single dot in AliasMode is an advisory signal meaning the service does not exist. Clients are permitted, not required, to honor it.

The security considerations section flags a specific risk here. A hostile DNS intermediary can forge this response to block one particular protocol or port on a domain, without blocking the domain outright the way forging an NXDOMAIN would.

That is a narrower, more surgical blocking primitive than most DNS-based interference, precisely because SVCB and HTTPS records are structured around individual protocols and ports rather than whole domains.

The RFC’s recommendation for clients that might face this kind of attacker: ignore AliasMode dot records rather than treat them as authoritative.

8. Query name construction depends on the port

Generic SVCB records use an underscore-prefixed label indicating the scheme, following the Attrleaf naming convention. A query for the foo scheme on port 8080 for api.example.com is a query for _8080._foo.api.example.com.

HTTPS records use a narrower rule.

Port	Query name
443 (default for https)	The plain hostname, with no prefix labels at all
Any other port	Underscore-prefixed: _PORT._https. followed by the hostname

; Port 443 (the default): no prefix
example.com.               HTTPS  1 . alpn=h2,h3

; Non-default port 8443: prefixed
_8443._https.example.com.  HTTPS  1 . alpn=h2,h3

The common misconfiguration publishes an HTTPS record for a non-default port at the plain hostname, the same place the default-port record belongs.

A client looking for the record on a non-standard port queries the prefixed name specifically. A record sitting only at the unprefixed name is never found for that case, with no error, since the plain-name query returns something different or nothing at all depending on what else is published there.

9. Zone and resolver operational details worth checking directly

A handful of behaviors only surface once a zone or resolver is under real operational conditions.

Underscore-label rejection. Some authoritative DNS server software refuses to load A or AAAA records on names starting with an underscore. This is a strict-hostname-validation feature originally intended to catch malformed data. It becomes relevant whenever a TargetName or owner name needs an Attrleaf-style underscore prefix and also needs its own address records. Check the specific authoritative server software’s name-validation settings before assuming a zone file that validates locally will load correctly on the production server.

Alias chain limits are implementation-defined. Clients and resolvers are required to follow at least one AliasMode record, but the exact limit beyond that is left to each implementation. The RFC discourages zone structures that require following more than eight combined AliasMode and CNAME hops. A chain near or beyond that length can resolve correctly against one resolver and silently fail against another, with a lower limit, since the chain-length-limit rule above still applies.

Additional-section chasing is optional for the resolver, not just the client. A SVCB-aware recursive resolver can pre-resolve the target’s SVCB, A, and AAAA records and return them in the Additional section, saving the client a round trip. A resolver with no SVCB awareness still returns the record correctly in the Answer section, through the generic unknown-type handling from RFC 3597, but does none of that extra work.

Independent lookups can disagree in a multi-CDN setup. When A, AAAA, and HTTPS records are served through independent CNAME chains that can each point to a different provider at different times, a client’s A/AAAA resolution and its HTTPS resolution can land on different providers within the same session. Each is an independent DNS lookup. The RFC treats this as an expected consequence of the design, and recommends including ipv4hint and ipv6hint in the HTTPS record to reduce the cost of reconciling the mismatch.

Testing the Additional-section behavior directly shows how much a given resolver is doing on the client’s behalf:

# A SVCB-aware resolver may populate the Additional section with
# pre-resolved A/AAAA/SVCB records for the target.
dig example.com HTTPS +additional @1.1.1.1

# A resolver with no SVCB awareness returns the record correctly
# but leaves the Additional section empty, requiring the client
# to issue its own follow-up queries.
dig example.com HTTPS +additional @<older-or-minimal-resolver>

10. Interaction with Encrypted Client Hello

The ech SvcParamKey carries the key material a client needs to encrypt the TLS ClientHello, hiding the Server Name Indication from on-path observers. It is one of the more common reasons a domain owner publishes HTTPS records at all.

ECH depends entirely on the HTTPS record for key distribution. There is no other channel defined for a client to learn the key material before connecting, which is exactly why the record’s availability, not just its correctness, matters for ECH specifically.

ECH’s own failure philosophy differs from the DNSSEC guidance above, and the difference is central to understanding why the RFC treats the two cases so differently.

Situation	What happens
HTTPS record with ech is missing, blocked, or not fetched	ECH-capable clients fall back to a standard TLS handshake with the SNI visible in plaintext. The connection still completes
HTTPS record fails DNSSEC validation (Section 3.1 conditions)	The client is directed to abandon the connection attempt entirely

The first row is a deliberate design choice. ECH is a privacy enhancement layered on top of a connection that has to remain functional even when ECH itself is unavailable, so losing the HTTPS record typically degrades privacy, not connectivity.

The second row is intentionally stricter, for the anti-downgrade reasons covered in Section 6.1. That contrast, privacy loss on one path and connection abandonment on the other, is the reason the two failure modes cannot be treated as interchangeable when debugging a report. Conflating them leads to chasing the wrong mechanism, whether the report is a connectivity failure or a loss of SNI privacy.

Some networks disable ECH deliberately, using a canary domain, use-application-dns.net, that returns NXDOMAIN or a deliberately empty answer. Browsers that check this canary treat that response as a signal to disable ECH network-wide for that session, independent of anything published in any individual domain’s HTTPS record.

dig use-application-dns.net

11. Cross-reference: agent discovery and why DNSSEC cannot stay optional there

RFC 9460’s decision to make DNSSEC optional rests on a specific backstop. An HTTP client steered somewhere wrong by a tampered record still fails TLS certificate validation against the real origin. The record’s authenticity does not need independent cryptographic protection to keep the connection safe.

The IETF draft for DNS-based agent identification and discovery, commonly referred to by its working name DNS-AID, reuses the SVCB record type for a different purpose. It publishes which protocol an autonomous agent speaks and where to reach it, using custom SvcParamKeys such as a capability document URL and a policy reference, under an agents-specific underscore-labeled namespace.

This draft requires DNSSEC signing and validation as part of its trust model, rather than leaving it optional.

The backstop argument above does not apply here. There is no equivalent to a TLS certificate check validating that a discovered agent endpoint actually belongs to the domain that published it. The SVCB record is not a connection hint layered on top of an independently authenticated channel in this case. It is closer to the sole source of truth about which endpoint is legitimate.

An unsigned record in this context carries the exact risk the base HTTP mapping was designed to avoid.

	HTTP client using an HTTPS record	Agent discovery client using an SVCB record
Independent authenticity check	TLS certificate validation against the real origin	None
Fallback if the record is rejected or unavailable	Plain connection to the same address	Typically no equivalent discovery path
Cost of an overly broad mandatory list	A skipped optimization	A hard discovery failure

The same parsing and mandatory-key rules produce very different outcomes depending on which column applies.

Any custom SvcParamKey used for this purpose that is not in the initial IANA registry (mandatory, alpn, no-default-alpn, port, ipv4hint, ipv6hint, and the reserved ech) needs its own registration through the Expert Review process the RFC defines, or has to be represented using the generic keyNNNNN numeric form until registered. A deployment relying on an unregistered custom key name that different implementations have not agreed on a numeric value for is not interoperable yet.

12. Common misconfigurations

Misconfiguration	Effect
SvcPriority left at 0 by accident	Every SvcParam on the record is silently ignored
ServiceMode record published alongside an AliasMode record at the same name	The ServiceMode record is dropped entirely by conforming clients
Duplicate SvcParamKeys, or keys out of numeric order	The entire RRset is discarded as malformed
A parameter value in the wrong format for its key	Same as above: the entire RRset is discarded
A key marked mandatory that most clients do not yet recognize	That record is skipped as incompatible, even though ignoring the key would have worked fine
HTTPS record for a non-default port published at the plain hostname	The record is never found by clients querying the correct, prefixed name
HTTPS RRset resigned on a different schedule than the rest of the zone	DNSSEC-validating clients get SERVFAIL and are directed to abandon the connection, while non-validating clients see no problem at all
Alias chains longer than roughly eight combined AliasMode and CNAME hops	Resolution can succeed against resolvers with a high chain-length limit and fail against ones with a lower limit

13. Diagnostic command reference

Check	Command
Confirm the record resolves and is well formed	dig +short example.com HTTPS
Confirm signature presence and expiration	dig example.com HTTPS +dnssec | grep RRSIG
Check DNSSEC validation against a known-validating resolver	dig +dnssec example.com HTTPS @1.1.1.1
Check whether a resolver is doing Additional-section chasing	dig example.com HTTPS +additional @<resolver>
Check whether ECH is disabled at the network level	dig use-application-dns.net

From the team at

Web Specification Studio

We build digital products and explore the modern web standards behind them.

About the team

Related posts

• HTTP 103 Early Hints: Preloading Resources During Server Think-Time
• Content Security Policy (CSP): Architecting Strict CSP with Nonces and Hashes
• Why Port 80 Is Required for ACME HTTP-01 Renewals: Troubleshooting AWS Ingress and Port 443 Failures