Subject: Re: DNSSEXT Yokohama Minutes

From: David Blacka <[email-masked]>
Date: Tue, 03 Sep 2002 18:32:25 -0400

>>>>> "Roy" == Roy Arends <[email-masked]> writes:

 Roy> The other (main) issue is caching of NXT/SIG(NXT). When not
 Roy> individually queried for, they MUST be cached as properties of
 Roy> QNAME/QCLASS/QTYPE or as an integral part of the entire
 Roy> answer. They MUST NOT be stored as individual records. However,
 Roy> these are DNSSEC issues which are inherited by Opt-In. In other
 Roy> words, caches are not more then a "response replay" box, which
 Roy> is only allowed to alter the TTLs of records and the
 Roy> [E]DNS-header.
 >> 
 >> I do not understand the harm in also caching the NXTs as individual
 >> records.  This is probably because I do not fully understand the
 >> corner case you and Rob Austein investigated.

 Roy> Wait, thats not what I wrote. When explicitly queried for, yes, the cache
 Roy> can replay the response if, and only if it was cached as result of a
 Roy> previous explicit query for that NXT.

What I was really asking is why the "only if it was cached as result
of a previous explicit query for that NXT" condition?

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?

 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?

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

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

--
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: Derek Atkins <[email-masked]>
Date: 03 Sep 2002 23:20:05 -0400

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

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

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

> Sr. Engineer    Verisign Applied Research

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Roy Arends <[email-masked]>
Date: Wed, 4 Sep 2002 09:17:51 +0200 (CEST)

> with me in Yokohama (at a very expensive bar, eh Roy? ;)

Yes, it still hurts :-)

> Hopefully Roy can better explain this particular issue.

This is indeed the problem. This problem exist with any accidental
"interval overlap".

The example I gave in Yokohama had not a match with any QNAME:

cached was:

a NXT e
c NXT f

and the query is for d. Which proof of non-existence does a cache return.

> response from request 1 across to request2 unless the Name/Class/Type

Bingo.

> As I said, hopefully Roy can better explain this.

You did it very well.

NXT records are more a statement on other records/types then that they are
individual records. (or: NXT records just suck).

Roy

---

From: David Blacka <[email-masked]>
Date: Wed, 04 Sep 2002 09:53:57 -0400

>>>>> "Derek" == Derek Atkins <[email-masked]> writes:

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

?

Or even:

Q: a.bar. IN ANY

ANS: a.bar IN NXT ...
     a.bar IN SIG NXT ...

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.

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.

Of course, I think that this particular example that I'm bringing up
is not very natural.  I'm not sure that this particular query sequence
would occur except for debugging.

 >> toto with the original qname).

When I said this, I was not imagining that the resolver be able to do
anything with the NXT records other than respond to a direct query for
them.

 Derek> As I said, hopefully Roy can better explain this.

You did a pretty good job.

---

From: Derek Atkins <[email-masked]>
Date: 04 Sep 2002 10:29:06 -0400

[example snipped]

Let me give a different example (similar to before).  Note that
between query-1 and query-2 the zone has changed.

Q: foo.bar. IN A
AUTH: a.bar IN NXT g.bar
      a.bar IN SIG NXT ...

Q: baz.bar. IN A
AUTH: a.bar IN NXT d.bar
      a.bar IN SIG NXT ...

Q: a.bar IN ANY (or IN NXT)
AUTH: ???

What do you return here?  This is still the same problem.  Do you
return both?  Do you choose one?

> would occur except for debugging.

Yes, but as I (hopefully) pointed out, it can be just as problematic.

> You did a pretty good job.

Thank you.  I wasn't so sure last night.

-derek

---

From: Roy Arends <[email-masked]>
Date: Wed, 4 Sep 2002 16:41:57 +0200 (CEST)

> is there a problem returning:

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.

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

> illustrated the potential problems with that fairly clearly.

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

> 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