[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q-10: Reaction to "Silly" NXT's

First I'll assume the context of this is that the NXT is in the authority section and appears in one of the messages as described in RFC 2308, including the referral.

At 12:14 +0200 6/3/03, Olaf M. Kolkman wrote:
1. You only process NXT RRs if the zone from which the NXT RR is
  returned is supposed to be secured. This is determined either by the
  DS (or relevant NXT) from the parent zone or by configuration of the
  zone as an island of trust.
The right way to do this step is to take the NXT and it's SIG and try to build a chain of trust back to a configured key. It's not important to establish the configuration of the zone when you are starting from an NXT and SIG (NXT) - and can positively verify them.

On the other hand, making a determination that a NXT and/or SIG is needed if they are absent from a response. In this case, determining that a zone is signed, ergo, expect NXT and SIG is done.

If you do have an NXT and SIG but are unable to establish a chain of trust, you need to determine if the zone is supposed to be signed. It could be that they are stuffed, are replayed, or are just from a cranky old cache with a too-high TTL for the data. Depending on what the reason is (which cannot be decided from the in-band information), you response may vary. But, we have a decidability issue here, so we're stuck.

2. Given that the zone is secure you only process NXT RRs to proof
  non-existence of names or non-existence of RRtypes.
I disagree with this...as before. If I can validate the NXT, the zone must be secured. If I can't I need to either get the NXT (absent but expected) or I discard the NXT (present but unexpected).

3. If either a NXDOMAIN or NOERROR empty answer section is received one
  first verifies the SIG over the NXT RR to check if that has not been
  tampered with. If it has been tampered with mark the answer as
  BAD. (Bad luck, either the zone served incorrect data or your answer
  has been tampered with)

  The SIG(NXT) is correct so we have to verify if the NXT RR is relevant
  to the answer.

  (If the answer is NOERROR and a non-empty answer section we have a
   direct match and the NXT RR is IMHO irrelevant; all the proof
   for the data in the answer section is enclosed in the answer)
This is the step where I realized that there's something missing from the discussion. Once you have cryptographically determined that the NXT is valid (let's assume this is the processing path), then you need to understand the context to see if it is relevant.

In a referral message, with a negative indication for the DS, you need to see that the NXT claims that there is no DS but there is a SIG and NXT for the name, as well as NS's. If that's not the case, the NXT is inappropriate - or falls under the silly state proposal.

If you are worried that a delegation from a secured zone using an experimental version of NXT to another secured zone will now mean that no secure delegation will work, consider that in such a referral, you do not see the NXT, just the DS.

If the answer is an NXDOMAIN, then the NXT is only appropriate if the QNAME is between the owner name and the RDATA's next name.

If the answer has NOERROR and an empty answer section, then the QNAME has to equal the ONAME and the QTYPE flag must be absent from the RDATA.

If the answer has NOERROR but has 1 or more CNAMEs in the answer, the QNAME has to own a CNAME whose RDATA name (owns another CNAME whose RDATA name) is the same as the NXT.

(Can a CNAME chain end in an NXDOMAIN?)

If the answer has NOERROR and has data in the answer that is revealed to be a wild card synthesized answer, then the owner of the NXT has to be the closest encloser.

So - the context of the NXT determines if it is appropriate. The determination of appropriateness is orthogonal to cryptographic verification.

4a. If the answer was a NXDOMAIN answer then one has to check if the
  original qname is enclosed in the NXT RR's owner name and the NXT
  RR's nxt_domain_name.

4b. If the answer was NOERROR no data one verifies that the ownername
  of the NXT RR is the same as the QNAME and verifies that the QNAME
  is not in the nxt_bitmap.
Yeah, but there are a lot more cases (c,d,e,...) as I mention above. (I don't guarantee completeness of my list.)

In both 4a and 4b one does never check if the NXT or the SIG bit are
actually set. So if Ed's proposal should state that the "listener"
would have to do an additional check before step 4 i.e. Verify if the
NXT and/or the SIG bits are set and continue with step 4 if the bits
are set and go into silly state if the bits are not set. (MUST
language)
Maybe - you need to make the check go hand-in-hand. Yes, the experimental semantics that make the NXT appear to be in a silly state might redefine appropriateness, but to the simple resolver, it only follows the traditional rules of appropriateness.

Independent of going "Ed's check" I also think that the protocol ID
should state  that one should (or maybe even must):

 - when verifying the NXDOMAIN response not use the NXT bitmap.

 - when verifying the NOERROR emtpy answer one should only perform the
   qname==ownername check and one should ignore the nxt_domain_name
   ignored.

Well, you need to also handle the CNAME and wild card "redirects".


To rehash: in my interpretation of the specs the NXT and SIG bits are
not looked at at all; one MUST only look at what is relevant to the
answer given. Ed's proposal introduces an additional check before actually
using the content of the SIG RR to validate answers.



  Last night I was toying with a server that dynamically synthesizes



"I" == Bert? ;)




  This should not break validators because I assume, based on the step
  4b, that for validation of a NOERROR-empty answer response the
  nxt_domain_name is irrelevant. Since caches are supposed to cache on
  the QNAME,QCLASS,QTYPE tripled there should not be any problem
  putting bogus name intervals in the NXT RRs that proof non-existence
  of QTYPE for caches either...



'Zackly.




  (yeah yeah.. this is a sick waste of time)



I expect to see a link and man page on Bert's site in short order.

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

Digital cameras are to film cameras as Etch-A-Sketches are to canvases.

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