2

I have read various blogs that a CNAME cannot coexist with other records that have the same name as the CNAME record.

I have not found a good example explaining the problem.

Here is an example from the blog:

CNAME records cannot coexist with other records that have the same FQDN as the CNAME record because they effectively overwrite all other records with the same FQDN.

For example, a CNAME record FQDN is example.com, and you want to create an A record FQDN example.com. This is not allowed because the A record FQDN is identical to the CNAME record FQDN, rendering the A record purposeless.

I do not find the example clear enough for me to understand the problem.

I am trying to understand what the explanation means.

Imagine I have configured:

Domain name TTL Class Record type Value
aliasname.example.com 300 IN CNAME name.example.com
name.example.com 300 IN A 10.0.0.1

What happens in such a configuration?

EDIT: I stand corrected by answers that my above example is correct/valid.

Putting an incorrect/invalid configuration below. The above example came from my wrong understanding of text examples lacking table illustrations.

Domain name TTL Class Record type Value
name.example.com 300 IN CNAME othername.example.com
name.example.com 300 IN A 10.0.0.1

My understanding is that the latter configuration is invalid because according to RFCs the CNAME is used first and the A record is never used.

Am I right regarding the cause of incorrectness of the latter table?

Or in general what happens in the case of the latter configuration?

Greg Askew
  • 39,132
Alexander Ites
  • 131

4 Answers4

5

That the CNAME cannot coexist with other record types relates to this:

Domain name TTL Class Record type Value
host.example.com 300 IN CNAME fqdn.example.com
host.example.com 300 IN A 192.0.2.1

NOT the scenario you described. The reason for it being invalid appears somewhat arbitrary but I believe it is a requirement of the RFCs.

Your described scenario is quite valid - and widely used. E.g.

Domain name TTL Class Record type Value
service1.example.com 300 IN CNAME reverseproxy.example.com
service2.example.com 300 IN CNAME reverseproxy.example.com
service3.example.com 300 IN CNAME reverseproxy.example.com
reverseproxy.example.com 300 IN A 192.0.2.1
symcbean
  • 23,767
  • 2
  • 38
  • 58
4

Your example is valid.

What's not valid is

Domain name ttl Class Record type Value
cname.example.com 300 IN CNAME foo.example.org
cname.example.com 300 IN A 192.0.2.1
vidarlo
  • 11,723
4

Your last example is invalid not because "something is used first". It is invalid because it violates the logic behind the CNAME.

The logic I am talking about is that CNAME defines the name to be an alias of some other name, which is then referred to as a canonical name, "cname" being abbreviation of that. The record alias CNAME canonical-name literally says: "alias is the other form of canonical-name". It's very much like to say: "Bob is the other form of Robert". It is absurd to add: "and also alias is something else", it wouldn't make sense, at least, in computing. It doesn't fit into the data model, so it is explicitly disallowed by the RFC.

The same reasoning stands behind CNAME at apex of the zone: an apex must define at least two records, SOA and NS, which is already at conflict with the requirement that CNAME must appear alone. (Initially I thought to vote for this question to be closed as a duplicate of the linked one, because that answer really answers this one too; however, it seems this is another, more broad, question, and it would be more sense to do it in the opposite direction.)

There was an update to this rule when DNSSEC was introduced. Signing records must appear together with CNAME to certify it's validity in a signed zone. But no other record can. (RFC 2181 says "may", but the record won't really work without signing in a signed zone.)

Nikita Kipriyanov
  • 15,624
0

Quote from the horse's mouth, RFC 1034:

The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.

Jelle Geerts
  • 121