is it dns? / wiki ← back to the live monitor

CNAME: canonical name (alias)

One name → another name. A CNAME says: for any lookup of this name, follow me to that other name, and use whatever record types are over there. It is not a redirect: it is an alias that the resolver follows transparently.

Type number5
RFC1035
RDATAA single canonical name (FQDN)

What it holds#

One name: the target (or "canonical name"). The resolver, when it sees a CNAME in a response, follows it: it asks for the same record type again at the target.

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

A lookup for www.example.com A returns:

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

Two records in one answer: the chase happened upstream. When the alias and target live in the same zone, the authoritative server itself restarts the query at the target and returns both (RFC 1034 §3.6.2); when the target is in another zone, the resolver does the follow-up lookup.

When to use it#

  • Any time you want to track one canonical name and point others at it.
  • Pointing a subdomain at a SaaS provider's hostname (status.example.com to your-page.statuspage.io) 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 have SOA + NS, so it cannot be a CNAME. Workarounds:
    • CNAME flattening: some managed DNS providers do this server-side: they follow the CNAME at lookup time and return the resulting A/AAAA records directly. The published record looks like a CNAME at the apex, but on the wire it is an A.
    • ALIAS / ANAME records: non-standard provider features that do the same thing.
  • 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 name does not exist or breaks: every lookup of the alias inherits the failure. The exact result depends on what broke: a non-existent target returns NXDOMAIN, a target with no records of the requested type returns NODATA (NOERROR, empty answer), and an unreachable authoritative returns SERVFAIL. There is no fallback in any case.

dig example#

Watch the chase happen. One A query for the alias comes back with both records:

dig @1.1.1.1 cname.example.isitdns.net A
;; QUESTION SECTION:
;cname.example.isitdns.net.	IN	A

;; ANSWER SECTION:
cname.example.isitdns.net. 300	IN	CNAME	example.isitdns.net.
example.isitdns.net.	300	IN	A	192.0.2.1

Both TTLs read 300 because this lookup was fresh; repeat the query and the cached values count down.

nslookup -type=A cname.example.isitdns.net 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
cname.example.isitdns.net	canonical name = example.isitdns.net.
Name:	example.isitdns.net
Address: 192.0.2.1

dig +short shows just the CNAME hop and the resolved address, one per line:

dig @1.1.1.1 cname.example.isitdns.net A +short
example.isitdns.net.
192.0.2.1

nslookup has no equivalent of dig +short. Its output always includes the server header and canonical-name line.

You can also query only the CNAME record itself, without chasing it to an A. Servers never restart a query that asks for the CNAME type itself (RFC 1034 §3.6.2):

dig @1.1.1.1 cname.example.isitdns.net CNAME +short
example.isitdns.net.
nslookup -type=CNAME cname.example.isitdns.net 1.1.1.1
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
cname.example.isitdns.net	canonical name = example.isitdns.net.

Authoritative answers can be found from:

The teaching zone also publishes a two-hop chain: chain.example.isitdns.net aliases to cname.example.isitdns.net, which aliases to example.isitdns.net. Every hop adds a record to the answer, and an extra lookup for the resolver whenever a hop crosses into a zone it has not cached:

dig @1.1.1.1 chain.example.isitdns.net A +short
cname.example.isitdns.net.
example.isitdns.net.
192.0.2.1

dig-along walks this chain step by step.

Apex CNAME, broken in practice#

RFC 1034 §3.6.2 forbids a CNAME at the zone apex: the apex must have SOA + NS, and CNAME cannot coexist with other records at the same name. Every well-behaved authoritative server rejects it.

Some managed DNS providers implement CNAME flattening: a zone configured with an apex CNAME target gets resolved server-side, and only A/AAAA records are emitted on the wire. As a zone configuration concept it might look like:

example.com.  CNAME  example.cdn-provider.net.

But on the wire, no CNAME comes back. The authoritative resolves the target's A/AAAA server-side and returns those directly. Resolvers see plain A records; nothing breaks the RFC because the CNAME never leaves the authoritative. The flattening happens at the authoritative, not in transit.

Several other DNS providers offer the same trick under different names (ALIAS, ANAME). None of them are standardized in an RFC.

nslookup cannot show this distinction. Since no CNAME record is present on the wire after flattening, any A query returns only A records regardless of the tool you use.

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, but it is convenient and widely supported:

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."
        }
    ]
}

The AD: true field confirms the response passed DNSSEC validation end-to-end.

nslookup cannot do DoH, DoT, or DoQ. On Windows 11, Resolve-DnsName uses the OS-configured DoH resolver when the OS is set up for encrypted DNS; it does not accept a -DnsOverHttps parameter or let you specify an arbitrary DoH endpoint. To probe a specific DoH endpoint, use the curl form above.

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. Resolvers detect loops, cap how many hops they will follow, and return SERVFAIL. Loops usually form across zones under different control (provider A aliases to provider B, which aliases back); nothing in the protocol stops one from being published.
  • CAA on the target. When a CA validates a CAA record, it walks the CNAME chain: the CAA on the target applies. Surprising the first time it bites. See caa and [the Cloudflare-side behavior][cf-caa-chain].
  • DNSSEC. A CNAME chain that crosses zones means the resolver needs to validate each zone independently. A signed-then-unsigned hop loses the AD flag. The curl DoH example above (with AD: true) confirms that cname.example.isitdns.net stays within the signed isitdns.net zone, so validation succeeds end-to-end.
  • Proxied CNAMEs. Works fine for non-apex names at managed DNS providers that proxy traffic. At the apex, providers that support flattening resolve the CNAME server-side: see the apex section above.

[cf-caa-chain]: https://developers.cloudflare.com/ssl/edge-certificates/caa-records/

See also#