Technical
CNAME
CNAME is a DNS record that makes one name an alias for another, so the resolver restarts its lookup at the target. It lets `shop.example.com` follow whatever address the platform publishes for its own hostname.
How it is measured
`dig shop.example.com CNAME` shows the target. A plain lookup shows the chain: the CNAME line, then the A line for the target. Count the links, since each hop is another query and a long chain adds latency.
One rule matters most: a CNAME cannot share a name with any other record. That is why it cannot sit at the zone apex next to MX and NS. Check the zone editor for conflicts before saving.
Worked example
A studio points `shop.northpine.example` at a hosted shop platform's hostname with a CNAME and a TTL of 3600. When the platform moves servers, the studio's zone does not change; the A record behind the target does. Customers follow it within the hour.
The same studio tries the same trick at the bare `northpine.example`. The DNS provider refuses because MX records already live there, so they switch to the provider's flattening feature, which returns an A answer built from the target.
How it differs
A CNAME says this name is that name. An A record says this name is this address. The alias follows changes at the target on its own but cannot coexist with other record types on the same name. The A record stays fixed until you edit it.
Common errors
Putting a CNAME at the apex alongside MX records. Creating a loop where one alias points at another that points back. Leaving a trailing dot off so the target becomes `cdn.example.com.example.com`. Chaining four aliases deep. Pointing at a vendor hostname that has since been deleted, which invites a subdomain takeover.
In practice
List every CNAME in your zone this week and confirm each target still exists and is still yours to use. Delete the ones that point at cancelled services. Keep chains to a single hop where you can.