DEV Community

Cover image for CNAME Records: When and How to Use Them (With Common Pitfalls)
toolbox-poster
toolbox-poster

Posted on • Originally published at toolbox.starnomina.tn

CNAME Records: When and How to Use Them (With Common Pitfalls)

#dns #networking #webdev #devops

TL;DR
CNAME records are one of the most widely used—and most misunderstood—DNS record types. A single misconfigured CNAME can break your entire domain, enable subdomain takeovers, or silently add latency. This guide covers the syntax, restrictions, flattening workarounds, and security implications you need to know.

📑 Table of Contents

  • What Is a CNAME Record?
  • CNAME Syntax & Behavior
  • The Apex Restriction
  • CNAME + Other Records Conflict
  • CNAME Flattening & ALIAS Records
  • CNAME Chains
  • When to Use A vs CNAME
  • CDN Integration
  • Dangling CNAMEs & Subdomain Takeover
  • Best Practices
  • Common Mistakes
  • Tools
  • References

What Is a CNAME Record?

A CNAME (Canonical Name) record maps an alias hostname to a canonical (true) hostname. When a resolver encounters a CNAME, it restarts the lookup using the canonical name, ultimately resolving to an A or AAAA record.

📖 Definition — A CNAME record delegates resolution of one domain name to another. The left-hand side is the alias; the right-hand side is the canonical target. Example: www.example.com. CNAME example.com.

CNAME Syntax & Behavior 

; Zone file syntax
alias.example.com.  3600  IN  CNAME  target.example.com.

; Resolution path:
; 1. Client queries alias.example.com → resolver gets CNAME → target.example.com
; 2. Resolver queries target.example.com → gets A record → 93.184.216.34
; 3. Client receives both the CNAME and the final A record
Enter fullscreen mode Exit fullscreen mode

The resolver transparently follows the CNAME chain. Most resolvers will follow up to 8–16 CNAME hops before giving up (implementation dependent).

The Apex Restriction

RFC 1035 §3.6.2 states that a CNAME record cannot coexist with any other record type at the same name. Since the zone apex (example.com) must have SOA and NS records, you cannot place a CNAME at the zone root.

🚫 Placing a CNAME at the zone apex will break NS and SOA lookups, making your entire domain unresolvable. Some DNS providers silently prevent this, but others will accept and serve the invalid configuration.

Why This Matters

Many services (CDNs, PaaS platforms) provide a CNAME target for onboarding. For the bare domain (example.com), you need an alternative approach—see CNAME flattening below.

CNAME + Other Records Conflict

The rule is absolute: if a CNAME exists at a name, no other record types may exist at that same name. This means:

  • You cannot have both shop.example.com CNAME and shop.example.com MX.

  • You cannot have both shop.example.com CNAME and shop.example.com TXT.

  • Violating this produces undefined behavior—some resolvers return the CNAME, others return the conflicting record, and some return SERVFAIL.

CNAME Flattening & ALIAS Records

To work around the apex restriction, several DNS providers offer proprietary solutions that resolve the CNAME target at query time and return the resulting A/AAAA records directly:

Provider Record Name How It Works
Cloudflare CNAME Flattening Automatically resolves CNAME targets at the apex and returns A/AAAA
AWS Route 53 ALIAS Native record type that resolves AWS endpoints (ELB, CloudFront, S3) at query time
DNSimple ALIAS Server-side resolution of CNAME targets, returns A/AAAA to clients
NS1 ALIAS / Linked Records Supports ALIAS at apex with health-check integration

ℹ️ ALIAS/ANAME is not yet an official RFC standard, though draft-ietf-dnsop-aname is in progress. Provider implementations may differ in edge cases.

CNAME Chains

A CNAME chain occurs when a CNAME target is itself a CNAME: a → b → c → IP. While technically valid, chains add latency (one extra round-trip per hop) and increase fragility. Keep chains to a maximum of one hop in configurations you control.

When to Use A vs CNAME

Scenario Use Why
Zone apex (example.com) A / AAAA CNAME is prohibited at the apex
Subdomain pointing to CDN/PaaS CNAME Provider manages underlying IPs; CNAME follows changes automatically
Subdomain pointing to a static IP you control A No benefit to indirection; A is one fewer lookup
Multiple subdomains to the same host CNAME Single point of update if the IP changes

CDN Integration

Most CDN providers (Cloudflare, Fastly, Akamai, CloudFront) require you to create a CNAME pointing your subdomain to their edge hostname. This allows the CDN to:

  • Route requests to the nearest edge PoP via anycast or GeoDNS on their side.

  • Rotate edge IPs without requiring DNS changes on your end.

  • Issue and renew TLS certificates via domain validation (DCV) on the CNAME target.

Dangling CNAMEs & Subdomain Takeover

A dangling CNAME points to a resource that no longer exists—such as a deleted Azure Web App, Heroku app, or S3 bucket. An attacker can claim that resource and serve content under your subdomain.

🚫 Subdomain takeover is a real and actively exploited vulnerability. Audit your CNAME records whenever you decommission cloud services. Automated scanners like subjack and can-i-take-over-xyz can detect vulnerable configurations.

Best Practices

  • Never place a CNAME at the zone apex—use ALIAS/flattening or A records.

  • Limit CNAME chains to one hop maximum in your own zones.

  • Remove CNAME records immediately when decommissioning the target service.

  • Use CNAME for subdomains pointing to externally managed infrastructure (CDNs, SaaS).

  • Document every CNAME with a comment in your zone file or DNS management tool.

Common Mistakes

Mistake Impact Fix
CNAME at zone apex SOA/NS lookups break; domain becomes unresolvable Use A record or provider ALIAS/flattening
CNAME + MX at same name Mail delivery fails unpredictably Move mail to a dedicated subdomain or use A records
Dangling CNAME after service deletion Subdomain takeover vulnerability Audit and remove CNAMEs when decommissioning
Long CNAME chains (3+ hops) Added latency; fragile resolution Point directly to the final canonical name
Missing trailing dot in zone file Name is interpreted as relative, appending zone origin Always use FQDN with trailing dot in zone files

Tools

CNAME Lookup — Resolve full CNAME chains and detect dangling records.

DNS Lookup — Query any record type to verify CNAME coexistence rules.

References

  • 📄 RFC 1035 — Domain Names: Implementation and Specification (§3.6.2 CNAME)

  • 📄 RFC 1912 — Common DNS Operational and Configuration Errors

  • 📄 draft-ietf-dnsop-aname — Address-specific DNS Aliases (ANAME)

🎯 Key Takeaway: 🎯 CNAME records are powerful aliases—but respect the rules: never at the apex, never alongside other record types at the same name, and never left dangling after a service is removed. Use flattening for apex needs and audit regularly for takeover risks.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

Top comments (0)