The layer that decides before the first handshake
For years the sequence was undisputed: resolve the name, get an A or AAAA record, open a TCP connection, negotiate TLS and pick the application protocol via ALPN along the way. The HTTPS record moves part of that decision forward — into the DNS answer. RFC 9460 defines two related record types for this: SVCB (type 64) as a generic service binding for arbitrary protocols and HTTPS (type 65) as the HTTP-specific variant that needs no underscore prefix and can therefore sit directly at the zone apex (IETF RFC 9460). A browser resolving a domain today queries A, AAAA and HTTPS in parallel and evaluates the answers together.
By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.
— IETF RFC 9460, Section 1
How relevant this has become is visible in HTTP Archive measurements. In the crawl for the Web Almanac 2024, 9 % of desktop and 10 % of mobile home pages carried the ALPN value h3 in a DNS HTTPS record, while 26 % and 28 % respectively announced HTTP/3 the classic way through the Alt-Svc header (HTTP Archive, Web Almanac 2024). The decisive figure, though, is a different one from the same analysis: roughly 99 % of the page loads actually observed over HTTP/3 were triggered by the presence of a DNS HTTPS record (HTTP Archive, Web Almanac 2024). The Alt-Svc header only takes effect on the second visit; the DNS record works on the first. For first contact, the HTTPS record is therefore the path to HTTP/3 that matters in practice.
The share of connections that benefit keeps growing: the Web Almanac 2025 reports 10.8 % QUIC on mobile and 9.5 % on desktop (HTTP Archive, Web Almanac 2025). At the same time TLS 1.3 sits at around 76 % of pages and HTTPS at 97.3 % of mobile home pages (HTTP Archive, Web Almanac 2025) — the base on which HTTPS records and Encrypted ClientHello can meaningfully build. If you want to follow the protocol choice your own site makes, our piece on monitoring HTTP/3 and QUIC covers the groundwork.
SVCB (type 64) and HTTPS (type 65) share their wire format and their parameter registry. The difference is mostly naming: SVCB expects prefix labels such as _8443._foo.example.com, while HTTPS records live under the name itself. That is why an HTTPS record works at the zone apex, where a CNAME would be illegal. For websites, type 65 is therefore the one that matters almost everywhere; SVCB shows up with DNS over HTTPS, Oblivious HTTP and similar services.
Anatomy: SvcPriority, TargetName and the parameter list
An HTTPS record has three parts. SvcPriority is a number between 0 and 65535 and simultaneously selects the mode: a value of 0 marks AliasMode, any higher value marks ServiceMode, with lower values preferred (IETF RFC 9460). TargetName names either the alias target or the alternative endpoint. SvcParams, finally, is the key-value list that carries the actual information — and that is exactly where the failures discussed in this article originate.
; ServiceMode at the apex: protocols, port, address hints and ECH keys
example-domain.com. 300 IN HTTPS 1 . alpn="h3,h2" port=443 \
ipv4hint="203.0.113.10" \
ipv6hint="2001:db8::10" \
ech="AEX+DQBBawAgACBRVO1kCb5b..."
; AliasMode: delegation to another name (CNAME substitute at the apex)
shop.example-domain.com. 300 IN HTTPS 0 edge.example-cdn.example.
; Classic address records remain mandatory (fallback path)
example-domain.com. 300 IN A 203.0.113.10
example-domain.com. 300 IN AAAA 2001:db8::10The permitted parameters are managed by IANA in a registry of its own. Thirteen keys with numbers 0 to 12 are currently assigned, the range 13 to 65279 is unassigned and only allocated after expert review, and 65280 to 65534 are reserved for private use (IANA, DNS SVCB Service Parameter Keys). Alongside the base parameters from RFC 9460 the registry now holds dohpath for DNS over HTTPS (IETF RFC 9461), ohttp for Oblivious HTTP (IETF RFC 9540), docpath for DNS over CoAP (IETF RFC 9953) and the key ech with number 5 (IANA, DNS SVCB Service Parameter Keys). The list keeps growing — and with it the number of places where a zone can drift away from reality.
| Parameter | What it controls | Typical failure mode |
|---|---|---|
| alpn | List of supported application protocols such as h3, h2, http/1.1 | Record announces h3 while the endpoint speaks no QUIC |
| no-default-alpn | Suppresses the implicit http/1.1 fallback | Set even though the endpoint still serves HTTP/1.1 |
| port | Alternative port for the endpoint | Port points at an instance without a matching certificate |
| ipv4hint / ipv6hint | Address hints that save an extra lookup | Hints lag behind the A/AAAA records after a migration |
| mandatory | Keys a client must understand, otherwise it ignores the record | Contains keys that widely deployed clients do not know |
| ech | ECHConfigList with the public keys for Encrypted ClientHello | Keys not carried over after a hosting or CDN change |
RFC 9460 is explicit: a ServiceMode record counts as compatible for a client only if that client recognises all keys marked mandatory and their values indicate that a successful connection is possible (IETF RFC 9460). Putting a young or exotic parameter in there quietly excludes every client that has not implemented it. mandatory is also automatically mandatory itself and must not appear in its own value list (IETF RFC 9460). For HTTPS records, port and no-default-alpn are automatically mandatory anyway.
How it interacts with A, AAAA and CNAME at the zone apex
AliasMode solves an old DNS problem. At the zone apex — the domain name without a subdomain — a CNAME is not allowed, because SOA and NS records must live there. RFC 9460 names this as the primary purpose: AliasMode exists to allow aliasing exactly where CNAME is ruled out (IETF RFC 9460). An HTTPS record with SvcPriority 0 points to a target name whose own records the client then resolves — recursively, with a loop limit.
What matters is what this does not replace: A and AAAA records remain necessary. Every client without HTTPS record support and every resolver that does not pass type 65 through falls back to classic address resolution. The address hints in the record are explicitly an optimisation as well. RFC 9460 states that a client should ignore the hints when A and AAAA records for the TargetName are locally available anyway, and warns that bypassing the real address answers can hurt load balancing and geo-aware features and thereby degrade client performance (IETF RFC 9460).
- Hints and address records drift apart — after a server move the A record is updated while
ipv4hintstill points at the old address. Part of the client base keeps connecting to the old IP. - AliasMode next to contradictory data — an alias HTTPS record on the same name as diverging address data produces an inconsistent picture depending on the client implementation.
- Alias chains without an end — a target that aliases again lengthens resolution and, in the worst case, runs into the loop limit.
- Wildcards — a wildcard HTTPS record also covers subdomains for which the announced parameters do not hold.
- Delegated subdomains — with outsourced services a third party maintains the zone. Changes to their HTTPS record reach your users unannounced.
Operators know this pattern from orphaned CNAME targets: an entry still points at a resource that no longer exists in that form. How that turns into a security problem is described in our piece on dangling CNAME entries and subdomain takeover. With the HTTPS record there is an extra twist — the mistake does not surface as a resolution error but as a silent loss of quality on part of the connections.
Encrypted ClientHello: the last piece of cleartext in the handshake
TLS 1.3 encrypts almost everything — with one prominent exception. Server Name Indication, through which the client tells the server which hostname it wants to reach, still travels in the clear inside the ClientHello. Anyone watching the traffic can still see which site is being visited, even though content and path are encrypted. RFC 9849 — TLS Encrypted Client Hello was published in March 2026 as a Proposed Standard and closes that gap (IETF RFC 9849). The client encrypts its ClientHello under a public server key; only an outer ClientHello with a generic public name stays visible. Connections to servers in the same anonymity set become indistinguishable from one another while the security properties of TLS 1.3 are preserved (IETF RFC 9849).
That raises the bootstrap question: where does the client get the public key before it connects? The answer is the HTTPS record. RFC 9848 — Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings, also from March 2026, defines the SvcParamKey ech, which carries an ECHConfigList in wire format, Base64-encoded in zone files (IETF RFC 9848). In the IANA registry this key holds number 5 and references RFC 9848 (IANA, DNS SVCB Service Parameter Keys). The SANS Internet Storm Center summarised the development in March 2026 as follows: the HTTPS record, previously used to negotiate HTTP/3 and QUIC, now also transmits the keys required for Encrypted ClientHello (SANS Internet Storm Center, March 2026).
The ech SvcParamKey conveys the ECH configuration of an alternative endpoint. It is applicable to all schemes that use TLS-based protocols.
— IETF RFC 9848
Operationally this creates an uncomfortable coupling. As long as every offered alternative carries an ech parameter, the client behaves in an SVCB-reliant way: it would rather abandon the attempt than send the server name in the clear (IETF RFC 9848). A stale or wrong key is therefore not a cosmetic issue but can make individual connections fail. RFC 9848 also notes that a hostile recursive resolver can always deny SVCB queries and that network intermediaries can often prevent resolution as well (IETF RFC 9848) — the DNS layer remains the breaking point.
The keys for Encrypted ClientHello travel through the very DNS whose metadata ECH is meant to protect. Without an authenticated transport — DNSSEC validation, an encrypted resolver path or both — the ech parameter can be suppressed, and depending on the setup the client either falls back to a visible SNI or does not connect at all. Anyone serious about ECH therefore monitors the signature chain and the delivery together. Our article on DNSSEC validation in monitoring shows what that looks like in practice.
A second point concerns key hygiene. ECH keys are designed to be short-lived and are rotated regularly on the provider side. As long as rotation and DNS publication stay in step, nobody notices. It gets critical when infrastructure changes: swap a termination point while the old ech value is still sitting in caches with its TTL, and you create a window with mismatched keys. Operators know the same logic from certificate replacement — except that expiry dates have been monitored there for years, while ECH keys rarely have an owner yet. Our piece on SSL certificate monitoring describes the base pattern that transfers to ECH.
Typical failure modes in HTTPS and SVCB records
Failures in this layer share one trait: they rarely produce an error message. The browser falls back, connects more slowly, picks a different protocol or fails only for one particular client type. The six patterns below cover most of what shows up in practice.
The record announces alpn=h3,h2, but the endpoint answers no QUIC connection on UDP 443. Affected are the clients that evaluate the record; everyone else connects over TCP without noticing. The result is a delay that only part of your visitors experience.
After a hosting or CDN change the old ech value stays in the zone. Clients with ECH support send an inner ClientHello the new endpoint cannot decrypt — depending on the setup the attempt is abandoned rather than quietly falling back to cleartext.
port or TargetName point at an endpoint whose certificate does not cover the requested name. The handshake fails with a name error — invisible to the operator as long as their own browser does not evaluate the record.
Some resolvers and middleboxes do not pass unknown record types through or answer with an empty result. Those users get neither HTTP/3 nor ECH even though both are published — a pure loss of visibility with no error to point at.
ipv4hint and ipv6hint still point at the old infrastructure after a migration while A and AAAA are already current. Clients that follow the hints land on the old endpoint — with all the consequences for certificate, data state and response time.
AliasMode records pointing at further aliases, or wildcards that sweep up subdomains, produce parameters that do not hold for the concrete name. Such setups usually surface only when one individual service starts stuttering.
All six patterns share one property: they hit only part of your visitors. Whether someone is affected depends on browser, version, resolver, network path and cache state. That is what makes this class of failure treacherous: in your own office, with your own corporate DNS and your own browser, it rarely shows up. It becomes visible when you measure from the outside and from several directions — the same logic that already applies to monitoring from multiple locations.
Why one vantage point is not enough for these records
DNS answers are not a global state but the sum of many independent caches. Every resolver holds entries according to their TTL, every one makes its own decisions about unknown record types, and many return geographically different answers. For ordinary A records this is well understood; we described it at length in our article on DNS propagation across multiple resolvers. For type 65 an additional uncertainty applies: support is distributed unevenly.
How unevenly is shown by a measurement that probed around 1.3 million open DNS resolvers in April 2025. Roughly 313,000 IPv4 and 8,400 IPv6 resolvers returned SVCB answers — about a quarter of the systems tested (APNIC, Nosyk, September 2025). Equally notable is the concentration: 80.8 % of those resolvers designated the same large public provider, and the five largest together accounted for 97.4 % (APNIC, Nosyk, September 2025). Monitoring that only measures against one of those providers therefore sees the majority view — and precisely not the outliers where problems arise.
That the queries themselves are everyday traffic is visible in older operational observations. The SANS Internet Storm Center analysed its own DNS logs in 2022 and arrived at roughly one HTTPS query for every four A queries; around 20 % of the answers to HTTPS queries contained any record at all (SANS Internet Storm Center, 2022). Browsers therefore ask for the record broadly, whether or not a zone publishes one. Every zone without an HTTPS record gives away the fast path to HTTP/3 — and every zone that publishes one incorrectly distributes the fault to every client that asks.
| Observation at one vantage point | Possible harmless cause | Possible fault |
|---|---|---|
| HTTPS record missing at exactly one resolver | Resolver does not pass type 65 through | Zone answers incompletely or record was removed |
| ech parameter differs per resolver | Rotation in progress, old TTL still active | Key change published incompletely |
| ipv4hint deviates from the A record | Geo DNS deliberately returns other addresses | Hint not updated after a migration |
| alpn without h3 at individual vantage points | Regional configuration without QUIC | Configuration drift between zone copies |
| Answer takes noticeably longer | Cold cache after TTL expiry | Alias chain or overloaded authoritative servers |
The table makes the real problem visible: a single deviation is rarely conclusive. Only a comparison across several resolvers, several regions and several points in time separates intended differences from genuine faults. That is the same methodological core that carries the work on hardening and checking TLS configurations.
Querying and comparing HTTPS records in practice
The starting point is an ordinary DNS query — with the difference that you state the type explicitly and put the answer up against several resolvers. The raw form of the record is more informative than a prettified view, because it shows order, priority and exact parameter values.
Comparing these answers produces the actual test catalogue. It can be automated end to end and should run at the same cadence as the rest of your DNS and domain monitoring.
- Existence and consistency — does every vantage point return an HTTPS record, and do SvcPriority, TargetName and the parameter list agree?
- ALPN against reality — is every announced protocol actually served by the endpoint? An
h3in the record without a QUIC answer on UDP 443 is a contradiction. - Address hints against A/AAAA — do
ipv4hintandipv6hintmatch the real address records, or does geo DNS explain the difference? - Certificate against TargetName and port — does the certificate served cover the name the record designates as its target?
- ech parameter — is an
echvalue present, identical at every vantage point, and does the endpoint accept a ClientHello encrypted with it? - TTL and age — how long can a wrong answer survive in the worst case? The TTL defines your reaction window.
- Fallback — does the connection still work when the record is ignored? That is the state for every client without type 65 support.
As with any DNS change: lower the TTL of the HTTPS record at least one old TTL period before a planned change — from 3,600 to 300 seconds, for instance. With ECH keys this matters even more, because a stale key sitting in a cache does not merely slow things down but can prevent connection setup for ECH-capable clients. After the change and an observation period you raise the TTL again.
Alerting on changes and following ECH rotation
An HTTPS record should change only when you want it to — with one exception: the ech parameter, which changes on schedule while key rotation is active. That distinction belongs in the alerting logic, otherwise healthy rotation produces permanent noise and a real manipulation drowns in it.
- Version the target state — keep the expected record as a reference, including priority, ALPN list, port and hint addresses. Every deviation from it needs an explanation.
- Treat ech separately — a key change is normal, the parameter disappearing is not. Alert on absence, on divergence between vantage points and on unusually frequent changes.
- Watch the rotation window — after a key change every vantage point should return the same value within one TTL period. If one lags behind, a publication or cache problem is likely.
- Treat infrastructure changes as triggers — provider migrations, new termination points and certificate replacements are the classic moments when ECH keys and HTTPS records fall out of sync.
- Report deletions like changes — a quietly removed HTTPS record costs you HTTP/3 and ECH without raising an availability alarm.
- Define escalation paths — which deviation goes to whom, and when does it escalate? That belongs in the same chain as the rest of your alerting and notifications.
A single HTTPS record decides the protocol chosen at first contact, the endpoint that gets connected to, and the confidentiality of the server name. Those three effects sit in different areas of responsibility — network, hosting and security — and are therefore often checked in full by nobody. An automated target-versus-actual comparison closes exactly that gap, without anyone having to type queries by hand every day.
Test the fallback before your visitors do
RFC 9460 distinguishes two classes of client. An SVCB-optional client can connect without ServiceMode records, an SVCB-reliant one cannot — and for pre-existing protocols such as HTTP the standard prescribes the optional behaviour (IETF RFC 9460). Operationally that means the classic path over A/AAAA and TCP has to keep working, even when the HTTPS record dominates the stage.
If any RRs are malformed, the client MUST reject the entire RRset and fall back to non-SVCB connection establishment.
— IETF RFC 9460, Section 3
That rule has an unpleasant flip side: a single malformed record in the RRset devalues the correct ones as well. Anyone maintaining several ServiceMode entries with different priorities should therefore check each one and not just the most preferred. At the same time the rule protects you: as long as classic resolution is intact, a broken HTTPS record causes quality loss rather than a total outage — with the exception of the ECH case, where the client deliberately gives up instead of revealing the server name (IETF RFC 9848).
- Measure without the record — check reachability over a path that ignores type 65. That is the view of every older client.
- Measure without QUIC — blocked UDP paths are common in corporate networks. The fallback to HTTP/2 over TCP should take hold cleanly.
- Measure with and without ECH — clients without ECH support must still be able to connect normally.
- Measure again after every deploy — zone automation, infrastructure as code and CDN configuration change records more often than the documentation suggests.
- Document the results — timestamped measurement series are the evidence that the configuration was correct at a given point in time.
That last point carries weight beyond the technology. Anyone falling under the security requirements of the NIS2 implementation needs solid evidence about the state of their publicly reachable systems — our article on NIS2 registration and management liability explains how far that documentation duty reaches. And anyone already collecting evidence for regulatory requirements, such as the transparency obligations of the AI Act, can run DNS and TLS measurements in the same reporting cycle.
Bringing HTTPS and SVCB records into continuous monitoring
The layer between DNS and TLS is no longer a footnote. It decides the protocol at first contact, the endpoint at connection setup and, since March 2026, the confidentiality of the server name (IETF RFC 9849). At the same time it is the layer with the thinnest observation coverage: a faulty HTTPS record produces no server error, no certificate alarm and no outage in the classic sense — only slower, less protected or abandoned connections for part of your visitors.
- Query the HTTPS record for every relevant name, not just the apex — subdomains, shop and API hosts included.
- Use at least three independent resolvers and several regions instead of relying on one provider.
- Version the target state and report every deviation, deletions included.
- Check ALPN entries against the protocols actually served.
- Reconcile address hints with A and AAAA records on a regular basis.
- Check ECH keys for presence, consistency and plausible rotation.
- Actively test the fallback without the HTTPS record, without QUIC and without ECH.
- Archive measurement results with timestamps so they hold up as evidence.
XICTRAQ DNS and domain monitoring queries your records regularly through several public resolvers and from several regions, compares them with the stored target state and reports every unexpected change. Together with the security scan for TLS configuration and headers and the reports and status pages, this produces a continuous view from the DNS answer through to the page delivered. The pricing overview shows scope and plans, and the live demo shows the interface. If you want to think the protocol layer further ahead, our article on the post-quantum TLS migration covers the next stage of the same chain.
This article draws on: IETF RFC 9460 — Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records), November 2023; IETF RFC 9848 — Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings, March 2026; IETF RFC 9849 — TLS Encrypted Client Hello, Proposed Standard, March 2026; IETF RFC 9461 (dohpath), RFC 9540 (ohttp) and RFC 9953 (docpath) as references for individual parameters; IANA — DNS SVCB Service Parameter Keys Registry (assignments 0 to 12, ranges for expert review and private use); HTTP Archive — Web Almanac 2024, HTTP chapter (share of DNS HTTPS records carrying h3, Alt-Svc prevalence, what triggers HTTP/3 page loads); HTTP Archive — Web Almanac 2025, Security chapter (QUIC, TLS 1.3 and HTTPS shares); APNIC — Nosyk, Discovering the Discovery of Designated Resolvers, September 2025 (SVCB answers from open resolvers, provider concentration); SANS Internet Storm Center — Encrypted Client Hello: Anybody Using it Yet? (2022) and Encrypted Client Hello: Ready for Prime Time? (March 2026).