Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals

Edward Lewis <Ed.Lewis@neustar.biz> Wed, 30 March 2011 12:11 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 909FD28C15F for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 05:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level:
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 fI8s82i0rVoy for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 05:11:09 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0C3BB28C108 for <dnsext@ietf.org>; Wed, 30 Mar 2011 05:11:07 -0700 (PDT)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2UCCgtX075642; Wed, 30 Mar 2011 08:12:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.115] by Work-Laptop-2.local (PGP Universal service); Wed, 30 Mar 2011 08:12:43 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 30 Mar 2011 08:12:43 -0400
Mime-Version: 1.0
Message-Id: <a06240800c9b8ccb5485c@[10.31.200.119]>
In-Reply-To: <4D931660.1000004@isc.org>
References: <alpine.LSU.2.00.1103281507410.5244@hermes-1.csi.cam.ac.uk><8EA8D1A36B8F49 68ABE973C39CA5E0E0@local><a06240800c9b78d52751f@[10.31.200.116]><FCB25297B FF0419692724D36AF3BC99E@local> <a06240804c9b79c870558@[10.31.200.119]><55128075215341BD92DCAAD00450FA85@l ocal> <a06240809c9b7b7143e51@[10.31.200.119]> <3B987BF13718424BBA818C248C428E64@local> <a06240800c9b7c543104f@[10.31.200.119]> <A5D8841CEB8F4BF9A007C8B6408C363C@local> <a06240801c9b7d3b57307@[10.31.200.119]> <4D931660.1000004@isc.org>
Date: Wed, 30 Mar 2011 08:10:02 -0400
To: Jelte Jansen <jelte@isc.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>, dnsext@ietf.org
Subject: Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals
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: Wed, 30 Mar 2011 12:11:14 -0000

At 13:39 +0200 3/30/11, Jelte Jansen wrote:

>as with another example you used in a previous discussion, it would seem
>you are arguing for not doing negative caching at all (i.e. if an A
>record is queried, does not exist, is then added, and queried again it
>would show the same behavior as when you ask for a different type and
>derive data from the nsec bitmap). Taking that further, what if
>something is removed between t=0 and t=5, should we also not do positive
>caching? :)

Caching is a pain, it complicates the work at the authority server. 
Without caching we wouldn't need the complicated key rollovers and 
such.  However, caching is an integral part of the DNS protocol. Not 
to say we are stuck with it, it also boosts performance and lets the 
system achieve the stated goals of scaling, reliability, low latency.

I'm not advocating the removal of caching.  I'm advocating the status 
quo.  With caching being good and bad, the optimum position is a 
balance.  If we push it in one direction too far, pressure is put on 
other parts of the architecture.

If changing caching improved the lot of a authority servers, I'd be 
for it.  Change is good too, but it's not free of concerns.

>IMO whether or not aggressive caching should be done or allowed, giving
>different answers where one would expect the same (i.e. different NSECs
>depending on the qtype, in this case) makes me slightly nauseous :p But
>that is probably not much of a protocol qualification.

It's going to happen.  Even if we throw out the "tailored responses" 
issue, there's the element of time.  Although the DNS protocol does 
not integrate time into the data model, there's the real world that 
does.  Zones get updated and reloaded, so a cache will have to deal 
with inconsistent NSEC/3 bitmaps.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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!"