A Record vs CNAME: When to Use Each DNS Record
An A record maps a hostname straight to an IPv4 address in a single lookup. A CNAME maps it to another hostname and follows that target's addresses — legal on subdomains, never at the root. Own stable servers get A records; IPs you do not control get a CNAME.
For anyone pointing a domain at hosting, a CDN or a platform and deciding which DNS record to set.
knowledge
- Read time
- 3 min
- Sections
- 7
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What an A record does: name to IPv4 address
An A record answers "where does this hostname live?" with an IPv4 address in a single lookup — the shortest path DNS offers. Write webji.in. A 203.0.113.10 and any resolver that finds your name servers returns that address directly, with nothing further to chase. (IPv6 uses the AAAA record, which behaves identically for the purposes of this comparison.)
Two properties make A records the default for infrastructure you control. First, one name may carry several A records — one per IP address — and resolvers rotate among them, a simple round-robin load balance. Second, an A record happily coexists with other records at the same name, so webji.in can hold its A record plus the MX records that route mail and the TXT records that carry SPF. The cost is vigilance: when the server's IP changes, you must edit the record yourself.
What a CNAME does: name to another name
A CNAME answers "where does this hostname live?" with "wherever that other hostname lives" — the resolver follows the alias to its canonical target and resolves that instead. Write cdn.webji.in. CNAME cdn-provider.net and the address handed to visitors is whatever the provider's hostname currently resolves to, even if it changed this morning. That automatic follow is the entire point: CDNs and cloud platforms change edge IPs constantly, and they cannot ask thousands of customers to keep editing A records.
The price is a protocol restriction: a CNAME must be the only record at its name. No MX, no TXT, nothing alongside it — because the CNAME legally replaces the name's entire record set with the target's. It also costs at least one extra lookup on every first visit, so keep chains short; a CNAME pointing at a CNAME adds a hop each time. The full record zoo is mapped in DNS records explained.
| Dimension | A record | CNAME |
|---|---|---|
| Points to | IPv4 address | Another hostname |
| Legal at the zone apex (root)? | Yes | No — protocol forbids it |
| Follows target IP changes | No — manual edit | Yes, automatically |
| Other records at the same name | Allowed (MX, TXT…) | Forbidden — must stand alone |
| Lookups to resolve | One | At least one extra |
| IPv6 sibling | AAAA | Same mechanism |
The root-domain CNAME restriction, explained properly
A CNAME at the zone apex is a protocol violation because the apex must hold the SOA and NS records that identify the zone — and a CNAME, by definition, may not share its name with any other record. The two requirements cannot both be true, so the DNS specifications rule the combination out and most control panels reject the attempt outright. This is the rule behind every confused forum thread titled "CNAME not allowed at root".
- Apex (webji.in): an A record to your server IP — or provider-side flattening where the DNS host supports it.
- www (www.webji.in): a CNAME to the apex, or to your host's hostname; then redirect one to the other so a single canonical name survives.
- Ordinary subdomains (shop, blog, staging): CNAME freely to platform hostnames — no restriction applies here.
- Verification conflicts: a TXT record at a name you also wanted as a CNAME is exactly the coexistence rule biting — move one of them to a nested name or switch to A records.
ALIAS, ANAME and CNAME flattening at the apex
CNAME flattening is the DNS industry's workaround for the apex restriction: the DNS host resolves the CNAME target on its own authoritative servers and answers queries with plain A/AAAA records, so the name behaves like a CNAME while staying legal at the root. Depending on the provider it is labelled an ALIAS record, an ANAME record, or simply a "flatten CNAME at apex" toggle in the zone editor.
Two caveats govern real deployments. Resolution happens from the provider's servers, so a CDN target doing geo-routing sees the provider's vantage point, not your visitor's — edge selection can land farther away than the marketing suggests. And support varies: confirm the feature exists in your zone editor before planning a full-site CDN on the naked domain, because without it the apex must keep a plain A record. Propagation of any change here follows ordinary DNS timing — the DNS propagation checker shows where a change has reached, and the propagation guide explains the TTL mechanics.
Which record for hosting, CDN, www and email
Match the record to what the service hands you: an IP address means an A record, a hostname means a CNAME, and mail is unaffected by either because MX records do their own routing. The four common setups resolve as follows.
| Scenario | Records to set | Why |
|---|---|---|
| Shared hosting that gives an IP | A at apex; www CNAME to apex | The IP is yours to state; www can follow the apex |
| Host that gives a hostname | CNAME on subdomains; A (or flattening) at apex | Subdomains may alias; the apex still cannot |
| CDN in front of the site | Subdomains CNAME to the edge hostname; apex via flattening | Edge IPs change without notice |
| Email on the domain | MX records wherever mail is hosted | Mail routing ignores A/CNAME choices |
The zone you edit lives at whichever DNS host the domain's name servers point to — set the name servers at the registrar, then edit records only in that panel, as the change nameservers guide walks through. The zone itself is part of your domain registration; the site and its mail can live on different hosts without conflict.
How to verify your records after setting them
Confirm with a query rather than a browser: dig shows exactly what resolvers see, including whether a name returns an address or an alias. Run these from any Linux or macOS terminal; on Windows, nslookup -type=CNAME cdn.example.com is the equivalent of the second command.
dig example.in A +short
dig cdn.example.in CNAME +short
dig www.example.in A +shortThe first command should print the IPv4 address from your A record; the second prints the alias target on a CNAME-backed name; the third printing an address on a www name that only carries a CNAME proves the alias chain works end to end. If a change does not appear, it is almost always TTL caching or the wrong panel — check propagation before editing again.
Frequently asked questions
Can a CNAME point to an IP address?
No. A CNAME's target must be a hostname — following another name is its entire job. To point a name directly at an address, use an A record for IPv4 or an AAAA record for IPv6. A CNAME "pointing at an IP" is simply a misconfigured record that will not resolve.
Why is a CNAME not allowed on the root domain?
The zone apex must carry SOA and NS records that establish the zone's authority, and usually MX and TXT records too. A CNAME must be the only record at its name, so the two cannot coexist — the specifications forbid the combination and most panels reject it. Use an A record at the apex, or flattening if your DNS host supports it.
What is CNAME flattening, exactly?
The DNS provider resolves the alias target on its own authoritative servers and returns plain A/AAAA answers to the world. Visitors and resolvers see a normal A record, while you manage a hostname that follows the target's IP changes — CNAME behaviour made legal at the apex. Look for it as ALIAS, ANAME or a flatten toggle in the zone editor.
How many A records can one hostname have?
As many as needed — one per IP address — and resolvers rotate among them (round-robin). What a name cannot do is mix a CNAME with anything else: a CNAME must stand alone at its name, which is why verification TXT records and CNAMEs clash.
Do A or CNAME records affect email?
No. Mail routing is decided by MX records at the name that receives mail, plus SPF/DKIM/DMARC in TXT records. You can change a site's A or CNAME records without touching mail, provided you do not carelessly add a CNAME at a name that carries MX records — which the coexistence rule blocks anyway.
Last editorial update: 15 November 2026. Record behaviour follows the DNS specifications (RFC 1034 and RFC 1912 §2.4 on the CNAME exclusivity rule) and current control-panel behaviour.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.