Subject: NXT processing at resolvers, the anomalies...

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Jun 2003 09:35:34 -0400

Probably the weakest link in the DNSSEC documentation has been on how 
a resolver and verifier need to work with the protocol.  I've started 
in, part time now, on trying to clarify topics in this area.

I've decided that the NXT is the first area that looks interesting to 
me.  (As opposed to the area that needs the most work, etc.)  This is 
a bit of the outgrowth of the wild card draft (the -00 WG version is 
being discussed by Bob and myself) and a bit of an outgrowth of the 
silly state thread.

My approach is to walk through the traditional DNS message 
definitions and try to figure out how NXT's play a role and vice 
versa.  The first stop is the OPCODE.

So far OPCODE 0 is the query/response, including the "normal 
messages" as well as AXFR and IXFR.  There's quite a bit of work to 
do here, especially with QR=1.

OPCODE 1 has been deprecated, OPCODE 2 seems to have been a 
non-starter, or whatever happened died early on.  OPCODE 3 is listed 
as reserved by IANA.  OPCODE 4 is NOTIFY and OPCODE 5 is UPDATE.

I plan to say that the presence of an NXT in OPCODE 1,2,3 are 
undefined as those messages ought not to be seen in the wild.

I can't imagine a need to see an NXT in a NOTIFY message.  Is there 
one?  Ought it be outlawed?

I also can't imagine a need to see an NXT in an UPDATE message.  Same 
question here as before.

What I am intending to state as an "error" reaction is that if an NXT 
seems out of place to the resolver, the resolver ought to cease 
processing on the message and discard it and return to the code point 
where new network input is retrieved.  This is meant to counter act 
anyone inserting messages that are meant to confuse the resolver by 
throwing in malformed messages.

This is a bit drastic in one sense.  It means that if we decide later 
to define NXT's as being valid in NOTIFY or UPDATE, a resolver we 
define today will discard the message.  On the other hand, this 
definition is safer and is crisper.

Finally, one other question.  Besides looking at OPCODE, it seems 
that the only times in which an NXT would appear in a message is when 
the RCODE is either NoError or NXDomain.  FormErr, ServFail, NotImp, 
and Refused will cancel the regular processing earlier in the 
algorithm.  All other RCODE's are associated with UPDATE, TSIG, TKEY, 
or EDNS0 - the latter three won't involve NXTs - I think.  So - is it 
safe to assume that if RCODE != NoError or NXDomain, then an NXT is 
not supposed to be there?

PS - When looking at this, assume you are only concerned with being 
the resolver.  Don't wonder how the data got there, but that it's 
there and you have to figure out what it means.  For now, I'm trying 
to throw away the non-sense cases - with OPCODE=0, QR=1, and RCODE=0 
or 3, there's a lot of fun stuff to write.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Okay, okay, the previous sig wasn't all that good...

--
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: Edward Lewis <[email-masked]>
Date: Tue, 10 Jun 2003 22:35:50 -0400

At 15:32 +0000 6/10/03, Paul Vixie wrote:
>i think that going at this from the OPCODE standpoint isn't useful.

Well, the OPCODE tells how to interpret the message - i.e., instead 
of question, answer, authority and additional, an UPDATE is zone, 
prereq, update, additional.  NXT's in the authority mean something, 
in update they are just data.  In NOTIFY, there's nothing special 
about NXT's.  That's as far as I'd go.

Would it be safe to say that the only special processing we need to 
be concerned with is if the NXT is in the authority section of a 
QUERY?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer