Re: DNSSEXT Yokohama Minutes

David Blacka <davidb@verisignlabs.com> Tue, 03 September 2002 22:39 UTC

Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16452 for <dnsext-archive@lists.ietf.org>; Tue, 3 Sep 2002 18:39:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mMDl-0007fQ-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 15:32:29 -0700
Received: from h227.s231.netsol.com ([216.168.231.227] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17mMDi-0007fE-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 15:32:26 -0700
Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id 7B0F11AF16; Tue, 3 Sep 2002 18:32:25 -0400 (EDT)
To: Roy Arends <roy@logmess.com>
Cc: namedroppers <namedroppers@ops.ietf.org>
Subject: Re: DNSSEXT Yokohama Minutes
References: <Pine.LNX.4.44.0209032341550.21459-100000@elektron.atoom.net>
From: David Blacka <davidb@verisignlabs.com>
In-Reply-To: <Pine.LNX.4.44.0209032341550.21459-100000@elektron.atoom.net> (Roy Arends's message of "Tue, 3 Sep 2002 23:57:43 +0200 (CEST)")
Date: Tue, 03 Sep 2002 18:32:25 -0400
Message-ID: <kofzwqln5y.fsf@pinion.admin.cto.netsol.com>
Lines: 44
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-mandrake-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD version=2.31
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>>>>> "Roy" == Roy Arends <roy@logmess.com> 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    <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/>