Subject: Re: another question about interpretation of the scriptures: cname chains

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Apr 2006 15:03:55 -0400

Mark, I don't understand your reply.

When I say that there is only one RCODE, I mean that the response can 
only reply with one "state."  I.e., in the case that there is a CNAME 
record matching the original query but the server gets a service 
failure trying to follow the chain, should the lone RCODE field 
report that the query name was found and a CNAME was successfully 
matched there, or that a service failure occurred following the CNAME.

What I meant by multiple queries and one return code field was that 
if one of the queries ended in a service failure and another in a 
name error, how do you indicate this?  You can report only one. 
CNAME processing is akin to multiple queries - because the sought 
name keeps changing.

At 9:00 +1000 4/5/06, Mark Andrews wrote:
>>  At 17:18 +0000 4/3/06, Paul Vixie wrote:
>>  >i know that an authority server can emit an incomplete cname chain if it
>>  >leads outside the servers's authority zone(s).  but what should a recursive
>>  >server return if a cname chain from the qname leads to an NXDOMAIN?  my
>>  >intuition says "return NXDOMAIN" since the nonterminal cname chain has no
>>  >value and no meaning to an RD=1 initiator.  but i note with 
>>dismay that BIND
>>  >actually emits the nonterminal chain as if it were an answer to 
>>the question.
>>
>>  This is a dilemma for the same reason why the query count can't be
>>  more than 1.  There's only one RCODE field, that's the problem.
>
>	No.  The problem is that NXRRSET didn't exist in RFC 1034 and
>	that authoritative servers stopped emitting SOA records in the
>	authority section on NXRRSET/NXDOMAIN to work around a broken
>	client (the later is hearsay).
>
>	You can disambiguate a NXRRSET from a incomplete answer if
>	the SOA record is always there.
>
>	Note: this was pointed out in RFC 2308.
>
>>  Let's say there's "first CNAME second", with first in the authority
>>  of the server and second not, further, not even existent.
>>
>>  If the RCODE is for the first, then it ought to be "NO ERROR" as
>>  you've found the name ("name error" means the name lookup failed).
>>  There's no RCODE for "PARTIAL ANSWER" which is most appropriate when
>>  just a CNAME set is returned but not asked for.  If the RCODE is for
>>  the second, then "NAME ERROR" is appropriate.
>>
>>  Hmm, what's a server to do?
>
>	The presence of tha CNAME / DNAME indicates that the original
>	QNAME exists.  You can't look at the RCODE in isolation.
>
>>  First question, is this a real problem, is it begging to be solved?
>>
>>  Second question, does it matter?  Won't resolvers be smart enough, if
>>  properly implemented, to deal with the two responses?  I mean,
>>  coherency doesn't mean consistency.
>>
>>  Up to me, using a 30 seconds-of-thought heuristic, I would say that
>>  the server use the RCODE for first if there is a problem with second.
>>  Let the resolver discover the problem (too), force the work back on
>>  them.  Yes, that means the recursive work goes unused - but that's
>>  operational slop.
>>
>>  --
>>  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>  Edward Lewis                                                +1-571-434-5468
>>  NeuStar
>>
>>  Nothin' more exciting than going to the printer to watch the toner drain...
>>
>>  --
>>  to unsubscribe send a message to [email-masked] with
>>  the word 'unsubscribe' in a single line as the message text body.
>>  archive: <http://ops.ietf.org/lists/namedroppers/>
>--
>Mark Andrews, ISC
>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.
>archive: <http://ops.ietf.org/lists/namedroppers/>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Apr 2006 23:04:47 +0000

> ... CNAME processing is akin to multiple queries -
> because the sought name keeps changing.

i don't agree.  each cname changes the name being described by the rcode.
therefore the rcode describes the status of the final cname target name.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 6 Apr 2006 00:14:30 -0400

>i don't agree.  each cname changes the name being described by the rcode.

Where's the disagreement?  "cname changes the name" is what I mean.

>therefore the rcode describes the status of the final cname target name.

Is that in the specs?  Or is that one interpretation?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar