Re: [dnsext] Fwd: RFC 2308 & RFC 4035

Edward Lewis <Ed.Lewis@neustar.biz> Sun, 27 February 2011 14:43 UTC

Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD713A6938 for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 06:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq0qX89FWSm4 for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 06:43:13 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 951283A692E for <dnsext@ietf.org>; Sun, 27 Feb 2011 06:43:13 -0800 (PST)
Received: from hway-t500.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p1REi3ep070458; Sun, 27 Feb 2011 09:44:04 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz)
Received: from [192.168.128.192] by hway-t500.cis.neustar.com (PGP Universal service); Sun, 27 Feb 2011 09:44:11 -0500
X-PGP-Universal: processed; by hway-t500.cis.neustar.com on Sun, 27 Feb 2011 09:44:11 -0500
Mime-Version: 1.0
Message-Id: <a06240800c9900f2a6eff@[192.168.1.103]>
In-Reply-To: <20110226234237.9E59DB00438@drugs.dv.isc.org>
References: <a06240805c98db61801c2@[10.31.200.114]> <20110226003214.0E1BFAFA28D@drugs.dv.isc.org><a06240800c98ed0f7a8c5@[10.31 .200.114]> <20110226234237.9E59DB00438@drugs.dv.isc.org>
Date: Sun, 27 Feb 2011 09:37:40 -0500
To: dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Feb 2011 14:43:14 -0000

At 10:42 +1100 2/27/11, Mark Andrews wrote:

>We do this for NXDOMAIN today.  If we ask for A foo.example and get
>back a NXDOMAIN then the cache gets asked for AAAA foo.example we
>use that NXDOMAIN.

That's cool - it complies with NCACHE (in a part I didn't quote).  I 
know you (as author know that, but I'm just saying it here.

>Using the NSEC/NSEC3 that matches the <qname,qclass>
>really no different.

There's a bit if difference.  I've been dealing with zones that are 
highly dynamic.  Signing such zones can be a challenge.  Besides the 
number of signatures needed for the positive answers, which is simply 
part of the workload is the generation and signing of the negative 
answers.

The way that NCACHE is written today, a simplifying assumption can be 
made for the NSEC/3 bit map if the negative cache is really type 
specific, basically returning a bit map that says "I don't have 
*that*".  If the negative cache is going to be name specific then the 
NSEC/3 has to state exactly what is there at the moment.

I'm asking this in the sense that on paper I would only need to send 
back "I don't have that" but if the deployed code tries to be 
tighter, I have to craft bit maps for each combination.  In addition 
to the provisioning and signing overhead, having to determine what's 
present "right now" will have to be done.

Even if that is pulled off, negative caches could be subject to 
higher false-positive negative-cache hits when sets become available. 
This could be a case where over-tightening on the security checks is 
a bad thing.   In this case, it isn't really the security, but the 
inferences made about the authority by the cache.

>The much more interesting question is infering NXDOMAIN for a
><qname,qclass> we havn't asked for.  Named already does this when
>looking for DLV records when validating but is expected by all
>parties involved.

Again, this is forbidden in RFC 2308 but brought up in resimprove.  I 
have to say there's something seductive about the idea, but it's like 
a siren's call to make caches take over being authorities.  I think 
that's something that should be resisted.  (And this also related to 
inferring across types at a name.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"