Problem with DNS (CNAME)

You can't have a CNAME record alongside any other type of record, and the domain itself must have several other records, such as SOA and the NS records. Therefore, no CNAMEs.

You'll have to find some other way to accomplish what you want.

I've done this with every other DNS server I've used including MS DNS and Slicehost's DNS (MyDNS)… I'm surprised it doesn't work here. Maybe the other servers where not doing things "properly" and linode DNS is more strict… who knows.

Yeah, I remember someone else doing it at Slicehost and being surprised it didn't work at Linode. Nonetheless, it's not allowed.

(I should grep my IRC logs for the relevant RFC citation, but, honestly, I don't care enough. :P )

I googled around a bit and found some info and I think the RFC on it… Perhaps I should setup my own MyDNS servers or just keep a slice open at Slicehost… sigh…

As has been mentioned, you can not have an SOA record and a CNAME record for the same entry. This breaks the rules.

Some systems might accept a CNAME (without any SOA) but for something that's been delegated it could get confused (the domain has an NS glue record in the parent domain, and then returns a CNAME…umm).

Although it's potentially do-able, it's a misconfiguration. You're just asking for problems.

If I wanted two zones to be identical then I'd run my own BIND nameserver and have the two entries in my named.conf pointing to the same zone source file. Then, for all intents and purposes, they're two separate zones; they just happen to be configured identically.

RFC 1034, section 3.6.2 states: "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."

RFC 1912, section 2.4 specifically reinforces: "A CNAME record is not allowed to coexist with any other data."

Since there's an SOA and at least one NS record for @ by necessity, a CNAME cannot be added for @ without violating that rule. This is a significant limitation of CNAMEs. If the target of the CNAME is under your control and/or is reasonably static, there's no need for a CNAME; if there is a need for a CNAME, you might be better off having the destination of the CNAME host the domain and keep it updated as things change.

If it's just "I have 100 domains that all point at the same place", look into the API… a couple nested for loops and you have a DNS search-and-replace, without having to deal with CNAMEs.

Wikipedia says, "the wild card is matched only when a domain does not exist, not just when there are no matching records of the type that has been queried for."

http://en.wikipedia.org/wiki/WildcardDNSrecord

So, the CNAME in the above example is not alongside any other records. If it's not allowed, this would be a bug in the Linode DNS Manager.

For wildcards, RFC 4592 section 3.3.3 revises RFC 1034 section 4.3.2 step 3 part C to clarify support of a wildcard CNAME. I did add an appropriate record through the DNS manager moments ago, and I have no reason to believe it won't work when I try it in a few moments.

However, worth noting is that *.example.com will not match example.com – the * applies only to that level in the tree. It will also not match foo.bar.example.com.

EDIT: Yup, *.example.com CNAME example2.com returns CNAME example2.com for fritter.example.com.

@BarkerJr:

So, the CNAME in the above example is not alongside any other records. If it's not allowed, this would be a bug in the Linode DNS Manager.
Not at all. He tried @ first (which didn't work – others have done a fine job of going over why), then tried * (which won't do what he wants -- Hoopy went over why -- but it is allowed). The example he pasted, I'm assuming, is the final try with *.

OP: If you run a nameserver on your Linode, like BIND or NSD, you can configure a slave domain in the Linode Manager which will AXFR/IXFR your zone from you and serve whatever you feed it. If you want to violate RFC with the CNAME, ns1-ns5 will happily serve your RFC-violating zone if they're configured as slaves to your master. (I'm pretty sure. Haven't tried.)