A Record vs CNAME: When to Use Each

## A Record vs CNAME: When to Use Each Two of the most common DNS record types are the A Record and the CNAME Record. Both ultimately get visitors to your server, but they work differently and have different constraints. Choosing the wrong one causes subtle breakage — especially at the root domain. ## What Is an A Record? An A Record (Address record) maps a hostname directly to an IPv4 address. It is the most fundamental DNS record type. ``` example.com. 3600 IN A 203.0.113.10 www.example.com. 3600 IN A 203.0.113.10 ``` When a DNS Resolver looks up `example.com`, it receives `203.0.113.10` and connects to that server. Resolution is a single lookup — fast and direct. For IPv6, the equivalent is the AAAA Record: ``` example.com. 3600 IN AAAA 2001:db8::1 ``` Best practice is to publish both A and AAAA records so your site is reachable over IPv4 and IPv6. ## What Is a CNAME Record? A CNAME Record (Canonical Name record) maps one hostname to *another hostname*, not to an IP address. The resolver must then look up that second hostname. ``` www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME mysite.netlify.app. ``` In the second example, when someone visits `blog.example.com`, the resolver sees the CNAME and then resolves `mysite.netlify.app` to get the final IP. This two-step lookup is called *CNAME chaining*. CNAMEs are powerful when your hosting provider's IP can change. Instead of updating your A record every time the provider updates their infrastructure, your CNAME always points to their current address. ## The Key Difference: IP vs Hostname | Feature | A Record | CNAME | |---------|---------|-------| | Points to | IPv4 address | Another hostname | | Lookup steps | 1 | 2+ | | Root domain (`@`) | Yes | No (RFC restriction) | | Can coexist with other records | Yes | No (exclusive) | | Common use | Root domain, direct servers | Subdomains, hosted services | ## Why You Cannot Use a CNAME at the Root Domain This is the most common pitfall. RFC 1034 states that a CNAME Record cannot coexist with any other record at the same name. Since your root domain (`example.com`) always needs NS and SOA records — and typically MX records for email — placing a CNAME at the root would violate this rule and break email delivery. In practice, DNS software handles this differently — some silently ignore the MX records, others refuse to create the CNAME — but the result is always broken email or broken name resolution. **The workaround:** Use an A (or AAAA) record at the root. If your hosting provider's IP changes, update the A record manually, or use a provider that supports "CNAME flattening" (also called ALIAS or ANAME records). Cloudflare, NS1, Route 53, and others offer this as a proprietary extension — they resolve the CNAME target at query time and return the resulting IP, making it behave like an A record at the root. ## When to Use an A Record Use an A record when: - You are pointing the **root domain** (`example.com`) to a server you control - You have a **static IP address** that will not change - You want **one lookup step** for maximum speed - You are setting up Reverse DNS (PTR Record) (PTR records always reference A records) Example: a VPS, dedicated server, or bare-metal machine with a fixed IP is perfect for an A record. ## When to Use a CNAME Use a CNAME when: - You are configuring a **subdomain** (`www`, `blog`, `app`) pointing to a third-party service - Your hosting provider's IP **changes without notice** (CDNs, PaaS platforms, managed hosting) - You want changes on the provider's end to **automatically reflect** without touching your DNS Common CNAME targets include: - `myapp.netlify.app` (Netlify) - `myapp.vercel.app` (Vercel) - `myapp.github.io` (GitHub Pages) - `myapp.azurewebsites.net` (Azure) - `d1234.cloudfront.net` (CloudFront CDN) All of these services manage their own IP addresses. If you used an A record pointing to their current IP, it might break silently when they rotate infrastructure. ## CNAME Chains: Be Careful A CNAME can point to another CNAME, creating a chain: ``` blog.example.com. CNAME alias.example.com. alias.example.com. CNAME mysite.netlify.app. mysite.netlify.app. A 104.198.14.52 ``` Each hop requires an additional DNS lookup. RFC 1034 does not define a maximum chain length, but many resolvers enforce a limit (typically 8–10 hops) and abort beyond that. Keep chains short — ideally zero or one hop. ## Performance Considerations The extra lookup step in a CNAME adds latency only if the target hostname is not already cached by the resolver. With typical TTL values and warm caches, the difference is negligible for users. Still, for latency-critical infrastructure (financial systems, real-time APIs), A records eliminate that variable. ## Practical Examples **Hosting a static site on Netlify with a custom root domain:** ``` example.com. A 75.2.60.5 # Netlify's load balancer IP (check their docs) www.example.com. CNAME yoursite.netlify.app. ``` **Pointing multiple subdomains to the same service:** ``` api.example.com. CNAME myapp.herokuapp.com. app.example.com. CNAME myapp.herokuapp.com. admin.example.com. CNAME myapp.herokuapp.com. ``` Using CNAMEs here means you only update one record (the Heroku target) if you move services. ## Summary Use **A records** for root domains and any hostname with a stable, server-controlled IP. Use **CNAME records** for subdomains pointing to third-party services whose IPs may change. Never place a CNAME at the root domain unless your DNS provider supports CNAME flattening. Verify your records with the DNS Record Helper tool, and read Setting Up DNS for Your Domain if you are building your DNS configuration from scratch.