DNAME Records vs CNAME: Redirecting an Entire Subtree

A CNAME redirects a single name to another single name. But what if you need to redirect every name under a branch of your namespace at once, so that www.old.example, mail.old.example, and anything else below old.example all map to their counterparts under a new name? Creating a CNAME for each one does not scale and misses names you have not thought of. The DNAME record solves exactly this: it remaps an entire subtree with one record. This guide explains how DNAME works, how resolvers synthesize CNAMEs from it, how it differs from a plain CNAME, and the real cases where it is the right tool.

CNAME: one name to one name

A CNAME, or canonical name record, says that one domain name is an alias for another. A query for the alias returns the target's records. The critical limitation is scope: a CNAME affects only the exact name it sits on. A CNAME at old.example.com does nothing for www.old.example.com, because that is a different name. CNAMEs also cannot coexist with other records at the same name, which is why they are forbidden at a zone apex.

; CNAME: only this exact name is aliased
old.example.com.   IN  CNAME  new.example.net.
; www.old.example.com is NOT affected by the line above

DNAME: one subtree to another subtree

A DNAME record, defined in RFC 6672, redirects a subtree of the namespace. It is placed at a name, and it remaps everything below that name to the corresponding names under a target. Crucially, a DNAME does not redirect the owner name itself, only its descendants. A DNAME at old.example.com redirects www.old.example.com, a.b.old.example.com, and every other descendant, but not old.example.com itself. If you need the apex of the subtree redirected too, you pair the DNAME with a CNAME at that exact name.

; DNAME: every descendant is remapped in one record
old.example.com.   IN  DNAME  new.example.net.
; www.old.example.com  -> www.new.example.net
; a.b.old.example.com  -> a.b.new.example.net
; old.example.com itself is NOT remapped by the DNAME alone

How resolvers synthesize a CNAME

The clever part of DNAME is how it interacts with older clients and existing resolution logic. When an authoritative server with a DNAME matches a query for a descendant name, it returns the DNAME record and also synthesizes a CNAME on the fly for the specific name that was queried. The owner of the synthesized CNAME is the query name, and its target is the equivalent name under the DNAME's replacement. The synthesized CNAME is given a TTL equal to the DNAME, and resolvers must also accept a synthesized TTL of zero.

$ dig www.old.example.com +noall +answer
old.example.com.      3600  IN  DNAME  new.example.net.
www.old.example.com.  3600  IN  CNAME  www.new.example.net.   ; synthesized
www.new.example.net.  3600  IN  A      203.0.113.80

The client sees a familiar CNAME pointing at the new name and follows it as it always would, then resolves the address there. This design means DNAME works even with clients that do not understand DNAME directly, because they only ever act on the synthesized CNAME. The DNAME itself is the instruction to the authoritative server; the CNAME is what the resolver consumes.

It is worth being precise about where the rewrite happens. The authoritative server for the zone holding the DNAME performs the synthesis; the recursive resolver and the stub client simply receive a normal-looking CNAME in the answer and cache both the DNAME and the synthesized CNAME. Because the synthesis is deterministic, any resolver can reconstruct the same CNAME for any descendant name without a round trip back to the authoritative server for each one, which is part of why a single DNAME can cover an arbitrarily large subtree efficiently. The trade-off is that the synthesized CNAME carries no signature of its own, so a DNSSEC-validating resolver proves its correctness from the signed DNAME rather than from the CNAME itself.

Rules and gotchas

• No descendant records under a DNAME owner. You cannot have the DNAME and also publish records for names below its owner in the same zone; the DNAME owns that subtree. Records for descendants must live in the target zone.
• The owner name needs its own record. Because the DNAME skips the owner name, add a separate A, AAAA, or CNAME at that exact name if it must resolve.
• A DNAME and a CNAME cannot share an owner name. They are different redirection types and conflict if placed together.
• Loops are possible. A DNAME whose target leads back into the source subtree can create a resolution loop, so map targets carefully.
• DNSSEC interaction. The DNAME is signed, but the synthesized CNAME is not; validating resolvers reconstruct it from the signed DNAME, so support must be correct end to end.

When DNAME is the right tool

DNAME shines whenever an entire namespace needs to move or mirror as a unit.

For a one-off alias of a single hostname, a CNAME is simpler and correct. Choose DNAME only when the thing you are redirecting is a whole branch, not a leaf.

Verify the subtree redirects as intended

Because DNAME changes how an entire branch resolves, a mistake can quietly misroute many names at once, and the synthesized CNAME behavior can differ across resolver implementations. After publishing, query several descendant names and confirm each one follows to the expected target, then run the owner name through the Valla DNS propagation checker to make sure the DNAME is live and consistent everywhere. Our guides on CNAME at the apex and on reading a resolution trace pair well with this one when you are untangling how a redirected subtree actually resolves.