IETF Logo Mail Archive

Re: DNSSEXT Yokohama Minutes

Derek Atkins <derek@ihtfp.com> Wed, 04 September 2002 14:37 UTC

Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02147 for <dnsext-archive@lists.ietf.org>; Wed, 4 Sep 2002 10:37:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mb9h-0006cv-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 07:29:17 -0700
Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17mb9d-0006cV-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 07:29:13 -0700
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA01673; Wed, 4 Sep 2002 10:29:07 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA10466; Wed, 4 Sep 2002 10:29:06 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA16243; Wed, 4 Sep 2002 10:29:05 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA12302; Wed, 4 Sep 2002 10:29:06 -0400 (EDT)
To: David Blacka <davidb@verisignlabs.com>
Cc: Roy Arends <roy@logmess.com>, namedroppers <namedroppers@ops.ietf.org>
From: Derek Atkins <derek@ihtfp.com>
Subject: Re: DNSSEXT Yokohama Minutes
References: <Pine.LNX.4.44.0209032341550.21459-100000@elektron.atoom.net> <kofzwqln5y.fsf@pinion.admin.cto.netsol.com> <sjmd6ruigpm.fsf@kikki.mit.edu> <koadmxlv2i.fsf@pinion.admin.cto.netsol.com>
Date: Wed, 04 Sep 2002 10:29:06 -0400
In-Reply-To: <koadmxlv2i.fsf@pinion.admin.cto.netsol.com>
Message-ID: <sjmn0qxhlql.fsf@kikki.mit.edu>
Lines: 51
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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,DOUBLE_CAPSWORD,OPT_IN version=2.31
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

David Blacka <davidb@verisignlabs.com> writes:

[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?

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

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

>  Derek> As I said, hopefully Roy can better explain this.
> 
> You did a pretty good job.

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

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

v2.46.0 | Report a Bug | By Email | System Status