Why a CNAME works on www but not on the root
A CNAME says one name is an alias for another. When someone looks up www.example.com and finds a CNAME to site.host.example.net, the resolver carries on and asks for the addresses of site.host.example.net. The benefit is that your host can change its IP addresses without you touching anything.
The price is exclusivity. RFC 1034, section 3.6.2, says that if a CNAME is present at a name, "no other data should be present". RFC 1912 spells out the consequence: a name that is a CNAME cannot also hold other records such as MX or TXT.
That rule collides with the root of a domain, also called the apex or the zone apex. RFC 1034, section 4.2.1, says the top of every zone holds the NS records listing its name servers and one SOA record. Those records must be there, so a CNAME cannot be. Your root domain usually carries MX and TXT records for email as well. A name such as www has no such duties, which is why it takes a CNAME without trouble.
- www.example.com: a CNAME is the standard choice
- blog.example.com or any other subdomain: same, provided nothing else is on that name
- example.com, the root: no standard CNAME; use one of the options below
Find where your DNS actually lives
Records only count at the provider your nameservers point to, and that is not always the company you bought the domain from. If you edit a zone at your registrar while the domain's nameservers point elsewhere, nothing changes and nothing warns you. Ask the public DNS first.
The names that come back tell you where to log in. A result ending in cloudflare.com means your records are edited at Cloudflare, for example, whoever sold you the domain.
If you decide to move nameservers at the same time, do that as a separate job. Cloudflare's troubleshooting page warns that DNS resolution fails if DNSSEC is left on at your domain provider when you add the domain to Cloudflare, and every other record in the zone has to be copied across, including your email records.
- Mac or Linux: dig @1.1.1.1 example.com NS +short
- Windows: nslookup -type=NS example.com 1.1.1.1
- Log in to the provider those names belong to, and open the DNS records for your domain
Add the CNAME for www, step by step
Your host gives you the target, a hostname of its own. If it offers a temporary address, build and test the site there first, so visitors reach a working site the moment DNS changes.
A live domain needs one extra step a day ahead: lower the TTL on the existing record. TTL is the number of seconds resolvers may keep reusing an answer, so the old value decides how long the previous address lingers after you make the change. Lowering it at the last minute does nothing for answers that are already cached.
Then clear the name and create the record. Cloudflare will not let you create a CNAME beside another record on the same name, and other panels may let the conflict through, so check by hand. A registrar's parking page is the usual leftover. Remove old AAAA records along with old A records, because a stale AAAA keeps visitors on IPv6 going to the old server.
- Type: CNAME
- Name or Host: www. Many panels add your domain for you, so typing the full name can create www.example.com.example.com
- Target or Value: the hostname from your host, on its own. No https://, no path and no port, because DNS deals only in names
- TTL: a low value while you are moving, or the provider's automatic setting
- Proxy, on providers that have one: off for now, as explained under HTTPS below
Four ways to handle the root domain
Visitors will type example.com, so it has to go somewhere. Which option fits depends on what your DNS provider supports.
ALIAS or ANAME is a provider feature that looks like a CNAME in the panel and answers like an address record. DNSimple's documentation describes looking up the target's current A and AAAA addresses and returning them, so resolvers see ordinary address records and MX and TXT records on the same name keep working. Namecheap documents ALIAS on the @ host and advises removing any CNAME, URL Redirect, A or AAAA records on that host first.
CNAME flattening is Cloudflare's version of the idea. You enter a CNAME at the root, and Cloudflare looks up the final IP address and returns that instead. Its documentation says this happens by default on all plans for a CNAME at the zone apex. The target must resolve, because a target with no A or AAAA records produces an empty answer that can look like a record that has not propagated.
The name alone does not promise the same thing everywhere. Amazon calls its alias records a Route 53 specific extension, limited to selected AWS resources and other records in the same hosted zone, and not to a record of type CNAME. So on Route 53 an alias cannot follow a hostname at an outside host.
Redirecting the root to www works with any DNS provider, using a forwarding service, and it makes www your one real address. Use a permanent 301 that keeps the path and query string, so example.com/about lands on www.example.com/about. Cloudflare publishes this as a ready example and requires traffic for that hostname to be proxied, so the root needs a proxied record, while www can stay DNS only. Registrar forwarding varies more, and it needs testing on https as well as http: Namecheap's article, for instance, says switching between HTTP and HTTPS on the same domain takes another method, and that redirecting one https domain to another needs certificates on both.
An A record is the last option, if your host publishes a stable IP address for this purpose. It is standard DNS and works everywhere. The catch is the one a CNAME avoids: if the address changes, your site goes with it until you update the record by hand.
- ALIAS or ANAME: best if your provider offers it and it can target an outside hostname
- CNAME flattening: built in on Cloudflare
- Redirect the root to www: works when the first two are unavailable
- A record: only with a stable IP address from your host
Check it, and fix what the answer shows
Test the records instead of reloading the browser, which has its own cache. The CNAME check should return your host's hostname. If the root is flattened or uses ALIAS, a CNAME query for it returns nothing, and that is correct: check the A record instead.
When public resolvers disagree with your panel, ask your own nameserver directly, using a name from the NS check. Cloudflare notes that this bypasses resolver caching. If the record is right there, your work is done and caches simply need to expire.
One waiting game catches people out. If anything looked up the name before the record existed, resolvers may have cached the fact that it does not exist. RFC 2308 sets that period as the lower of the SOA's MINIMUM field and the SOA's own TTL. Cloudflare points out that lowering the TTL on your record does not shorten it. Its test is dig +noall +answer +authority www.example.com: an SOA in the authority section means the negative answer is still cached.
- Mac or Linux: dig www.example.com CNAME +short
- Windows: nslookup -type=CNAME www.example.com 1.1.1.1
- Root domain: dig example.com A +short
- Your own nameserver: dig @ns1.yourprovider.example www.example.com
- Redirect: curl -I http://example.com, then the same with https://, and read the status and Location lines
- Nonexistent domain or NXDOMAIN: the name has no record yet, is misspelled, or was edited at the wrong provider
- Old address still returned: the old TTL has not run out, or a leftover record remains
- Error 1014 on Cloudflare: Cloudflare prohibits a CNAME between domains in different Cloudflare accounts, and its stated fix is on the target domain's side, so contact whoever runs the target
HTTPS, proxies and your email
DNS only gets visitors to the server. The certificate is the next step, and it depends on DNS being right. With Let's Encrypt's HTTP-01 method, the certificate authority connects to your hostname on port 80 and fetches a token. It follows up to 10 redirects, and that method cannot issue wildcard certificates. So the certificate can only exist once the name reaches your host, which makes a certificate error straight after a DNS change normal. Some hosts issue it automatically once the record resolves, and others need you to add the hostname in their panel or ask them.
Each name needs covering. If both example.com and www.example.com serve the site, the certificate has to include both. If the root redirects through a forwarding service, then that service has to answer https on the root.
A proxy changes what visitors reach. With a Cloudflare record set to proxied, a query for the name returns Cloudflare's addresses and traffic passes through Cloudflare first. With DNS only, it returns the real target and traffic goes straight to your server. Keep the record DNS only until the site works over HTTPS, then turn the proxy on if you want it.
CAA records are rarer. A CAA record names the certificate authorities allowed to issue for your domain, and Let's Encrypt says site owners who do not use CAA usually have nothing to do. If you have one and your host uses Let's Encrypt, it needs an issue record for letsencrypt.org.
Email is separate and easy to protect. A CNAME on www has no effect on the MX records that route your mail. The risk sits at the root: a true CNAME there would conflict with MX and TXT, which is one more reason to use the options above and leave your email records alone.
- Point DNS first, then expect the certificate
- Proxy off until HTTPS works
- Keep port 80 reachable: HTTP-01 validation can only use that port
- Leave MX, SPF and DKIM records exactly as they are
- Point MX records at a real mail hostname, not at a CNAME, as RFC 1912 advises
The same steps on Puranode website hosting
Every Puranode website server has its own hostname under sites.puranode.com, ready for testing with HTTPS before your domain is involved. How web hosting works covers the rest of the setup.
To bring your domain, create a CNAME at your DNS provider with your sites.puranode.com address as the target, then email hello@puranode.com with the hostname. We add it to the proxy and issue a Let's Encrypt certificate. Keep that order, because validation checks the live name over HTTP, and leave any proxying mode off until HTTPS works.
For the root domain, use ALIAS, ANAME or CNAME flattening if your provider has it, and otherwise put the site on www and redirect the root. Each hostname you add has its own record and its own certificate. Your MX records stay exactly as they are, since the CNAME has no effect on them. See the web hosting page for the details of each plan.