DNS record types
CNAME records and aliases
Point one name to another name while respecting the rule that a CNAME cannot share its owner name with other data.
A CNAME record says “this name is an alias of that other name”. It points a name to a name, never to an IP address.
Here’s one:
www.example.com. 300 IN CNAME sites.hosting-company.test.
When a resolver sees this, it learns that www.example.com is an alias. It then resolves the target, sites.hosting-company.test, for whatever record type the client asked for. Ask for A and you get the target’s A records.
This is how most hosting platforms work. You point www at their hostname, and they manage the addresses behind it. When they change servers, you don’t touch anything.
A CNAME is not a redirect
This one confuses a lot of people. The browser never sees the CNAME. It still requests www.example.com. The URL bar still says www.example.com. The TLS handshake and the HTTP Host header carry www.example.com.
So the hosting service on the other end must know about your hostname and have a certificate for it. If you only add the CNAME and skip the “add custom domain” step at the host, you’ll get a certificate error or a “site not found” page. DNS is fine. The host doesn’t recognize you.
The rule that bites at the apex
A CNAME can’t share its name with any other record. If www.example.com is a CNAME, it can’t also have an A, TXT, or MX record.
Now think about the apex, example.com. Every zone must have SOA and NS records at the apex. So a standard CNAME at the apex is impossible.
Providers solve this with features called ALIAS, ANAME, or CNAME flattening. You configure something that looks like a CNAME, and the provider resolves the target itself and serves plain A and AAAA answers. The apex keeps its required records. This is provider behavior, not a real CNAME. Cloudflare does this automatically.
Keep chains short
A CNAME can point to another CNAME. Avoid it when you can. Every hop is another lookup, another thing that can fail, and another TTL to reason about.
Inspect alias and target
Let’s look at both ends:
dig CNAME www.example.com
dig A sites.hosting-company.test
dig AAAA sites.hosting-company.test
Be careful with dig +short here. It follows the alias and prints the final addresses mixed with the target name. Use the full output when you need to tell the CNAME apart from the addresses behind it.
Try this on a CNAME from a hosted service you use. Find the alias owner, the target, the final addresses, and the service that has to accept your original hostname.
Lesson completed