Stop putting CNAMEs at the root

Using a CNAME record at the apex (example.com.) seems like a shortcut. It looks tidy. It even resolves in some resolvers. But the DNS standards forbid it, and the result is brittle systems that fail at the worst possible times.

This post traces the problem from the standards, through resolver behavior, to operational failures in real deployments. Then it covers the sanctioned alternatives.

1. Standards Prohibition

The prohibition is explicit in the DNS specifications.

RFC 1034, Section 3.6.2:

If a CNAME RR is present at a node, no other data should be present.

RFC 1912, Section 2.4:

A CNAME record is not allowed to coexist with any other data.

The apex of a zone always has other data: at minimum SOA and NS records. Publishing a CNAME there violates the rule, instantly.

This was not an afterthought. The rule was deliberate, to preserve consistency in how resolvers handle canonical names.

2. Why the Apex Cannot Be a CNAME

Every zone apex is a structural anchor in the DNS tree. It must:

• Publish SOA for administrative boundaries.
• Publish NS for delegation.
• Optionally publish MX for mail.
• Often publish TXT for policies (SPF, DMARC, ACME).

A CNAME asserts that the apex is merely an alias of some other node. That contradicts its role as a delegation and policy anchor. The standards writers chose clarity over convenience: no CNAME at the apex.

3. Resolver Behavior in Practice

When confronted with a CNAME+other data at the apex, resolvers diverge:

• BIND (most widely deployed authoritative software) returns the CNAME but discards coexisting records.
• Microsoft DNS refuses to load the zone at all.
• Unbound (popular validating resolver) may reject the answer as bogus under DNSSEC.
• dnsmasq and other lightweight resolvers cache inconsistently.

This means two users querying the same domain may see different results, depending on which resolver path they hit. Intermittent failures are the hardest to diagnose in production.

4. The Mail Problem

Mail is the most obvious casualty. An apex CNAME prevents publishing MX records:

example.com. 3600 IN CNAME myapp.provider.net.
example.com. 3600 IN MX 10 mail.example.com.

Per RFC, this is illegal. Most resolvers discard the MX. Result: mail sent to [email protected] bounces or disappears.

This is not theoretical. Several high-profile startups have cut off their own email flow by deploying apex CNAMEs for web traffic.

5. The TXT Problem

Modern services depend on TXT at the apex:

• SPF (v=spf1 …)
• DMARC (v=DMARC1 …)
• ACME DNS-01 challenges for TLS automation

An apex CNAME forbids coexistence, breaking authentication, spam filtering, and certificate issuance.

6. Historical Context

When DNS was designed (1983–1987), canonical names were meant to ease migration and renaming. A CNAME is a pointer, not an override. The apex, by contrast, is a root of authority. Mixing the two would have undermined consistency of delegation and administrative control.

That’s why the rule in RFC 1034 was unambiguous from day one.

7. Why People Still Try It

Cloud and SaaS providers almost always provision customer resources under provider-owned domains:

customer123.hostedservice.net.

For a subdomain like www.example.com, a CNAME works perfectly. But many organizations want their brand at the root (example.com). Without ALIAS/ANAME, the temptation is to copy the CNAME into the apex.

It appears to work for HTTP traffic. But the collateral damage to mail, authentication, and DNSSEC lurks in the background.

8. Real-World Outages

• Startups on Heroku: Early Heroku docs encouraged apex CNAMEs. Customers reported mail blackholes until Heroku adopted ALIAS records and clarified documentation.
• ACME / Let’s Encrypt: Users who tried to place CNAMEs at apex failed DNS-01 validation, breaking automatic certificate renewal.
• Enterprise migrations: Organizations moving to CDN frontends with apex CNAMEs found SPF and DMARC invalidated, resulting in widespread mail rejections.

These failures were not rare edge cases. They were systemic.

9. Workarounds That Work

a) ALIAS / ANAME / Flattening

DNS providers introduced pseudo-records that look like CNAMEs but are resolved to A/AAAA before publication.

• AWS Route53: ALIAS
• Cloudflare: CNAME flattening
• NS1: ANAME

These satisfy standards because the apex node still carries SOA/NS. The indirection is hidden from the resolver.

b) Direct A/AAAA

If your service has fixed IPs (common for load balancers but rare for CDNs), publish them directly. But beware: if the provider rotates IPs, you now own monitoring and updates.

c) Subdomain CNAME + Redirect

The cleanest DNS option:

• Point www.example.com at provider via CNAME.
• Redirect apex traffic (example.com) to www.

This preserves mail and TXT integrity, requires minimal DNS trickery, and follows web convention.

10. The DNSSEC Complication

DNSSEC signing makes apex CNAMEs even more toxic. A CNAME at apex conflicts with required NSEC/NSEC3 records. Validating resolvers can and do reject such answers as “bogus.” If your domain is signed, you will see resolution failures immediately.

11. The Cloud Tradeoff

Vendors prefer to give you a stable DNS name they control, rather than expose raw IPs. This gives them elasticity, failover, and DDoS defense. The tension is: DNS standards vs. cloud convenience.

The industry compromise has been ALIAS/ANAME. If your DNS host doesn’t support them, you are forced back to A/AAAA or redirect.

12. Recommendations

1. Never deploy a raw CNAME at the apex. It is forbidden by RFC 1034/1912 and will break.
2. Use ALIAS/ANAME/flattening if your DNS provider offers them.
3. If not available, use a www subdomain with a redirect from apex.
4. Avoid publishing IPs unless unavoidable. You will inherit operational burden.
5. If migrating providers, test mail and TXT services after DNS changes—don’t assume web tests are enough.

13. Final Word

The DNS standards community made this call nearly 40 years ago. The prohibition is not an outdated artifact. It protects interoperability across billions of clients and thousands of resolver implementations.

Shortcuts at the apex will keep working “until they don’t.” And when they fail, it won’t be obvious why.

Stop putting CNAMEs at the root. Use the sanctioned patterns. Keep your domain stable.