Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt

Matthew Dempsky <matthew@dempsky.org> Tue, 02 February 2010 19:46 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D126C3A693A; Tue, 2 Feb 2010 11:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 G8Vr+AXgZzZa; Tue, 2 Feb 2010 11:46:19 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 224193A6810; Tue, 2 Feb 2010 11:46:19 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcOff-000N9j-BV for namedroppers-data0@psg.com; Tue, 02 Feb 2010 19:44:23 +0000
Received: from [209.85.222.189] (helo=mail-pz0-f189.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <matthew@dempsky.org>) id 1NcOfc-000N7V-Us for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 19:44:20 +0000
Received: by pzk27 with SMTP id 27so434760pzk.33 for <namedroppers@ops.ietf.org>; Tue, 02 Feb 2010 11:44:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.105.15 with SMTP id d15mr4326693wac.18.1265139860512; Tue, 02 Feb 2010 11:44:20 -0800 (PST)
In-Reply-To: <4B687B3C.2080509@isc.org>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <6e04e83a1002011109u1cd55c99k8b584648184cdc73@mail.gmail.com> <162E0DB1-EC86-4206-AB36-6FEFA786B24C@ICSI.Berkeley.EDU> <6e04e83a1002011402u395f599g74180d28fdbe5707@mail.gmail.com> <939BB577-FDBE-4573-9129-8CA29B0FB493@sackheads.org> <7B06A582-38E3-4387-BA16-932825A4A62B@rfc1035.com> <F2E927AA-B07C-45D0-9D26-AFE8115F2CC2@icsi.berkeley.edu> <B7A5F1C5-E972-4915-A90F-E561B041A133@rfc1035.com> <alpine.LSU.2.00.1002021825310.28066@hermes-2.csi.cam.ac.uk> <4B687B3C.2080509@isc.org>
Date: Tue, 02 Feb 2010 11:44:20 -0800
Message-ID: <d791b8791002021144x61ceb967g384399f65be71c28@mail.gmail.com>
Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt
From: Matthew Dempsky <matthew@dempsky.org>
To: Michael Graff <mgraff@isc.org>
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Tue, Feb 2, 2010 at 11:21 AM, Michael Graff <mgraff@isc.org> wrote:
> Since the response coming back now has a network range the answer is
> good for, this more or less adds another dimension to the cache.

Caches already have to deal with a potentially unbounded set of data.
Adding another dimension to this doesn't really change the fundamental
problem.

Resolvers have the option to control when the flag is used or not.
E.g., if the cache is experiencing high levels of churn, they can just
turn it off and fallback to current behavior.  They can only turn it
on for interesting domains that are likely to benefit from it.

I see whether or not to use the option as an administrative choice.

> You
> may now have many answers for the same data.  Do you have to run DNSSEC
> validation on each of these answer ranges specially?  The signatures
> have to match up with the records, after all.

Of course you'd have to.  But as an optimization, you can check if you
already have the same record set + DNSSEC signatures cached for a
different CIDR block, and then short circuit re-evaluation.