Does "@" in CNAME record not work?

[Kevin Darcy]

Jim Lum wrote:

> Cricket,
>
> Comments below, interspersed.
>
> Cricket Liu wrote:
> >
> > > Then, as I read the book, I ran across the section that I cited above,
> > > which I took (and which I guess I still take) to imply that, in a
> > > "correct" DBxxx.. file, you should TRY to avoid having names with the
> > > same IP address.  I've read those two paragraphs (bottom of pg. 64, top
> > > of pg. 65) over several times, and I THINK that's what it's trying to
> > > say?
> >
> > No, it's really not.  It just explains the impact of using a CNAME record
> > versus an A record vis a vis canonicalization.  You're reading too much
> > into it.
>
> Wow!  It seems like we're really getting into semantics now :)!  Perhaps
> if I had said "caused me to infer that ..." instead of "I took ... to
> imply that ...", it might've been more accurate.
>
> I guess if I was going to be picayunish, in the context of the text, I
> still don't really see the difference in implication between "should try
> to avoid having names with the same IP address" and "explains the impact
> of using a CNAME record versus an A record vis a vis canonicalization"?
>
> I mean, if it (having A records with duplicate IP addresses) has a
> (potential) impact on someone, then it still sounds to me (i.e., I still
> would infer) that I should try to avoid this if I could?
>
> Let me put it another way, hypothetically:
>
> IF someone "out there" had a hard-and-fast rule [I have no idea why,
> but, for the sake or argument, let's say the management in a company
> made such a rule] that said specifically that no A records within zone
> files could ever have duplicate IP addresses, THEN it seems like Bind
> would not be able to comply to this rule in all cases?
>
> You might say "Whoever made that rule is dumb!", or "Oh, that's probably
> stupid management!", and I might agree, but who knows, there might
> actually be a reason why someone would want to have such a rule.
>
> My apologies, and I'll probably get flamed for this, but this looks (to
> me) like a design oversight...

Sigh. It's not a "design oversight" of BIND. In fact, it's not a BIND-specific
phenomenon at all. It's a protocol restriction. The protocol explicitly and
deliberately rules out "CNAME and other data", i.e. a name owning a CNAME and
records of other types:

> 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.
>
(RFC 1034, Section 3.6.2).

Think about it. A caching server has a CNAME record cached, but nothing cached
for the canonical name. Without the "CNAME and other data" prohibition, if it
wants to give a complete answer to a client asking about that name, it has to
go ask a) the authoritative servers for the canonical name and b) the
authoritative servers for the alias name. With the rule, it only needs to do
(a). The rule thus prevents the caching server from doubling (roughly) its
workload, in that scenario, for essentially no benefit.

Moreover, what if the data that the caching server gets from these two sources
overlap or contradict each other, e.g. the authoritative servers for the alias
name report that the name owns an A record pointing to address 1.2.3.4, but
the authoritative servers report that the canonical name owns an A recored
pointing to address 2.3.4.5? Do you answer with *both* A records? Give
preference to one over the other?

What if you can't contact one of the sets of nameservers? Do you return what
you have or fail the query completely? If you return the partial result, how
is the client to know that it's a partial result? And if you fail the query
completely, you've just doubled the number of failure points for resolution of
aliased names, thus reducing the robustness of the mechanism.

There are very good design reasons for the "CNAME and other data" rule, and
it's only a minor inconvenience to administrators. As for arbitrary,
non-protocol rules like "any given IP address must appear at most once in a
given set of zonefiles", such a rule is incompatible with the DNS protocol
unless you get into lawyerly technicalities like loading the zone data from
something other than files...


- Kevin