CNAME: canonical name (alias)

One name, aliased to another: any lookup of the alias follows to the target and gets back whatever is there. Not a redirect: the resolver follows it transparently.

What it holds#

One name: the target, also called the canonical name (RFC 1035 §3.3.1).

www.example.com.   CNAME  example.com.
example.com.       A      192.0.2.1

A query for www.example.com A returns both records in one answer. When the alias and target share a zone, the authoritative server itself restarts the query and returns both; across zones, the resolver does the follow-up lookup itself (RFC 1034 §3.6.2). A query for the CNAME type itself is never restarted: it gets back only the alias record.

When to use it#

• Tracking one canonical name and pointing others at it.
• Pointing a subdomain at a SaaS provider's hostname so the provider can serve content under your name.
• Pointing at a CDN (www.example.com to your-zone.cdn-provider.net).

When not to use it#

• Never at the zone apex. RFC 1034 §3.6.2 and RFC 2181 §10.1 forbid a CNAME coexisting with other data at the same name, and the apex must carry SOA + NS. Some managed DNS providers work around this with CNAME flattening: the CNAME is resolved server-side at lookup time, and only A/AAAA records go on the wire.
• When you need multiple targets: CNAME can only point at one name. Use multiple A/AAAA records or service-discovery records (srv) instead.
• When the target does not exist or breaks: every lookup of the alias inherits the failure. A non-existent target returns NXDOMAIN, a target with no records of the requested type returns NODATA (NOERROR, empty answer, RFC 2308 §2.2), and an unreachable authoritative returns SERVFAIL. There is no fallback in any case.

dig example#

$ dig @1.1.1.1 cname.example.isitdns.net A

DoH query (HTTPS)#

DNS-over-HTTPS (DoH) wraps a normal DNS query in an HTTPS request. The application/dns-json format is a Cloudflare/Google extension; it is not defined by RFC 8484:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=cname.example.isitdns.net&type=CNAME' \
  | python3 -m json.tool

{
    "Status": 0,
    "TC": false,
    "RD": true,
    "RA": true,
    "AD": true,
    "CD": false,
    "Question": [
        {
            "name": "cname.example.isitdns.net",
            "type": 5
        }
    ],
    "Answer": [
        {
            "name": "cname.example.isitdns.net",
            "type": 5,
            "TTL": 300,
            "data": "example.isitdns.net."
        }
    ]
}

AD: true means the resolver validated the DNSSEC chain for this answer (RFC 4035 §3.2.3); you are trusting its validation over the DoH channel rather than doing your own.

Gotchas#

• The "no other records at the same name" rule. A CNAME and an A at the same name is a zone-file error. Every well-behaved authoritative server rejects the second one. If you need an A and an alias, give the alias a different name. The one exception: in a DNSSEC-signed zone, RRSIG and NSEC records coexist with the CNAME (RFC 4035 §2.5).
• MX and NS targets must not be aliases. The domain name in MX or NS RDATA must be a name with address records, not a CNAME (RFC 2181 §10.3). Point MX and NS at the canonical name itself.
• CNAME chains. A points to B points to C points to A. RFC 1034 §3.6.2 requires a loop to be signalled as an error; resolvers do this by capping how many hops they follow and returning SERVFAIL past the cap. Loops usually form across zones under different control; nothing in the protocol stops one from being published. Chained (non-looping) CNAMEs are legal: each hop adds a record and, where the hop crosses into an uncached zone, an extra lookup. dig-along walks a live chain step by step.
• CAA on the target. A CAA lookup for a name follows its CNAME the same way any other query does, so the CAA record that applies is the one at the final target (RFC 8659 §3). See caa.

See also#

• When it actually is DNS: common CNAME-chain failures
• All record types: cheat sheet