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

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Jun 2003 15:32:58 +0000

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

hmmmm.

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

the NOTIFY spec says the "answer" section only pertains to SOA "at this time"
and i think that's all we need to (not) say about NXT.

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

i guess i can imagine an online signer that used UPDATE to put NXT RR's in.

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

if someone puts an NXT into an UPDATE or NOTIFY (or QUERY with QR=0) then
a receiver will either ignore it or FORMERR or act on later knowledge, all
of which would be reasonable.  i don't think we need to specify it directly.

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

for QUERY with QR=1 where NXT is actually specified, yes, those other bit
patterns would be invalid.

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

i think that going at this from the OPCODE standpoint isn't useful.

--
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, 11 Jun 2003 03:31:20 +0000

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

yes.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Jun 2003 16:24:51 +0000

> So, the suggestion for this case is to state:
> 
>    o Name servers MAY reject (refuse to load) zones with any wild card domain
>      name owning an NS RR set.
>    o Name servers MAY refuse to accept updates to add NS RR sets to a wild
>      card domain name.
> 
> MAY, not MUST. ?

i'd like SHOULD.