Subject: RE: cname quick question

From: Erik Aronesty <[email-masked]>
Date: Thu, 1 Mar 2001 11:48:53 -0500

Mark,

Following your excellent example:

There is a CNAME present at the node, so the request for the SOA/NS record 
will be restarted with the QNAME changed to the target.  The SOA will 
then be returned from the canonical name.

--> The query will not fail if the algorithm is follwed.

Other results:

The SOA present at the zone-top will never be cached/used except 
in requests which prevent chaining, IE: requests for the CNAME itself or for 
other domains in the zone file.  Likewise, the NS records will only be used 
for the authority section in non-chained requests.  

If you consider the meaning of NS/SOA records - this behavior is correct.  
(Or as close to correct as possible - since there really should have been 
*two types of NS records*, as was pointed out earlier on namedroppers)

That's it.  Where do you foresee failure/doom in this?  Bear in mind that 
this is how BIND resolver used to behave in versions 4 through 8.2.2 
when CNAME's were not prevented from being in the zone top.

			- Erik

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Thursday, March 01, 2001 10:49 AM
To:	Erik Aronesty
Cc:	'Jim Reid'; [email-masked]
Subject:	Re: cname quick question

> 
> JIM>Please *read* the extract from RFC1034 above. Now *think* about what
> JIM>it says and what that means. Pay particular attention to the last
> JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at
> JIM>moron.example.net. That CNAME is cached by some name server. It can
> JIM>safely use that cached CNAME without having to query the example.com
> JIM>name servers to check that no other record types exist for
> JIM>clueless.example.com.
> 
> 1- Suppose clueless.example.com was at the zone top with a "@ IN CNAME moron.
> example.net."
> 
> 2- The CNAME can still get cached by a name server.  The CNAME can still be
>    safely used from the cache -and no other record types ever have to be quer
> ied -
>    since the SOA and NS record types are transmitted in the authority section
> .

	The problem is once the CNAME is cached you can't retrieve
	the SOA or NS records.  i.e. "dig NS clueless.example.com"
	or "dig SOA clueless.example.com" will FAIL.

	People have as much right to query for NS and SOA records
	as any other type.  You seem to think that the only way
	they can be transmitted is as a side effect of a query for
	some other type.  THIS IS FALSE.

> 
> 4- You example just shows that you arent' paying attention.
> 
> 			- Erik

	Erik you are the one that is not paying attention.  Your
	changes will not interoperate cleanly with the exist resolvers.

	It doesn't matter how many time you say they will when you
	have proved by your own examples that they don't.

	Mark
> 
> 
> --- thread below ---
> 
> -----Original Message-----
> From:	Jim Reid [SMTP:[email-masked]]
> Sent:	Thursday, March 01, 2001 5:16 AM
> To:	Erik Aronesty
> Cc:	[email-masked]
Subject:	Re: cname quick question
> 
> >>>>> "Erik" == Erik Aronesty <[email-masked]> writes:
> 
>     >> 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.
> 
>     Erik> Exactly.  How does having a CNAME at the zone-top cause this
>     Erik> to be an error?  For that mater how does having an SOA
>     Erik> record fail to allow cached CNAMES to be used without
>     Erik> checking an authoritative server for other RR types?  It
>     Erik> doesn't.  Because the SOA record is used for zone transfers
>     Erik> and cache/timing information itself.  The RFC neglected to
>     Erik> mention that.  That's all.
> 
> JIM>Like Tal Dayan, you are being obtuse or deliberately provocative.
> JIM>Please *read* the extract from RFC1034 above. Now *think* about what
> JIM>it says and what that means. Pay particular attention to the last
> JIM>sentence. Hint: suppose clueless.example.com was a CNAME pointing at
> JIM>moron.example.net. That CNAME is cached by some name server. It can
> JIM>safely use that cached CNAME without having to query the example.com
> JIM>name servers to check that no other record types exist for
> JIM>clueless.example.com.
> 
> 1- Suppose clueless.example.com was at the zone top.
> 
> 2- The CNAME can still get cached by a name server.  The CNAME can still be
>    safely used from the cache -and no other record types ever have to be quer
> ied -
>    since the SOA and NS record types are transmitted in the authority section
> .
> 
> 4- You example just shows that you arent' paying attention.
> 
> 			- Erik
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

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

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 01 Mar 2001 17:41:38 -0500

> --> The query will not fail if the algorithm is follwed.

No, Erik, the results will be *inconsistent*, in the case of a non-authoritative,
recursive nameserver. If it *only* has the CNAME cached, then the SOA of the alias
target will be returned. But if QNAME's SOA record is cached, then it will be
returned instead. Work through the algorithm in both cases.

Surely you can see how unacceptable it is for a server to give inconsistent
answers for the same recursive query, based on the vicissitudes of what records it
happens to have cached at any given point in time...

> other domains in the zone file.

What do you mean by "requests which prevent chaining"? With the rules the way they
are now, chaining always occurs for CNAMEs, except for the DNSSEC-related records
which have already been noted.

Or, are you suddenly switching from "the way things are now" to "the way things
would be if my 'NS and SOA queries do not chain' proposal were adopted"? In order
to avoid misunderstandings, please take care to distinguish between actual and
hypothetical situations.

> Likewise, the NS records will only be used

Except for referrals, NS records in the authority section are optional anyway...

- Kevin

---

From: [email-masked]
Date: Fri, 02 Mar 2001 10:37:08 +1100

[ people, please stop responding to this thread.  cluelessness has been
  sufficiently demonstrated that i prefer to approve no further postings
  on this topic.  -- randy ]

> then be returned from the canonical name.

	Correct.  You want to have both a CNAME and SOA and a NS
	RRset at the same owner name.  Now depending upon the order
	of queries made I get *different* responses for a SOA and
	NS queries.

	This is why your proposal does not interoperate with the
	current resolvers despite everything you keep saying.
> --> The query will not fail if the algorithm is follwed.

	The query did fail as it did not return the "correct" SOA /
	NS record.  It did follow the algorithm.  It looked for
	a SOA / NS record in the cache failed to find one, found
	a CNAME and followed it.

	Now DNSSEC went ahead with the same problem.  However in
	the DNSSEC case it was with a new types knowing that the
	existing base would not cache the new types.  Anyone look
	up a DNSSEC record knows that they might have this failure
	mode and can take steps to ensure that it is not a problem.

	Your wanting to do the same thing with well known types
	that will be cached.  You are proposing a change that will
	destabalise the existing base.  While failing to acknowledge
	that it will do that.

	You keep saying that pre 8.2.3 supports CNAME and SOA / NS
	records at the same node, despite us telling you as the
	developers that it was not supported, and that anyone with
	those versions can check that it was not supported.  Use
	a tool other that nslookup and make the queries of a zone
	with and without a CNAME at the apex and look at the
	differences in the answers returned.  They don't just vary
	by just the contents of the records.  Try to perform a zone
	transfer it will FAIL.

	Now Eric of all the real life examples you have seen for
	CNAME vs SOA, would they not have also been solved by the
	solution space to the CNAME vs MX issue.   I know I have
	seen vastly more complaints about CNAME and MX vs CNAME
	at top of zone.

	I also know that people want to be able to mail to
	[email-masked] at the same time as the want to be able
	to use http://example.com where the http is served by a
	hosting company and the mail is in house.  Adding support
	for CNAMES at top of zone does not solve this problem.

	It would solve the plain http://example.com but we all
	know that is the less common and a short term problem
	that invariable graduates into the bigger problem.
	
	You have been told to write your proposal as a draft.  Do
	that listing all the ways that it breaks existing functionality,
	how existing servers will behave under the new regime
	including the effect on the old caches when lookup data
	below the zone apex and the resulting additional traffic,
	list the percieved benefits over the solution space for MX
	vs CNAME.   Be sure to check a number of different caching
	servers from different sources.  Don't assume that they
	all have BIND's behaviour when it comes to dealing with
	proposed change.

	Go read RFC 2308.  It made non-compatible changes.  It also
	listed all the sort of things we have been asking you to
	list so that they could be evaluated and be documented as
	a reference for people that were having problems in the
	future.

	Mark