Re: DNSSEXT Yokohama Minutes

[David Blacka <davidb@verisignlabs.com>]

>>>>> "Roy" == Roy Arends <roy@logmess.com> writes:

 Roy> On Tue, 3 Sep 2002, David Blacka wrote:
 >> >>>>> "ogud" == Olafur Gudmundsson <Olafur> writes:
 >> 
 ogud> This will not happen on my watch, but Opt-in camp needs to
 ogud> answer the open questions in their open park.
 >> 
 >> Could somebody please restate the open questions about opt-in?  Feel
 >> free to add new open questions.

 Roy> As I recall, we need to write:

 Roy> - The impact on: Authoritative servers (but this is already
 Roy> clear in draft IMHO)

 Roy> [caching] resolvers (basically the change to the resolver
 Roy> algorihm)

More specifically, what needs to be in the opt-in draft that isn't
already there about this?  Or is what is in the draft just not clear
enough? (I am asking the list, not just Roy)

 Roy> - The current issues:
 Roy> Clear AD-bit on an opt-in response.
 Roy> (I think this will be taken care of by the "AD-bit is
 Roy> secure" authors ).

Ok.  Does this mean the AD bit behavior does not need to be opt-in
draft at all?  Or just a reference to a new AD-bit draft?

 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.

What I do understand is this: opt-in creates a case where for a
postive response, a cache must be able to return the covering opt-in
NXT that goes with the response, and that NXT record does NOT share
its name with qname.  Hence, the cache should store the NXT records as
properties of the original qname.  I also know that this case also
shows up in negative caching, with or without opt-in.  Well, there
will most likely be more than one NXT record to cache in this manner,
as there will most likely be at least one wild-card proof NXT.

But why shouldn't the cache be able to respond for an explict query
for one of those NXT records?

 Roy> Some of the above were stated by Olafur last week during the DS
 Roy> workshop, others were a result of research by Rob Austein and me
 Roy> (which was presented at Yokohama).

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

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