Why using CNAME and DNAME together isn't allowed

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 1.1.1.1

www.amazon.com. A 1.1.1.1

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 1.1.1.1 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?

Solution 1:

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.

Solution 2:

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.

https://www.rfc-editor.org/rfc/rfc1912

http://www.faqs.org/rfcs/rfc1034.html

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

Solution 3:

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.

Solution 4:

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.