Summary

  • CNAME made one DNS owner name an alias to exactly one target. To prevent the alias and its destination from giving conflicting answers, the alias owner could not also carry ordinary A, MX, TXT, NS or other application data.
  • A resolver caches the CNAME and restarts the lookup at the target. The source zone controls the detour; the target's authority controls the eventual data; neither act is a delegation, identity proof or service guarantee.

One name wanted to perform two incompatible jobs

Suppose portal.example is published as a CNAME for service.example.net. A client asks for its address. The source server can return the alias instruction and the resolver can continue at the target. Now imagine that the source also publishes its own A record for portal.example. Which address should a cache trust: the one attached to the old name, or the one reached by following the alias?

The original DNS refused to leave that conflict to preference. In RFC 1034, published in November 1987, Paul Mockapetris defined CNAME as a special resource record. Its owner name is the alias; its RDATA names the canonical destination. If CNAME is present at a node, no other ordinary data should be present there.

This was more than tidy zone-file style. The specification gave two architectural reasons. Data for a canonical name and its aliases must not diverge. And a resolver that has cached the CNAME must be able to use it without asking the source authority whether another record type at the same owner would contradict the detour.

Exclusivity therefore created a small piece of authority. The cached CNAME does not say what address, mail exchanger or service exists. It says where the resolver must resume asking.

The answer changed the question

CNAME does not simply return a second spelling as inert data. It changes DNS processing. If the requested type is not CNAME, RFC 1034 tells the name server to copy the CNAME RR into the answer, replace the working QNAME with the target name and return to the beginning of the lookup algorithm. A query for CNAME itself is the exception: the caller asked to inspect the detour, so resolution does not follow it.

Modern terminology in RFC 9499 makes the movement visible. The original QNAME is the name placed in the question. An effective QNAME is any name actually resolved after a CNAME step. The final QNAME is the last name in the chain. A single DNS response may echo the original question while carrying an answer whose owner is the final name.

That distinction matters when the end fails. The alias may exist and be answered authoritatively even when the target is absent, temporarily unreachable or controlled by a different zone. A negative result at the final QNAME does not retroactively prove that the original alias never existed.

A detour was not a delegation

DNS delegation and DNS aliasing both make a resolver continue elsewhere, but they transfer different things. An NS RRset at a zone cut identifies the servers that hold authority for a descendant zone. A CNAME remains data published by the authority for its own source name. It instructs the resolver to start another lookup; it does not hand the source zone to the target operator.

The source-zone administrator can create, change or remove portal.example and choose its TTL. The operator authoritative for service.example.net controls the target's A, AAAA or other terminal data and their TTLs. The source does not acquire authority over the target by pointing at it. The target does not acquire authority to edit the source alias.

RFC 6604 later clarified status handling across CNAME and DNAME chains. A response can be authoritative for the alias step and still contain a referral or failure arising later. Authority over the first statement is not authority over the whole journey.

One alias, one target—not one machine, one name

The word “canonical” invited an overreach. It could sound as though DNS permitted every host or interface only one official name. RFC 2181 rejected that inference. DNS imposes no general one-name identity rule on a host.

The narrower rule is exact: one CNAME owner has one canonical target. RFC 2181 also warns that calling the owner “a CNAME” can obscure the direction. The owner is the alias; the domain name inside the record is the canonical name for that alias operation.

This precision separates protocol state from identity claims. Several domain names can legitimately lead toward the same service. A name can also carry multiple ordinary RRsets when it is not an alias. What it cannot do is declare itself a CNAME detour and simultaneously act as an independent destination.

Why the zone apex could not take the shortcut

The exclusivity rule creates a familiar structural consequence. A zone apex must carry SOA and NS data. Since a CNAME owner cannot also carry those ordinary records, the apex cannot be an ordinary CNAME.

RFC 1912 recorded how dangerous the tempting configuration could be. Its historical BIND example placed CNAME beside apex NS records; the server could prefer the CNAME and ignore the other resources, making the names beneath the zone disappear. The exact behavior belongs to the implementations of that period, but the conflict belongs to the data model itself.

Services that synthesize address answers or “flatten” an apex may offer useful product behavior. They do not change what a CNAME RR on the wire means. Calling every provider convenience “an apex CNAME” erases the very distinction operators need when diagnosing authority and caching.

Some target positions could not tolerate an alias

The rule also reaches records that contain other domain names. RFC 2181 says an NS target and the exchange part of an MX record must not be aliases. Queries for NS and MX prompt additional-section processing: the server can append address records for the named server or exchanger. That processing does not chase a CNAME and then append addresses for the canonical target.

Using an alias in those positions adds queries and network load; in hard cases, especially around delegation, the missing address can make resolution fail. The administrator who writes the NS or MX data is expected to resolve the alias once and publish the direct name that owns address records.

This is not a universal ban on domain names pointing to other names. It is a rule about where an implicit extra resolution step would undermine a protocol path that depends on predictable address discovery.

DNSSEC added proof without restoring a second destination

The phrase “no other data” acquired an important qualification as DNSSEC evolved. RFC 2181 allowed the security records of its time beside CNAME. RFC 4034 later required RRSIG and NSEC records at a CNAME owner in a signed zone.

Those records do not compete with the target. RRSIG authenticates the CNAME RRset; NSEC participates in authenticated denial and type evidence. They prove the state of the alias node. They do not give that node an independent address, mail route or text payload.

RFC 4033 keeps the security claim bounded. DNSSEC supplies data-origin authentication, integrity and authenticated denial when validation succeeds. It does not make the target an authenticated application, a healthy service, a contractual counterparty or the legal owner of the source name.

Chains were tolerated, loops were not

One alias may lead to another. RFC 1034 advises against multiple levels because every step adds work, yet it does not make a finite chain an error. Resolvers must instead catch loops and aliases that end at nonexistent names and return an error condition to the client.

The operational object is therefore a graph, not a string substitution. Each edge has an owner, an authority, a TTL and possibly a DNSSEC state. The last name has its own records and lifetime. A chain that worked from one cache can fail from another while old edges expire at different times.

That is the price of decoupling. A source operator can move a familiar name without duplicating target data. A target operator can change addresses without editing every aliasing zone. But each side can also change independently, and caches preserve their earlier statements until the applicable TTL expires.

Minimal coordination survived by refusing mixed truth

CNAME solved a distributed-maintenance problem with a deliberately thin primitive. The shared protocol did not need a global registry of equivalent names or a central adjudicator of which address was “really” attached to an alias. It needed one unambiguous edge that any resolver could cache and follow.

The exclusivity rule is the constitutional centre of that design. The source name may be a detour or a destination, but not both. Once it chooses the detour, its authority is real and narrow: publish one target, preserve the chain's evidence, and leave the destination's data to whoever controls the destination.

Sources and limits

The original model and resolution algorithm come from RFC 1034 and RFC 1035. Operational errors and naming clarifications come from RFC 1912 and RFC 2181. DNSSEC exceptions come from RFC 4033 and RFC 4034; chain status and present terminology come from RFC 6604 and RFC 9499. These documents do not establish current deployment share, provider-specific flattening, resolver chain limits, dangling-alias prevalence, application ownership or the availability of any present service.