CNAME records and aliases

A CNAME record says one name is an alias of another name.

For example:

www.example.com.  300  IN  CNAME  sites.hosting-company.test.

The resolver learns that www.example.com is an alias, then resolves the target name to the record type the client requested. The target is a hostname, not an IP address.

A CNAME is not an HTTP redirect. The browser still requests www.example.com, keeps that name in the URL, and sends it during TLS and HTTP. The hosting service must therefore recognize the original hostname and have a valid certificate for it.

A CNAME cannot coexist with other records at the same name. This is why the zone apex needs special provider features such as flattening when a platform asks for a CNAME-like setup.

The apex already needs SOA and NS records, so a standard CNAME cannot own example.com. Provider features called ALIAS, ANAME, or CNAME flattening synthesize address answers while preserving the required apex data. They are provider behavior, not ordinary CNAME records.

Avoid long CNAME chains. Every additional target can require more lookups, creates another failure dependency, and can make caching harder to reason about.

Inspect both the alias and its destination:

dig CNAME www.example.com
dig A sites.hosting-company.test
dig AAAA sites.hosting-company.test

dig +short may follow and print several values, so use the full answer when you need to distinguish the CNAME from the final addresses.

Your action is to inspect one CNAME used by a hosted service. Identify the alias owner, target, final addresses, and the service that must accept the original hostname.