You've opened the DNS panel, pointed the domain to the new server, and the browser still gives ERR_NAME_NOT_RESOLVED. Or worse: the site comes up but works on www and not on the domain without www. In nine out of ten cases where I've seen this symptom, someone has put a CNAME record on the domain root (zone apex). This is forbidden per RFC 1034 and RFC 2181, and some DNS providers won't even let you save it; others save it and then behave unpredictably during resolution.
Why CNAME doesn't work on the domain root
Every DNS zone must have SOA and NS records at its apex. If you put a CNAME on that same name, you've said "whatever this name has is actually another name" — and that contradicts the existence of SOA. The result is that resolvers, depending on their implementation, either ignore the SOA or see the entire zone as broken.
The symptom isn't always the same. Sometimes dig responds but the browser doesn't. Sometimes the domain's MX record stops working and emails bounce silently, because a CNAME on the root also calls the MX into question. This is the worst case: the site looks healthy and transactional email dies three days later.
When an A record is the right answer
For the domain root, an A record (or AAAA for IPv6) is the default choice. If the server IP is static, just set this and you're done:
example.com. 3600 IN A 185.xxx.xxx.xxx
www.example.com. 3600 IN CNAME example.com.The number 3600 is the TTL, in seconds. Before any migration, lower it to 300 seconds and wait a day. If you keep the TTL at 86400 and then change the IP, for a full day some users will go to the old server and some to the new one. This difference is exactly what creates "the site opens for some people and not for others."
When the IP isn't static: ALIAS and ANAME
The real problem starts when you don't have an IP. On a CDN, on a cloud load balancer, or on services whose IP changes every few weeks. Here you can't set a static A, because every time the IP changes you'd have to manually edit DNS.
The standardized solution is ALIAS (some providers call it ANAME). This record is resolved at the zone level, not at the user's resolver level. That is, your DNS server itself goes and looks up the destination and returns the final IP as an A. From the user's perspective, it's an ordinary A record.
| Record | On root | On subdomain | Hidden cost |
|---|---|---|---|
A | Yes | Yes | If IP changes, needs manual editing |
CNAME | No | Yes | One extra hop in resolution |
ALIAS | Yes | Yes | Depends on the DNS provider |
If your domain's DNS doesn't have ALIAS and you don't want to change nameservers, the third option is to move DNS to Cloudflare or Route 53, both of which have this record. Here my choice is clear: if you have a static IP, set an A and don't think about anything else. If you have a dynamic IP, ALIAS is worth changing nameservers for.
The hidden cost of one extra hop
Every CNAME adds an extra lookup step to the resolution path. For one domain this number is negligible, about 20 to 50 milliseconds under normal conditions. But if you build a chain, it's a different story:
a.example.com CNAME b.example.com
b.example.com CNAME c.example.com
c.example.com CNAME target.cdn.netHere the resolver has to ask three times in a row. Some resolvers cut the chain after 8 to 10 hops and return SERVFAIL. If you've put a CNAME on www and also defined another CNAME inside the CDN, you may approach this limit. Keep the chain short; one hop, not three.
This is where people go wrong: many think that because CNAME "automatically follows the IP," it's always a safer option than A. Then they put it on the root and spend three hours looking for the problem in the server firewall. The sign is that dig +short example.com responds on your system but not on a phone with mobile internet. The discrepancy between resolvers is the signature of an illegal record on the root.
How to diagnose it in practice
Before any change, look at the current state. These three commands clarify almost everything:
dig +noall +answer example.com A
dig +noall +answer www.example.com CNAME
dig +trace example.comThe first command should return an A record. If it returns a CNAME, that's the problem we described. The third command shows the full resolution path from the root servers to your zone, and if the chain is broken somewhere, it'll be exposed right there. To check DNS propagation in different parts of the world, you can also use ServerNet's free tools.
Another practical point: check the TTL before the change, not after. If the current TTL is 86400 and you've just changed the record, for the next 24 hours you're in a half-migrated state and there's nothing you can do but wait. Factor this into your migration plan, or you'll face half your traffic on the first night.
Other records on the same name
A limitation that's less often mentioned: any name that has a CNAME cannot have any other record. Not MX, not TXT, not SRV. If you put both a CNAME and an MX on mail.example.com, some mail servers reject the message and others silently send it to the spam folder. For email subdomains, always set an A.
The same rule applies to domain verification records. If you put a Google Workspace verification TXT or an SSL certificate on a name that has a CNAME, verification fails and the error message is usually cryptic. First remove the CNAME, set the TXT, get verification, then restore it if needed.
For WordPress sites, these settings are usually done once and then forgotten until the day the server changes. If you're on Linux hosting and the server IP is static, the same A record is enough and you don't need more complexity. ServerNet's technical documentation in the knowledge base also has the DNS configuration details for each service.
Frequently asked questions
Can I put a CNAME on the domain root?
No, per the DNS standard this isn't allowed and it conflicts with the SOA and NS records. Some panels let you save it, but resolvers don't behave consistently toward it and the result is scattered, hard-to-diagnose errors. For the root, use A or ALIAS.
What's the difference between ALIAS and CNAME?
CNAME is resolved on the user's resolver side and returns another name; ALIAS is resolved on your DNS server side and delivers the final IP as an A. That's why ALIAS is allowed on the domain root and CNAME isn't. ALIAS support depends on your DNS provider.
Why does the site open on www but not on the main domain?
It almost always means the www record is configured correctly but the root record is missing or wrong. Check with dig +noall +answer example.com A; if the output is empty, add the root record. If it returns a CNAME, remove it and replace it with an A.
What number should I set the TTL to?
Under normal conditions, 3600 seconds is reasonable. Before a migration or IP change, lower it to 300 seconds and wait at least one full previous TTL period. After it stabilizes, you can raise it again. A permanently low TTL increases your DNS query count and is significant on high-traffic sites.
If you're dealing with this right now, first check the current state with dig and then decide. In most cases the answer is a simple A record; only add complexity where the IP truly isn't static.
Comments 0
No comments yet — be the first!