DNS CNAME record

A resolver asked for the address of a name with a CNAME receives the alias, then repeats the lookup for the target, then returns the target's address. The client sees the final answer and normally never knows an alias was involved.

Each step is a real lookup that can be cached independently, with its own time to live. A short-lived alias pointing at a long-lived target behaves differently from the reverse.

Chains are legal — an alias pointing at another alias — and each additional link costs another resolution. Two is common in hosted setups; more than that is worth questioning.

The delegation of control is the point: once `www` is a CNAME to a provider's hostname, the provider can change addresses, add regions and fail over without you touching your zone.

The rule is that if a name has a CNAME, that is the only record it may have. It is not a convention; resolvers rely on it, and violating it produces inconsistent answers between implementations.

The apex of a domain necessarily carries NS records and an SOA record. Those cannot be removed, so the apex can never be a CNAME.

That collides with a common requirement: a domain that must serve at `example.com` as well as `www.example.com` and be hosted behind a CDN.

The same rule bites on a subdomain used for email: a name with MX records cannot also be a CNAME, which is why an aliased subdomain sometimes silently stops receiving mail.

Redirect the apex to `www` at the HTTP level and put the CNAME on `www`. This is standards-compliant and costs one redirect on the first request.

Use a provider's apex alias feature — ALIAS, ANAME, or a CNAME flattening option — where the DNS server resolves the target itself and returns an A record. Behaviour and refresh intervals vary by provider.

Publish A records at the apex pointing at addresses the provider gives you, accepting that you must update them if the provider changes them.

All three are in use on large sites. The first is the only one that involves no provider-specific behaviour.

`dig www.example.com CNAME +short` prints the target, or nothing if the name is not an alias.

`dig www.example.com` without a type shows the full chain: the CNAME, then the target's records, in the order the resolver followed them.

If a name unexpectedly resolves somewhere else, look for a CNAME before suspecting the address records — an alias added years ago is easy to forget.

Check that a name carrying MX or TXT records is not also a CNAME. Some providers accept the configuration in their interface and produce a zone that does not behave as expected.