If you have a main domain and a bunch of similar domains that you basically want to behave exactly the same it seems logical to configure as follows:

'Poor relation' zone:

amazon.co.uk. DNAME amazon.com.

amazon.co.uk. CNAME amazon.com.

'Daddy' zone:

amazon.com. A

www.amazon.com. A

amazon.com. MX x.y.z.

... and expect email for both amazon.co.uk and .com to be handled by x.y.z and the web server at to get requests for not only amazon.com and www.amazon.com but also for amazon.co.uk and www.amazon.co.uk.

However RFC 6672 says:

The owner name of a DNAME can only have one DNAME RR, and no CNAME RRs can exist at that name. These rules make sure that for a single domain name, only one redirection exists; thus, there's no confusion about which one to follow.

What I don't understand and my question is, what is the potential confusion which is avoided by not allowing CNAME with DNAME? My understanding is that DNAME will do everything except the apex and CNAME does the apex, what have I missed?

  • 1
    Regarding the zone apex (as in your example), you can't have a CNAME anyway whether or not you have a DNAME. I suppose the question is relevant further down into a zone, though. Commented Nov 27, 2016 at 22:36
  • @HåkanLindqvist why not? :-S AFAIK the reason you can't is that you don't have the DNAME, in other words you wouldn't be able to resolve www.amazon.co.uk (which is what DNAME solves).
    – ostergaard
    Commented Nov 27, 2016 at 22:41
  • 2
    A CNAME record cannot coexist with other records (with RRSIG as the obvious exception but which makes complete sense based on it being metadata for the other RR). The zone apex always has at least SOA and NS records, hence no way for it to have a CNAME record. Commented Nov 27, 2016 at 22:44
  • 1
    The DNAME spec noting that you can't have it side by side with a CNAME probably comes back to that same reasoning, I think the answer lies in finding the scenario where the actual DNAME RR is used and the conflict appears. Commented Nov 27, 2016 at 22:48
  • 1
    Ie, I think the question boils down to "why wasn't DNAME made an exception?" (which would still have changed nothing for the zone apex), which I imagine one will figure out after reading the nitty gritty details of how to implement DNAME. Commented Nov 27, 2016 at 23:04

4 Answers 4


it seems like the answer is basically that the original architects never thought it would be useful or something equally short sighted

It's important to understand that the Domain Name System (DNS) was replacing an arrangement that used a globally cloned version of /etc/hosts across every computer on the internet at the time, so reliability and fast average responses were critical to its adoption. So the inclusion of caching resolvers in the original design was a critical to its success.

Since then the focus has shifted: backwards compatibility is also extremely important: caching DNS resolvers are a core service on consumer appliances that typically run for 10~15 years without software updates.

Now imagine a CNAME record were allowed in combination with some other record type, and then consider a caching resolver.

The first problem is efficiency.

Depending on the order of queries and the TTLs of the records, it will eventually wind up with only a CNAME in its cache for a given name.

Then what should happen when a client (which might be another caching resolver) queries for a AAAA: should it answer using the CNAME, or query the authoritative server for an AAAA?

The next problem is ambiguity.

If the owner and target names are both zone apexes, and the client queries for NS or SOA, then there are two completely different possible answers, both valid depending on why the query was made.

The "keep it simple" design would say "treat all queries the same", because you don't know why the client is asking: always follow the redirection.

You could argue that different rules should apply for different record types, and that there should be an enumerated a list of RR types which could co-exist with CNAME records, but such a list would have had to have been part of the original design (in the early 1980's). And while that would have solved the problem for SOA & NS, it would not have solved the problem for DNAME which was not added until later.

The addition of a "do not follow CNAME" field in the query record would probably have resolved most issues, without adding much complexity, but that would have been a prescient design at a time when symbolic links were a novelty, and O_NOFOLLOW was still at least decade away.


Because that's the rule.

it seems like the answer is basically that the original architects never thought it would be useful or something equally short sighted.

If a CNAME record was allowed at the Root, the CNAME would include the NS records, invalidating the zone itself into an infinite loop.

Other DNS Servers have "Fixed" this with things like an ANAME which specifically aliases the resolution of a host as the answer to an A record request. ANAME is not a standard.



Do what everyone else does, and 301 your root domain to the www subdomain, either yourself or with a 3rd party service.

  • Sorry but, while interesting, relevant and even practical, your answer doesn't even come close to answering the original question.
    – ostergaard
    Commented Nov 27, 2016 at 23:47

Due to the way it is defined a CNAME must be the only RR for the domain. As a result, it is only applicable to apex domains.

DNAME can be used in place of multiple CNAME records when all the sub-domains of a domain should be redirected to the same structure under a different domain. The DNAME record does not redirect the domain it applies to. Servers querying a domain redirected by a DNAME record will get a CNAME response.

If both domains are served by the same servers, it would be possible to avoid redirection by using the same zone file for both domains.


The "what are you missing" is that CNAME cannot be used at the zone apex, and it does not matter whether a DNAME is present.

For the sake of people who hit upon this question while asking about combining CNAME and DNAME on a non-apex name, I would point to https://tools.ietf.org/id/draft-sury-dnsext-cname-dname-00.html and https://tools.ietf.org/id/draft-sury-dnsop-cname-plus-dname-01.html which explain why this is basically a flaw in the existing DNS spec.

Prohibiting a CNAME at the apex of a zone is an entirely separate matter from having a CNAME and DNAME apply to the same name, and there are good and sensible reasons for allowing the latter (provided it's not the apex, of course).

Really this is only an issue for DNS server software; if yours doesn't allow the combination, consider upgrading or replacing it.

  • i belive that answer shoots far away from what was asked in case of the last sentence
    – djdomi
    Commented Jul 21, 2021 at 7:34
  • 1
    @djdomi I've edited this answer to take your comments into account; is it clearer now? Commented Jul 22, 2021 at 19:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .