Re: DNSSEXT Yokohama Minutes

[Derek Atkins <derek@ihtfp.com>]

David Blacka <davidb@verisignlabs.com> writes:

> If I get NXT records (opt-in or otherwise) in the authority section of
> a response, I need to cache these NXTs as properties of the qname, but
> why can't I ALSO cache them as ordinary records?

Let me see if I can remember this example that Roy worked through
with me in Yokohama (at a very expensive bar, eh Roy? ;)

Assume you've got this record at time T0:

 a in ...
   in nxt k ...

At time T1 you make a query for f and get the "a in nxt k" response.
Now, at time T2 the zone is changed and you now have records:

 a ...
   in nxt d
 d ...
   in nxt k
 
At time T3 you make a query for e.  You now have two overlapping NXT
records, a->k and d->k.

Now you make a query for d.  What do you do?  You've now got an
authoritative negative query for "d" in your cache, but you've also
got an authoritative positive response for 'd' in the zone (not
cached).

Note that this is not just a problem with Opt-in, but opt-in makes the
problem worse because records can not only change in terms of
existance but also in terms of whether they are signed.

Hopefully Roy can better explain this particular issue.

>  Roy> Sure, explicit queries for qtype NXT are okay, as long as cache
>  Roy> follows the query, and NOT _reconstruct_ responses from
>  Roy> cache. If it has been cached as an individual
>  Roy> QNAME/QCLASS/QTYPE, than the cache can simply respond that. But
>  Roy> again, simply replay the response, not reconstruct.
> 
> Specifically, what pitfalls exist in reconstructing a positive
> response to an explit NXT query?

That's not the issue.  The issue is if you make a request for
NameA/ClassA/TypeA and cache the NXT response, then make a request for
NameB/ClassB/TypeB, you should not respond with the NXT obtained from
the A/A/A request.  In other words, you should not promote the NXT
response from request 1 across to request2 unless the Name/Class/Type
are the same.

> The reason I am pursuing this is that I'm trying to imagine how I
> would build a cache, and I am thinking that I would like to store the
> NXT records just like any other record in my cache, while having other
> cache values have pointers to it (rather than storing the NXT set in
> toto with the original qname).

NXT records are just special..  The reason is that they can cause a
failure in other records, which can lock out a large portion of a zone
for long periods of time.

As I said, hopefully Roy can better explain this.

> David Blacka    <davidb@verisignlabs.com> 
> Sr. Engineer    Verisign Applied Research

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com

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