Subject: RE: RCODEs in EDNS

From: James Gilroy <[email-masked]>
Date: Wed, 23 Feb 2000 11:12:14 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> 
> 	What's the point in doing it?
>

Excellent question Mark.

My answer would be clarity.  I consider it an exercise in cleaning detritus
from the spec.  I guess how much appeal that has depends on how anal one is
about such stuff.  I'd like to push towards having a spec that's clear and
easily implementable from scratch.

I would also note, that there's probably more than one existing
implementation that doesn't do this correctly.  I know of one -- the first
one I wrote.  I assumed that the Authority bit was sufficient to distinguish
between empty-auth responses and referrals.  Once caching of empty-auth
responses started, that code was broken.  Currently to do this correctly you
must completely parse the packet to determine whether the answer is a
referral or empty-auth response.  That just strikes me as unnecessarily
complex.

So yeah.  I'd agree that one way to do something is better.  But moving
forward with a GOOD way to do something also has advantages.  

	jim

> 	Servers and clients are still going to have to do it the
> 	old way when talking to old client and servers so the code
> 	to do this has to exist.
> 
> 	In general having only one way to do something leads to less
> 	errors.
> 
> 	Mark
> 
> > One issue that i've always found annoying, that i'd like to 
> see cleaned up
> > in EDNS is the overloading of the NO_ERROR RCODE in queries.
> > 
> > Currently NO_ERROR can mean
> > 	-- have an answer
> > 	-- empty auth response (name exists, RR set doesn't)
> > 	-- referral
> > 
> > To correctly distinguish the later two response from some BIND
> > implementations, involves testing a bunch of bits or 
> further parsing the
> > packet.  (It was never clear to me why empty auth response 
> didn't have an
> > RCODE to begin with as name error did.)
> > 
> > I think it would be a useful service -- primarily to 
> implementors, but also
> > to anyone diagnosing problems, looking at traces, etc. -- 
> to clean this up
> > now.
> > 
> > I'd propose using
> > 	NXRRSET -> empty auth response (that's exactly what it 
> means in the
> > update case)
> > 	NOTAUTH -> referral (sorta captures the idea)
> > 
> > The idea would be that EDNS aware implementations would 
> just tack these onto
> > the revelant case statements in their packet parsers and do whatever
> > processing they now do when they detect these conditions by 
> the appropriate
> > set of tests.
> > 

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