skip to content

When a recursive DNS resolver looking up www.example.com receives a CNAME pointing into another zone, how does it assemble the final answer?

level: middleimportance: should knowfreq 32%

answer

  1. an alias is not an address
  2. change the name, start again
  3. possibly a second walk
  4. the chain rides in the answer
  5. unless the type was CNAME

basics

~20 s

The resolver caches the CNAME, switches the name it is resolving to the CNAME's target and restarts there, walking to the target zone's servers if needed. The stub then gets one answer section: the CNAME record followed by the target's records.

solid answer

~50 s

A CNAME says its owner is an alias for another name, the canonical name. RFC 1034 section 5.3.3 step 4(c) tells the resolver: if the response shows a CNAME that is not itself the answer, **cache the CNAME, change the name being resolved to the canonical name, and go back to step 1**. Step 1 checks the cache, and if the target lies in another zone the resolver may need new referrals, even a fresh walk from the root. When done, it replies to the stub with the **original question** and an answer section holding the CNAME followed by the target's records, which is how RFC 1034 section 4.3.1 describes a recursive response: the answer, possibly prefaced by the CNAME records met on the way. A query for the CNAME type itself is not chased. Chains are followed; loops must be caught and reported as errors.

go deeper

for a junior

Recall that a CNAME is an alias, that the resolver follows it for you, and that the reply lists the alias before the final address.

for a middle

Explain the restart in the resolver's loop, the second walk a cross-zone target can need, and why a CNAME-type query is not chased.

for a senior

Show the trust rule for target data bundled with the alias, how loops and missing targets surface to clients, and how chains through several zones add cold-cache latency and dependencies.

for a principal

Weigh aliasing into another operator's zone for convenience against the added lookup cost and the new failure dependency on that operator's name servers.

## What a CNAME says A **CNAME** record declares its owner name to be an **alias** and names the **canonical name** in its data. RFC 1034 section 3.6.2 adds that if a CNAME is present at a node, no other data should be present there, so a cached CNAME can be used "without checking with an authoritative server for other RR types". Which names may hold a CNAME, and the zone-apex restriction, belong to DNS record types; here the question is what the resolver does when it meets one. ## The restart Take a recursive resolver asked for the `A` record of `www.example.com`, where `www.example.com` is a CNAME for `web.example.net`. 1. The resolver walks to an authoritative server for `example.com` and asks for `www.example.com`, type `A`. 2. That server finds a CNAME at the name. Per RFC 1034 section 4.3.2 it copies the CNAME into the answer and restarts its own lookup at `web.example.net`. It is not authoritative for `example.net`, so it usually has nothing more to add. 3. The resolver applies RFC 1034 section 5.3.3 step 4(c): **cache the CNAME, change the name being resolved to `web.example.net`, go back to step 1**. 4. Step 1 checks the cache for `web.example.net`. With a cold cache, step 2 finds the best known servers for it, which may be only the root, so a **second walk** follows: root, then `net`, then the `example.net` servers. 5. The `example.net` server returns the `A` record with AA set. 6. The resolver returns to the stub a single response that keeps the **original question** and lists the chain in order. ```dns ;; recursive resolver's reply to the stub ;; QUESTION SECTION: www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN CNAME web.example.net. web.example.net. 60 IN A 203.0.113.10 ``` RFC 9499 names the two halves: **QNAME (original)** is the name asked, and **QNAME (final)** is "the last name in a CNAME chain response". ## When the target data arrives in the same response If one server is authoritative for both the alias and the target, its restart in step 2 finds the target's records too, and it returns the whole chain. RFC 1034 says the resolver restarts at the CNAME "unless the response has the data for the canonical name". Trust is the catch: - RFC 1035 says the **AA bit** corresponds to the name matching the query or the first owner name in the answer section. - RFC 2181 section 5.4.1 adds that when the name sought is an alias, "only the record describing that alias is necessarily authoritative", and a client that needs authoritative data "should query again, using the canonical name". A careful resolver therefore accepts target data only from a server it has reason to trust for that name, and otherwise chases the target itself. ## Chains, loops and dead ends - **Chains** (an alias to an alias) must be followed. RFC 1034 says multiple levels "should be avoided due to their lack of efficiency, but should not be signalled as an error". - **Loops** (an alias that leads back to itself) and aliases pointing at names that do not exist "should be caught and an error condition passed back to the client". - **A missing target** yields the CNAME plus a name error: RFC 1034 section 4.3.1 lists a name error that "may include CNAME RRs", and RFC 2308 notes the NXDOMAIN then refers to the target. What that response code means belongs to the DNS message format. - **A query for type CNAME** is not chased. RFC 1034 section 3.6.2 says queries "which match the CNAME type are not restarted", so a client can ask whether an alias exists; its example adds that a `*` query should likewise return just the CNAME. ## Why it matters in production Each hop into another zone can cost more referrals on a cold cache. After the first walk the resolver already knows the root servers and the first TLD's servers, so the extra cost depends on where the target lives: | Where the CNAME target lives | Extra servers asked on a cold cache | |---|---| | No alias at all | None | | The same zone as the alias | Usually none: that zone's server returns the chain itself | | Another zone under the same TLD | That TLD's server, then the target zone's server | | A zone under a different TLD | A root server, that TLD's server, then the target zone's server | Every further link in a chain repeats the calculation. A name aliased through two or three separately operated zones depends on all of them being reachable. The stub sees none of this; it receives one response with the whole chain, which is why RFC 1034 describes recursive service as returning the answer prefaced by the aliases met on the way.

  • Why does a DNS resolver not follow the alias when a client queries www.example.com for type CNAME?
    RFC 1034 section 3.6.2 says queries that match the CNAME type are not restarted. The client is asking whether the name is an alias and what it points to, so the CNAME record itself is the answer; chasing it would return data about a different name than the one asked.
  • What does a DNS recursive resolver return when the CNAME target does not exist?
    The CNAME in the answer section together with a name error. RFC 1034 section 4.3.1 lists a name error that may include CNAME RRs showing the original name was an alias for a name that does not exist, and RFC 2308 notes the NXDOMAIN refers to the target, not the alias.

saying these in an interview costs you the question

  • The resolver returns only the CNAME and the stub must resolve the target.
  • The question section of the final response is rewritten to the canonical name.
  • A CNAME chain is a protocol error that resolvers must reject.
  • Target records supplied by the alias's server are always authoritative.
  • Following a CNAME never needs a new walk, since the first server knows the target.