DNS

CNAME record

A practical field guide to CNAME record, including an operational example, common misconceptions, troubleshooting checks, and primary references.

Updated

Definition

A Canonical Name record makes its owner name an alias for a target name. With limited DNSSEC-related exceptions, other data should not coexist at the same owner name.

In practice

Follow an alias to its address

Synthetic example: www.example. is an alias for app.example. The alias and target are separate record sets with independent TTLs.

  1. The zone publishes: www.example. 300 IN CNAME app.example.

  2. The target publishes: app.example. 60 IN A 192.0.2.20. This is a documentation address, not a live service.

  3. Query dig @<lab-resolver> www.example. A +noall +answer. A recursive answer can include both the CNAME and target A record.

  4. After changing the target A record, account for its cached TTL; changing the CNAME itself has its own cache lifetime.

Common misconceptions

What this does not mean

A CNAME is an HTTP redirect.
DNS supplies another domain name to resolve. It does not change the browser URL, HTTP path or TLS certificate requirements.
A normal zone apex can contain a CNAME alongside SOA and NS.
A CNAME owner cannot have other ordinary data, apart from DNSSEC-related exceptions. A normal zone apex needs SOA and NS records, so provider-specific ALIAS/flattening features are different mechanisms.
Field checks

A practical review order

  • Use fully qualified targets with a final dot in zone-file examples.
  • Check the entire alias chain for loops, missing targets and unexpectedly long chains.
  • Check both the alias TTL and the target record TTL when explaining a migration.