Re: DNSSEXT Yokohama Minutes

[Roy Arends <roy@logmess.com>]

On Wed, 4 Sep 2002, David Blacka wrote:

> >>>>> "Derek" == Derek Atkins <derek@ihtfp.com> writes:
>
>  >> Specifically, what pitfalls exist in reconstructing a positive
>  >> response to an explit NXT query?
>
>  Derek> That's not the issue.  The issue is if you make a request for
>  Derek> NameA/ClassA/TypeA and cache the NXT response, then make a
>  Derek> request for NameB/ClassB/TypeB, you should not respond with
>  Derek> the NXT obtained from the A/A/A request.  In other words, you
>  Derek> should not promote the NXT response from request 1 across to
>  Derek> request2 unless the Name/Class/Type are the same.
>
> Suppose my caching resolver first issues the following:
>
> Q: foo.bar. IN A
>
> And gets back:
>
> AUTH: a.bar IN NXT g.bar
>       a.bar IN SIG NXT ...
>
> Next, it issues the following:
>
> Q: a.bar. IN NXT
>
> is there a problem returning:
>
> ANS: a.bar IN NXT g.bar
>      a.bar IN SIG NXT ...
>
> ?

Yes, the problem is that you synthesize parts of a negative response to
satisfy a positive response. Next to the TTL issues involved, the matching
algorithm to satisfy the query from cache is horribly complicated,
especially when different caching methods are used for pos. and neg.
caching.

> Or even:
>
> Q: a.bar. IN ANY
>
> ANS: a.bar IN NXT ...
>      a.bar IN SIG NXT ...

If you mean QTYPE=* then this poses another difficulty (DNSSEC, not
Opt-In). With this optimised matching, you might not find a complete
answer.  Since you probably want all record types that exist at an owner
name (listed in the NXT type bit map), but you only get the NXT record
from cache, since that satisfies the matching. There is no way to get a
better response, other then wait TTL+1 second.

> Note that I'm not suggesting that the resolver build negative proof
> out of NXT records that it has in its cache.  You (and Roy)
> illustrated the potential problems with that fairly clearly.

Okay, but the first example looked like you are doing exactly that.

> I am trying to draw a distinction between Roy's stated requirement
> that "[NXT records] MUST NOT be stored as individual records", and a
> slightly weaker restriction that resolvers MUST NOT use cached NXT
> records to construct new negative (or opt-in) proofs.

Wait, it is no problem to cache NXT records as individual records, but
_only_ as a result of a query where QTYPE is NXT.

This is what I said:

     "The other (main) issue is caching of NXT/SIG(NXT). When not
      individually queried for, they MUST be cached as properties of
      QNAME/QCLASS/QTYPE or as an integral part of the entire answer.
      They MUST NOT be stored as individual records."

The key-sentence here is "When not individually queried for". I referred
to type=NXT

Regards,

Roy





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