Your hosting platform tells you to point your domain at yourapp.hostexample.net with a CNAME. It works for www, then your DNS provider refuses when you try the same on the bare example.com. That isn't the provider being awkward. It's a rule as old as DNS, and knowing why it exists makes the workarounds much easier to choose between.
Most explanations say a CNAME "points one name at another". That's true, but it hides the detail that causes all the trouble. A CNAME doesn't redirect a particular kind of lookup. It says this whole name is an alias, and every question about it should be asked of the target instead.
www.example.com. 3600 IN CNAME site.hostexample.net.When a resolver asks for the A record of www.example.com and finds that CNAME, it restarts the query for site.hostexample.net. The same happens for AAAA, MX, TXT or any other type. Ask for www.example.com's TXT records and you get site.hostexample.net's TXT records.
You can see the alias and where it leads with dig:
dig www.example.com CNAME +short
dig www.example.com AThe second command shows the CNAME in the answer section, followed by the A records of the target.
RFC 1034, section 3.6.2, says: "If a CNAME RR is present at a node, no other data should be present." RFC 2181 (section 10.1) tightened that up. A name either has one CNAME record or it has other records, never both. DNSSEC signature records are the only exception.
That follows directly from how a CNAME works. If www.example.com were an alias and also had its own TXT record, a resolver asking for TXT couldn't know which answer you meant.
Now look at the apex, the bare example.com. It always has records of its own. Every zone has an SOA record and NS records at its apex, because that's how DNS knows who's authoritative. Most domains also keep MX, SPF and verification TXT records there. A CNAME can't share a name with any of that, so it can't live at the apex. That's all there is to it.
Our DNS record types guide covers the basics of each record. This rule is the one that bites hardest in practice.
Most DNS providers reject a CNAME at the apex. A few older or self-hosted setups will accept it, and that's worse, because it looks fine until something asks the wrong question.
Email goes somewhere else. When a mail server looks up your MX record and finds a CNAME, RFC 5321 says to treat the target name as if it were the original. So your mail follows the alias to site.hostexample.net's MX records. That means mail meant for you goes to your web host's mail setup, or bounces. Your own MX records, if they're still in the zone, get ignored or cause errors depending on the server.
TXT records vanish. SPF records and domain-verification tokens at the apex are TXT records. With a CNAME at the apex, resolvers return the target's TXT records instead of yours, so SPF fails and verification checks can't find their tokens.
Resolvers disagree. Because the zone breaks the rules, different resolvers and caches handle it differently. You can end up with a domain that works from one network and not another, which is miserable to debug.
The same rule applies below the apex too. If shop.example.com is a CNAME, you can't add a TXT verification record to shop.example.com as well. That's a common surprise when a service asks you to verify a subdomain you've already pointed elsewhere.
ALIAS, ANAME or CNAME flattening. Many providers offer a pseudo-record that you configure like a CNAME but which gets served as ordinary A and AAAA records. The provider looks up the target itself and answers with the resulting addresses, so the apex keeps its SOA, NS, MX and TXT records. Cloudflare calls this CNAME flattening and applies it at the apex automatically. Route 53 has alias records, which work for AWS resources like CloudFront and load balancers. Others call it ALIAS or ANAME.
Two trade-offs are worth knowing. These records aren't part of the DNS standard, so they don't survive a move to another provider unless the new one has an equivalent. And the provider resolves the target from its own servers, so a CDN that picks an edge by resolver location sees the provider's location rather than your visitor's. Most large CDNs cope with this, but it's worth testing.
Use the A records your host gives you. Many platforms publish fixed apex IP addresses, often anycast, specifically for this. Put those in A (and AAAA) records at the apex and CNAME www to the platform's name. You lose the automatic follow-along if the host changes addresses, but those apex IPs are usually meant to stay stable.
Redirect the apex to www. Make www.example.com the real site, CNAMEd to the platform, and have the apex do nothing but a 301 redirect to it. You still need A records at the apex pointing at something that serves the redirect, but many registrars and DNS providers offer that as a built-in forwarding feature.
HTTPS records. The HTTPS record type from RFC 9460 has an "alias mode" designed to allow CNAME-like behaviour at the apex without breaking other records. Browser support for the alias form is still limited, so treat it as a complement to one of the options above, not a replacement.
After changing the apex, confirm three things: that the apex returns addresses, that your mail records are still there, and that www points where you intended.
dig example.com A +short
dig example.com MX +short
dig example.com TXT +short
dig www.example.com CNAME +shortOur DNS lookup will show the apex's A, MX and TXT records from a browser. If you've just made the change, use DNS propagation with the CNAME type on www to see whether resolvers around the world have picked it up.
Yes, and it usually should be when your host gives you a hostname. www is an ordinary subdomain with no other records of its own, so the rule doesn't get in the way. Just don't add TXT or MX records to www as well.
It behaves like one when you set it up, but on the wire it isn't one. Resolvers only ever see A and AAAA records. That's exactly why it's allowed at the apex, and also why it only works on providers that support it.
Yes. Resolvers follow the chain, but every hop is another lookup and another chance for something to break, so keep chains short. A CNAME that points at the name it came from, directly or via other names, is a loop and fails outright.
It shouldn't. RFC 2181 says the name in an MX record must not be an alias, so point MX records at a hostname that has its own A or AAAA records. Our guide to MX records covers the other rules that trip up mail setups.
0 comments
No comments yet. Be the first.