Subject: Re: cnames are in conflict with soa's...

From: "Erik Aronesty" <[email-masked]>
Date: Thu, 1 Mar 2001 01:05:30 -0500

----- Original Message -----
From: "Kevin Darcy" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 28, 2001 8:05 PM
Subject: Re: cnames are in conflict with soa's...

> Erik Aronesty wrote:
>
> > Doug,
> >
> > Clearly, the resolver algorithm already supports this feature - if it
plans
> > on following the RFC's.  This is a completely backward-compatible
feature.
> > Eliciting dialogue on this forum *is* a part of the process.  RFC's are
not
> > used as "requests for comments" anymore.
> >
> > Should a DNS server issue an error if a CNAME is at the "zone top"?
> >
> > DNS is a "tree" of information.  CNAME's can be at any node on this
tree.
>
> Subject to the "CNAME and other data" rule, of course.

 - The restriction on the zone-top has no purpose - other than to follow the
RFC.

 - The purpose in the rule is to insure that a cached CNAME can be used
without checking with an authoritative server for other RR types.  All other
RR's *aside from the SOA/NS records* (which are required) could conflict
here.  The SOA/NS are for the authority section of a response - and always
get transmitted along with the CNAME anyway regardless - so how can this
records cause conflicts?

 - Assuming you are a network admin with a CNAME from ny.x.com to www.y.com
in the ny.com zone.  A perfectly reasonable config.  It becomes necessary to
create new zone for ny.x.com.  This kind of thing happens. How do you
resolve this now?  Start copying records around in a batch job?  What if
there are 50 zones like this?

                - Erik

>
> > If the text file they are in has SOA record for the same domain, then
> > there's a problem.  However the text file is required to have an SOA
record
> > if it's a "zone top".
>
> No, this has nothing to do with "text files" _per_se_. Although the RFC's
> specify "master file format", I'm not aware of any requirement that text
files
> be used to load DNS zones. It is more proper, I think, to state that a
zone
> must have at least 1 SOA RR and 1 NS RR. This is true *regardless* of
whether a
> text file is used to load the zone.
>
> > This is an indirect restriction on CNAME's at the zone top and should
have
> > been clarified in the RFC.
>
> I suppose we can differ on whether the restriction is "indirect" or not,
but it
> seems to me to follow, by simple logical implication, from
>
> 1. CNAME records can't co-exist with records of other types having the
same
> owner name, and
>
> 2. The name of a zone must own at least 1 NS and 1 SOA record
>
> that
>
> 3. a CNAME can't have the same owner name as that of a zone.
>
> But then, what do I know from syllogisms? I only have a degree in
Philosophy...
>
> > RFC's should not create "implied rules".  They should be careful to list
all
> > of the rules - so that things like this don't happen.
> >
> > At the very least, the RFC should be amended to state that CNAMEs are
> > restricted from being served from any node that is a "parent" in the
tree.
> > This would be acceptable - but would expose the obvious problem.  But,
that
> > way none of this would have happened.
>
> Feel free to submit a clarifying Internet Draft.
>
>
> - Kevin
>
>
>
>
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
>

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Robert Elz <[email-masked]>
Date: Fri, 02 Mar 2001 00:40:14 +0700

Date:        Thu, 1 Mar 2001 01:05:30 -0500
    From:        "Erik Aronesty" <[email-masked]>
    Message-ID:  <[email-masked]>

This whole discussion s truly absurd.   You clearly have no idea
what the intent of CNAMES was.

  |  - The restriction on the zone-top has no purpose - other than to follow the
  | RFC.

On zone top, in particular, perhaps - but that is a side effect of a rule
which does have a purpose, which is not ...

  |  - The purpose in the rule is to insure that a cached CNAME can be used
  | without checking with an authoritative server for other RR types.

That's just a side benefit.

The restriction is so that the data for the alias, and the data for the
canonical name, are identical.   Everything about them is the same.
CNAMES are (were) the replacement for the "extra names" (aliases) field
in the hosts.txt file.   More names that mean exactly the same thing as
the canonical name.

If it isn't identical in all respects, then it isn't an alias, and should
have real data, not a CNAME.

Also, only hosts get aliases - domains weren't in hosts.txt, so never
had aliases, so still don't get to have aliases.

  | All other
  | RR's *aside from the SOA/NS records* (which are required) could conflict
  | here.  The SOA/NS are for the authority section of a response - and always
  | get transmitted along with the CNAME anyway regardless - so how can this
  | records cause conflicts?

Huh?   *always* - now I know you're joking.

But just consider

	A	IN	CNAME	B
		IN	NS	C

	B	IN	NS	D

now the NS records for A and B are not identical, and hence A is not
an alias for B, and hence A should not have a CNAME record.   It doesn't
matter what else exists or does not.

  |  - Assuming you are a network admin with a CNAME from ny.x.com to www.y.com
  | in the ny.com zone.  A perfectly reasonable config.  It becomes necessary to
  | create new zone for ny.x.com.  This kind of thing happens. How do you
  | resolve this now?  Start copying records around in a batch job?

You copy the records from www.y.com to ny.x.com and then modify whatever it is
that makes it no longer be an alias.   Whether than is to add a delegation
below ny.x.com or to alter the A record, or MX record, or anything else
where the two names are no longer identical.

  | What if there are 50 zones like this?

Then you have a bit more work to do.   Big deal.

Please stop bothering people about this - if you have a sensible and
well thought out proposal, that documents all of the ramifications,
then write it as an I-D.

Otherwise, it seems clear that there is *no-one* else here that supports
your rather oddball theory on the way things ought to be.  Arguing about
it is just wasting everyone's time.

kre

---

From: Randy Bush <[email-masked]>
Date: Thu, 01 Mar 2001 10:59:17 -0800

> This whole discussion s truly absurd.

nah, only mostly absurd.  so why are folk continuing it?

randy

---

From: Robert Elz <[email-masked]>
Date: Fri, 02 Mar 2001 02:06:54 +0700

Date:        Thu, 01 Mar 2001 10:59:17 -0800
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | nah, only mostly absurd.  so why are folk continuing it?

Very good question.   You can assume that any more messages from
me on the subject must be forgeries, and drop them...

kre

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 01 Mar 2001 18:51:19 -0500

Erik Aronesty wrote:

> get transmitted along with the CNAME anyway regardless - so how can
> thisrecords cause conflicts?

Are you implying that SOA and NS records can *only* appear in Authority
Sections? Clearly that is false; in answers to explicit SOA or NS queries, they
may appear in the *Answer* Section. And explicit SOA and NS queries are not
only possible, they are quite common: explicit SOA queries are generated
routinely and automatically in the serial-number checking step of
AXFR/IXFR-based master/slave synchronization; certain Dynamic Update clients
generate explicit SOA and/or NS queries also.

But, regardless of the circumstances under which SOA and NS records appear in
the Answer versus the Authority Sections of responses, the relevant point here
is that records of those types can be *cached* from responses. Given this, you
create a terrible ambiguity if you allow CNAMEs to co-exist with those record
types. As I've explained in my last message in a parallel thread, if a
CNAME can be cached and an SOA or NS record with same name could be cached,
then the results of issuing an NS or SOA query of that name to a
non-authoritative, recursive server would be *unpredictable*, depending on what
type of record(s) with that name it happened to have in its cache at any
particular time. You can't build a robust nameservice infrastructure on such
unpredictability.

> there are 50 zones like this?

Erik, admins who read relevant RFC's and/or fix the problems that
BIND complains about in log files have been dealing successfully with this rule
for 13 years since RFC 1034 first announced it. I personally ran afoul of this
rule somewhere around 1991, realized my mistake, corrected it and I've never
had a problem with it since that time. It's just a fact of life in the world of
DNS administration, and I have accepted it as such. Why then, all of a sudden,
do you declare the whole profession of DNS administration incapable of dealing
with this rule? Clueless admins need to be *educated* and to *learn* the rules,
not for their cluelessness to be accommodated with reckless changes that
introduce inefficiency and/or unreliability into the underlying protocol.
Another common newbie misconception is that putting an NS record in a zone
somewhere other than at the zone top tells a nameserver to "forward" requests
(i.e. issue recursive queries) for the name to some other nameserver; shall we
accommodate that misconception also, thus mangling the mechanism of delegation
and referral? Where does this all end? Or maybe what we actually need are two
*different* DNS protocols -- the regular DNS protocol and the Remedial
DNS protocol, for those who can't deal with the regular one...

- Kevin