CNAMEs pointing to @?

I initially answered this question as if you were putting "@" as the target of the record, but rereading it sounds like you're trying a CNAME called "@". So, I'll answer both ways - a CNAME named @ and a CNAME with @ as the RDATA.

A CNAME called @ is illegal by the RFCs. There are implementations that allow it, but it is expressly forbidden by RFC 1912. The reason for this is that a canonical name is not allowed to coexist with any other records. When you render a zone in the DNS Manager, we inject SOA and NS records called "@", and RFC 1912 specifically mentions that case:

   A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.  Especially do not try to combine CNAMEs and NS
   records like this!:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4

As for "@" as the target of a record, just use the domain name itself. I don't know what will happen if you try to use "@", and my gut reaction is to say that "@" is only valid as the name of a record, and not the RDATA. I might be wrong.

Well, to try to be more clear, what I used to have, for fixppp.org

Type: A

name: @

data: IPgoeshere

Type: CNAME

name: www

data: @

Type: CNAME

name: hoth

data: @

etc.

In this manner, I pointed various subdomains at the same IP for vhost purposes, but only ever had the IP entered once.

I think you're saying that I do more or less the same thing, but instead of having the CNAMEs have "@" as data, they'd have "fixppp.org" as the data?

@Guspaz:

I think you're saying that I do more or less the same thing, but instead of having the CNAMEs have "@" as data, they'd have "fixppp.org" as the data?

That's how I have mine setup.

@Guspaz:

I think you're saying that I do more or less the same thing, but instead of having the CNAMEs have "@" as data, they'd have "fixppp.org" as the data?
Precisely.

@jed:

@Guspaz:

I think you're saying that I do more or less the same thing, but instead of having the CNAMEs have "@" as data, they'd have "fixppp.org" as the data?
Precisely.

I've gone ahead and done this, but I pulled the zone file from godaddy for another domain I have, here's an abbreviated copy:

; SOA Record
TEKNEWS.NET.    3600    IN  SOA ns13.domaincontrol.com. dns.jomax.net. (
                2004111500
                28800
                7200
                604800
                3600
                )

; A Records
@    1800    IN  A   68.234.14.10
ut2004    1800    IN  A   68.234.14.10

; CNAME Records
forums    1800    IN  CNAME   @
mail    1800    IN  CNAME   @
roughrider    1800    IN  CNAME   @
www    1800    IN  CNAME   @

; MX Records
@    3600    IN  MX  0   mail.teknews.net

; NS Records
@    3600    IN  NS  ns13.domaincontrol.com
@    3600    IN  NS  ns14.domaincontrol.com

It looks like this is valid and does what is intended. It's not a big deal, since entering the domain itself as the data of the CNAME like you suggested seems to do just what I want, but putting @ is slightly less annoying (works on any domain, don't need to keep track of what domain you're working on). Might want to confirm if it's valid; godaddy's zone file validator seems to think it's OK.

Names that point at other names should not (RFC 1034 sec 3.6.2) point at a CNAME, especially not MX records (RFC 974, "Minor Special Issues"):

@   3600   IN   MX   0   mail.teknews.net 
mail   1800   IN   CNAME   @

@hoopycat:

Names that point at other names should not (RFC 1034 sec 3.6.2) point at a CNAME, especially not MX records (RFC 974, "Minor Special Issues"):

@   3600   IN   MX   0   mail.teknews.net 
mail   1800   IN   CNAME   @

RFC 974 specifically says that MX records pointing to CNAMEs is perfectly fine. The special case that you cite has to do with the local and remote host sharing aliases, which is pretty difficult for a host like teknews that is receive-only.

RFC1034 section 3.6.2 also does not forbid this, as it states that "Domain names in RRs which point at another name should always point at the primary name and not the alias.", and the MX record points at a CNAME belonging to the same domain rather than a different name.

The wording in the source RFCs is a little ambiguous, but RFC 2181 section 10.3 is quite direct:

> The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

(See also section 10.1.1 for definition of "alias" as the label of a CNAME resource record and justification for this choice of wording; see section 3 for definition of "must not" in this RFC, which differs from the standard RFC "MUST NOT".)