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

From: Erik Aronesty <[email-masked]>
Date: Thu, 1 Mar 2001 13:24:42 -0500

|  - 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 ...

That *is* the only issue here. The zone-top restriction.

	  |  - 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.

I agree.  Howeve, it's not the general case of the rule that I am taking 
issue with. It's the very specific case of a CNAME at the "zone-top". So, 
lets discuss the specific case of the "zone-top".  

What data would be "duplicted"?  What happens if this were allowed?

Remember, all nodes in the DNS tree really "have" an SOA/NS for the authority 
section.

And all CNAME's already have authority information in two places, 
the alias and the canonical name.

Moving forward:

Requests for QTYPE=CNAME would respond with the authority information from the 
local zone file, or inheriting from the parent node.  The results,
in this case are not contradictory / misleading.

Requests for other QTYPE's would respond with the authority 
information from the target.  The results, in this case are still not 
contradictory or misleading

Direct requests for QTYPE=SOA or NS would respond with the information from the 
canonical name, dutifully following the algorithm.

How do CNAME's at the zone-top cause failure/doom?

	  | 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.

****I repeat, this is not the case that we have an issue with***

Consider again that this is valid:

	----x zone file----
	A	IN	CNAME	B.Y
	A 	IN	NS	C

	----y zone file----
	@	IN	NS	C
	B	IN	A	...
	
Then explain why this is not using the same argument:

	----x zone file----
	@	IN	CNAME	B.Y
	@ 	IN	NS	C

	----y zone file----
	@	IN	NS	C
	B	IN	A	...

	  |  - 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.

Sorry, I'm working on it.  Believe it or not your analysis is very helpful.

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 01:55:14 +0700

Date:        Thu, 1 Mar 2001 13:24:42 -0500
    From:        Erik Aronesty <[email-masked]>
    Message-ID:  <01C0A252.FA607FA0@INSIDE>

  | That *is* the only issue here. The zone-top restriction.

You are failing to understand.  There is no "zone-top" restriction.
There is a general restriction which applies everywhere, zone top or not.

  | I agree.  Howeve, it's not the general case of the rule that I am taking 
  | issue with. It's the very specific case of a CNAME at the "zone-top". So, 
  | lets discuss the specific case of the "zone-top".

Why?   There's no magic difference.

  | What data would be "duplicted"?  What happens if this were allowed?

Exactly the same as can happen anywhere else.   Any domain in the DNS
can be a zone top, zones are an administrative issue.   Allow CNAME at
the zone top, and it is instantly allowed everywhere, so that is what
you are taking issue with.

  | Remember, all nodes in the DNS tree really "have" an SOA/NS for
  | the authority  section.

This is a total mis-mash of two different concepts.   Nodes in the
DNS tree do not have an authority section.  DNS packets have an
authority section (which sometimes contains data).  The two things
are not very related.

  | Requests for QTYPE=CNAME would respond with the authority information

requests for type CNAME respond with the CNAME RR, if it exists,
they don't respond with "authority information".  Sometimes, auth
info might be included, if it happens to be available.

  | Consider again that this is valid:
  | 
  | 	----x zone file----
  | 	A	IN	CNAME	B.Y
  | 	A 	IN	NS	C

No it isn't.   If A is an alias, it can have no other data, hence
it cannot have that NS record.

  | Then explain why this is not using the same argument:
  | 
  | 	----x zone file----
  | 	@	IN	CNAME	B.Y
  | 	@ 	IN	NS	C

it is not for the exact same reason, except we have @ ($ORIGIN, or x)
instead of A.   Except as a thing to do this makes zero sense at all.

kre