· 11 min read

The apex CNAME problem is solved. Most browsers never got the memo.

RFC 9460 fixed apex aliasing in the protocol, but the clients never followed. In multi-provider DNS, where vendor workarounds are off the table, that leaves you with no fallback.

RFC 9460 fixed apex aliasing in the protocol, but the clients never followed. In multi-provider DNS, where vendor workarounds are off the table, that leaves you with no fallback.

RFC 9460 closed a gap that had been open since the early 1980s. There is finally a standards-compliant way to alias a zone apex, the one thing CNAME was never allowed to do. The fix is real, it survives DNSSEC, and it works across multiple DNS providers. There is one problem: it only works end to end when the client cooperates, and in mid-2026 most clients still do not.

If you run DNS behind a single provider, none of this matters much. You can close the apex gap with that provider’s proprietary trick and move on. If you run several DNS providers for redundancy, which any financial institution, payment processor, or public-sector operator should, those proprietary tricks fall away and you are left relying on client support that has not arrived. This post is about that gap, why it exists, and why a multi-provider architecture is exactly where it hurts.

The forty-year-old corner case

A zone apex has two jobs it cannot delegate. It carries the SOA record, the deed to the zone: who is authoritative, the serial number, the timers. It also carries the NS set, the directory of which servers answer for the zone. Both are mandatory.

CNAME cannot live next to them. The whole meaning of a CNAME is “this name is nothing but a pointer; go resolve the target and use whatever you find there.” The same way a sign on a building that reads “we have moved, everything is over there.” You cannot hang that sign on a building that is also the head office holding the zone’s deed and its directory. The two statements contradict each other, so RFC 1034 forbids CNAME from coexisting with any other record type, and RFC 1912 section 2.4 spells out the apex consequence.

Subdomains escape this limitation. The www record can be a CNAME because nothing else needs to live there. The apex cannot, and that single restriction has shaped CDN onboarding for more than two decades.

The proprietary era, and its hidden assumption

Vendors filled the gap with private machinery. Akamai built Zone Apex Mapping with its AKAMAICDN record. Cloudflare shipped CNAME flattening. Others sold ALIAS pseudo-records. They differ in detail and agree in spirit: when a query for the apex arrives, the authoritative server resolves a target hostname behind the scenes and synthesizes fresh A and AAAA answers on the fly.

That design carries an assumption people rarely say out loud. The server doing the synthesis has to be the server answering the query. With one provider, that holds and the trick works.

Add a second provider and it falls apart for two independent reasons.

The first is mechanical. A synthesized answer is computed at query time from live mapping data. You cannot write a moving target into a zone file and hand it to another provider over a zone transfer. There is nothing static to transfer.

The second is DNSSEC. A signature covers fixed bytes and is produced in advance by the key holder. An answer synthesized per query cannot be signed ahead of time, so a secondary provider has no signed answer to hand out, and a validating resolver rejects an unsigned one. Akamai laid this out in a 2020 post: a zone owner can sign the zone and use a single provider, or skip signing and spread the zone across many, but not both at once.

So proprietary apex aliasing and multi-provider DNS are mutually exclusive. That is the crux of the whole topic, and it is the reason a serious operator has no shortcut.

A signed, multi-provider zone constrains what can live at the apex: the primary transfers a signed zone to its secondaries, and only A, AAAA, and HTTPS records survive identical replication while ZAM and CNAME flattening do not.

Before the standard: two attempts that did not make it

RFC 9460 was not the first try. The IETF reached for this twice and missed.

In 2010, Ondřej Surý proposed letting CNAME itself coexist with other records at the apex, in draft-sury-dnsext-cname-at-apex. It was the most direct fix imaginable: change the rule that makes CNAME stand alone. It died on backward compatibility. Every deployed resolver already enforced the old rule, so a CNAME sitting next to an SOA would have meant one thing to updated resolvers and another to the rest of the installed base at the same moment.

The larger effort was ANAME, draft-ietf-dnsop-aname, worked on from 2017 to 2019. It defined a dedicated record that aliased only the address types and let the authoritative server, or the resolver, substitute the target’s A and AAAA at answer time. It expired without becoming a standard, and the reason matters here. ANAME put the aliasing work on the server, the same move the proprietary records make, so it inherited the same two problems: a server-synthesized answer is awkward to sign, and it does not replicate cleanly across independent providers. The working group folded the use case into SVCB, and RFC 9460 keeps a section (Appendix C.3) explaining why it chose its approach over ANAME.

The pattern is worth naming. Every attempt before SVCB tried to make the server perform the alias, which is exactly what breaks under DNSSEC and multiple providers. SVCB won by doing the opposite: a static record that the client or resolver follows. That single choice is also the root of the adoption gap in the table below. The thing that made SVCB multi-provider-safe, a brand-new record type clients must learn to follow, is the same thing that has left most clients unable to follow it.

What RFC 9460 actually fixed

The HTTPS and SVCB record types give you apex aliasing inside the protocol. Set the priority field to zero and you have AliasMode:

bank.com.   3600 IN HTTPS 0 pool.bank.com.

This coexists with SOA and NS for a simple reason: it is type-scoped. The record only answers HTTPS queries. It makes no claim over the rest of the name, so MX, TXT, and the apex’s mandatory records all keep working alongside it. CNAME claims the entire name; AliasMode claims one service.

The property that matters for redundancy is that this record is static data. You author it once, sign it, and transfer it to every authoritative provider you run. DNSSEC works because the bytes never change. Multi-provider works because there is something concrete to replicate. This is precisely the thing query-time synthesis could never offer, and it is why the standard, not the proprietary feature, is the only correct answer for a signed multi-provider apex.

The unsolved half

Here the story turns, because solving the publishing side did not solve the client side.

Two capabilities get conflated in almost every write-up. The first is consuming ServiceMode parameters: a client queries the HTTPS record and uses it to pick HTTP/3, load Encrypted Client Hello keys, or race IP hints. The second is following AliasMode: a client receives a priority-zero record and chases the target to find the address. Only the second one delivers apex aliasing. They have completely different support stories.

ServiceMode consumption is broad. Chrome, Firefox, Safari, Edge, and Opera all query HTTPS records and use the parameters. Following AliasMode is, in practice, Apple-only.

The evidence is in the browser source itself. A 2024 measurement study read the Chromium code and tested live browsers, and found that the Chromium network stack does not issue a follow-up query for an AliasMode target that differs from the queried name.1 Point an apex at an AliasMode target with no A record, and only Safari issued the second query and connected; Chrome, Firefox, Edge, Opera, and Chromium on Android queried the apex, found no address, and failed. Apple resolves HTTPS records at the operating-system layer, so every app on iOS and macOS using system networking inherits the behavior. The rest of the field does not.

The recursive resolver will not rescue you either. Public resolvers serve the record correctly, but they do not flatten an apex AliasMode into A and AAAA answers for the apex name, so a non-following browser gets nothing usable.

That was early 2024. Two years on, there is no public sign that Chromium or Firefox has started to follow AliasMode, so the mid-2026 picture is unchanged:

Client support for HTTPS AliasMode at the apex, mid-2026. Consuming ServiceMode parameters is supported across Safari, Chrome, Edge, Opera, Firefox, and Android; following AliasMode at the apex is supported only on Apple platforms, while Chrome, Edge, Opera, Firefox, and Chromium on Android do not follow it and public resolvers serve the record without rescuing non-following clients.

The gap is also hard to even discover. caniuse, the reflex place to check client support, has no entry for it: there is no page-script API that can probe HTTPS-record handling, because the work happens below the browser in the connection path. Fittingly, the request to track DNS records there (issue #6091) has sat open since November 2021, with no matrix to show.

Publishing-side adoption is just as bare. A measurement of HTTPS records in the wild found AliasMode on a few dozen apex domains per day against effectively universal ServiceMode use. Almost nobody publishes apex AliasMode, because it reaches only Apple clients and you still need A and AAAA for everyone else.

Why multi-provider designs feel it most

Consider a large bank running its own primary authoritative DNS with a third-party secondary, four authorities in total, the zone DNSSEC-signed. They want to add a CDN as a failover authority so they can shift traffic if their primary stack fails.

$ dig NS bank.com

bank.com.   300 IN NS ns1.bankdns.com.
bank.com.   300 IN NS ns2.bankdns.com.
bank.com.   300 IN NS nsa.secondary-dns.com.
bank.com.   300 IN NS nsb.secondary-dns.com.

$ dig +dnssec bank.com SOA

bank.com.   300 IN SOA ns1.bankdns.com. hostmaster.bank.com. 2026010101 3600 360 2592000 900
bank.com.   300 IN RRSIG SOA 5 2 300 ...

They cannot use the CDN’s proprietary apex feature. The zone is signed and served by multiple authorities, which rules out query-time synthesis for the two reasons above. So AliasMode is the only standards-based way to point their apex at the CDN.

But AliasMode reaches only Apple clients. The Chrome and Android majority that makes up most of the bank’s traffic will query A and AAAA at the apex and need real records there. So the operator publishes A and AAAA anyway, and that move brings back the exact problem proprietary synthesis was invented to solve. Those apex addresses have to be stable IPs the CDN will commit to, because nobody can synthesize them per query across multiple providers.

Read that sequence again, because it is the whole argument. The standards-based apex alias, in 2026, is an optimization for a minority of your users layered on top of a static A/AAAA floor you still have to engineer by hand. The record type is solved. The operational problem it was supposed to remove is still sitting there.

Where this leaves you

Publish the HTTPS AliasMode record. It is correct, it signs cleanly, it replicates across providers, and it hands your Apple users HTTP/3 and ECH at no extra cost.

Keep A and AAAA at the apex and treat them as the load-bearing path, not a legacy fallback. They carry the majority of your traffic and will keep doing so until the Chromium and Firefox network stacks learn to follow AliasMode.

If your apex sits behind a CDN that uses dynamic mapping, the question that decides everything is whether that CDN will give you a stable set of apex IPs you can hardcode and sign. That, and not the choice of record type, determines whether apex-on-CDN works in a multi-provider design.

And watch the clients, because that is where the bottleneck now lives. The IETF finished its part in November 2023. The remaining work is in the browsers and the stub resolvers, and the apex CNAME problem will stay half-solved until Chromium, Firefox, and the others decide to chase a priority-zero record.

References and further reading

Footnotes

  1. Deciphering the Digital Veil: Exploring the Ecosystem of DNS HTTPS Resource Records, arXiv:2403.15672 (2024). The authors analyzed the Chromium source as of February 2024 and ran controlled tests against current browsers, reporting that only Safari follows an AliasMode target while Chromium- and Firefox-based clients do not issue the follow-up query. https://arxiv.org/abs/2403.15672 ↩

Share:
Back to Blog