DNAME Delegation Name Common
Redirects an entire subtree of the DNS namespace to another subtree, unlike CNAME which only aliases a single name.
What it's for
A DNAME (Delegation Name) record redirects an entire subtree of the DNS namespace to another subtree, in one shot. Where a CNAME aliases exactly one specific name to another, a DNAME aliases every name under a given point — so anything.old.example.com automatically redirects to anything.new.example.com without needing a separate CNAME for each individual subdomain.
This makes DNAME useful specifically when you're rehoming an entire branch of subdomains at once (a whole department, product line, or legacy domain's worth of subdomains) rather than one hostname at a time.
Format & syntax
old.example.com. 3600 IN DNAME new.example.com.
- Name — the subtree being redirected (e.g.
old.example.com.) - Value — the target subtree everything gets redirected to
When a resolver looks up foo.old.example.com against this record, it synthesizes a CNAME on the fly, effectively rewriting the query to foo.new.example.com — this happens transparently to the client, which just sees the final resolved answer.
Important distinction from CNAME: unlike CNAME, a DNAME record can coexist with other records at the same name — it only redirects lookups for names underneath it, not the name itself.
How it's used in practice
- Whole-subtree domain migrations — moving an entire branch of subdomains from one naming scheme to another (e.g., consolidating
*.legacy.example.comunder*.example.com) without manually creating a CNAME for every individual subdomain that currently exists or might be created in the future. - Organizational renames or mergers — redirecting an entire acquired company's subdomain structure under a new corporate domain in one operation.
- IPv6 transition mechanisms — DNAME has historically been used in some IPv6-related reverse DNS delegation schemes, redirecting large blocks of
ip6.arpanamespace.
Common mistakes & gotchas
- Reaching for DNAME when you only need to alias one name — if you're just redirecting a single hostname, a plain CNAME is simpler, far more widely understood, and has broader tooling/provider support. DNAME's whole value proposition is redirecting an entire subtree at once; using it for a single name is unnecessary complexity.
- Limited DNS provider support — DNAME is less universally supported in DNS provider dashboards compared to A/CNAME/MX; some providers don't offer a UI for it at all, requiring more manual zone file management or a provider that specifically supports it.
- Confusion with CNAME's coexistence restriction — people familiar with "CNAME can't coexist with other records" sometimes assume the same restriction applies to DNAME, but it doesn't — a DNAME record only affects lookups underneath it, so the DNAME's own name can still have other records like TXT or MX.
- Underestimating the scope of the redirect — because DNAME affects everything below a name, an accidental or overly broad DNAME can redirect subdomains you didn't intend to move, especially if new subdomains get created under the old subtree after the DNAME was set up expecting a static, already-known set of names.
Comparison & FAQ
| Type | Purpose | Key difference from DNAME |
|---|---|---|
| CNAME | Aliases exactly one name to another | Doesn't cover subdomains underneath it; DNAME redirects an entire subtree in one record |
What's the actual difference between DNAME and CNAME?
CNAME aliases one specific hostname to another. DNAME aliases an entire subtree — every name underneath the DNAME's own name gets redirected automatically, without needing individual records for each one.
Can a name have both a DNAME record and other records like TXT or MX?
Yes — unlike CNAME, DNAME doesn't have the "no other records on this name" restriction. It only affects lookups for names below the DNAME's own name, not the name itself.
Is DNAME widely supported by DNS providers?
Less universally than the core record types (A, CNAME, MX). Some providers offer full support, others don't expose it in their standard dashboard, so check your specific provider's capabilities before planning a DNAME-based migration.
When would I use DNAME instead of just adding several CNAME records?
When you need to redirect an entire branch of subdomains — including ones that might be created in the future — a single DNAME covers the whole subtree automatically, whereas CNAME would require a separate record per subdomain and wouldn't automatically cover new subdomains added later.