Subject: Re: DNSSEXT Yokohama Minutes

From: David Blacka <[email-masked]>
Date: Tue, 03 Sep 2002 16:39:08 -0400

>>>>> "Roy" == Roy Arends <[email-masked]> 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    <[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: Olafur Gudmundsson <[email-masked]>
Date: Tue, 3 Sep 2002 17:27:26 -0400 (EDT)

On Tue, 3 Sep 2002, Roy Arends wrote:

> On Tue, 3 Sep 2002, David Blacka wrote:
>
> As I recall, we need to write:
>
> - The impact on: Authoritative servers (but this is already clear in draft
>                  IMHO)
>                  [caching] resolvers (basically the change to the resolver
>                  algorihm)
> - The current issues:
>                  Clear AD-bit on an opt-in response.
>                  (I think this will be taken care of by the "AD-bit is
>                  secure" authors ).

This is for Opt-in to specify, not AD due to dependancy reasons, this
definition is only needed if both AD and Opt-in are part of the standard.

For the record: this relates to use of NXT between the two names
on the NXT (record name and the target name).
In DNSSEC where AD bit is used (either RFC2535 or AD-secure definition),
the AD bit can be set on responce if it is authenticated denial with NXT,
for the QNAME if the
	NXTNAME  == QNAME or (NXTNAME < QNAME and QNAME < NXTargetNAME )

Opt-in NXT must define that this that NXT can only be used when
NXTNAME == QNAME to set the AD bit.

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

Then there is the minor issue of bytes on the wire, are responses
from Opt-in zones smaller/same/larger than from regular DNSSEC zones.

And then there is the issue on memory usage in caches, there was an
assertation that opt-in zones cause more memory consumption than other
DNSSEC zones.

	Olafur

---

From: Roy Arends <[email-masked]>
Date: Tue, 3 Sep 2002 23:57:43 +0200 (CEST)

> enough? (I am asking the list, not just Roy)

And I was just repeating comments. The draft is pretty clear on that, but
hey, who am I to judge :-)

> draft at all?  Or just a reference to a new AD-bit draft?

Then lets just fully specify it, better double effort that no effort at
all.

> corner case you and Rob Austein investigated.

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

> for one of those NXT records?

Sure, explicit queries for qtype NXT are okay, as long as cache follows
the query, and NOT _reconstruct_ responses from cache. If it has been
cached as an individual QNAME/QCLASS/QTYPE, than the cache can simply
respond that. But again, simply replay the response, not reconstruct.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Sep 2002 07:40:33 -0400

>corner case you and Rob Austein investigated.

(Reading this a few days late, so this may have been answered already...)

The danger comes from NXT's whose reported owner name is the result 
of a wildcard match.  Let's say I ask for data whose QNAME that does 
not exist but matches a wildcard.  Further, the QTYPE is absent at 
the wildcard.

So there will be a returned NXT that looks like it belongs to the 
QNAME (but the SIG label count will contain info that says it is a 
wildcard).  Holding this NXT isn't dangerous, and it is fine to 
replay it (from the cache) for a repeat of the same query (QNAME, 
QTYPE, and QCLASS).

The "danger" is in the cache's trying to use the NXT to respond to 
any other query - QTYPE'.  Because the NXT is synthetic, it might be 
used incorrectly to declare QTYPE' does not exist (or that a QTYPE at 
it is absent).  So the danger is not caching the record, the danger 
is in incorrectly using the cached, synthetic NXT.

I can't think of any damage in answering with the cached, synthetic 
NXT if the QNAME is the same as the original and the QTYPE=IN.  (And 
QCLASS is appropriately set - off hand I don't know what is 
"appropriate.")
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer