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

Michael Graff <mgraff@isc.org> Tue, 02 February 2010 20:01 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 7BA1828C0D7; Tue, 2 Feb 2010 12:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 nETa5H4boQiY; Tue, 2 Feb 2010 12:01:52 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5C79F28B23E; Tue, 2 Feb 2010 12:01:50 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcOsv-000PsW-5t for namedroppers-data0@psg.com; Tue, 02 Feb 2010 19:58:05 +0000
Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <mgraff@isc.org>) id 1NcOss-000Ps0-UY for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 19:58:02 +0000
Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 7401617D1DF; Tue, 2 Feb 2010 19:58:02 +0000 (UTC)
Received: from bigmac.home.flame.org (unknown [IPv6:2001:4f8:fff9:13:21d:4fff:fe47:6790]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 904C617D1DB; Tue, 2 Feb 2010 19:58:01 +0000 (UTC)
Message-ID: <4B6883C8.8020702@isc.org>
Date: Tue, 02 Feb 2010 13:58:00 -0600
From: Michael Graff <mgraff@isc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Matthew Dempsky <matthew@dempsky.org>
CC: namedroppers@ops.ietf.org
Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00.txt
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> <d791b8791002021144x61ceb967g384399f65be71c28@mail.gmail.com>
In-Reply-To: <d791b8791002021144x61ceb967g384399f65be71c28@mail.gmail.com>
X-Enigmail-Version: 1.0
OpenPGP: id=BE9E0FA6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
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/>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010-02-02 1:44 PM, Matthew Dempsky wrote:
> Caches already have to deal with a potentially unbounded set of data.
> Adding another dimension to this doesn't really change the fundamental
> problem.

I think it quite easily could change it.  The amount of data a cache
must maintain is not my issue really, although it is a concern.

If you query for an MX host, and you get an answer that is valid for a
given address range, will the address records for that MX target also
need to be checked for that range?  What if it's not in it?

What about targets of CNAMEs?

I know caches deal with this type of thing all the time, but it gets
really messy when you do range-checking for the target of the name and
then need to do additional section processing in order to really answer
the query.  Previously, it was "do I have this additional data?" but now
it's "Do I have this additional data, and does it also fit within the
netmask of the actual query?

Perhaps it's just the same thing with the same filters applied.

- --Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktog8gACgkQ+NNi0s9NRJ1URwCdFpk0DNAgoWPgtabL2IOZs62a
x0EAn252IXgEPmh3OrLZezGorK5hj1xY
=p2wz
-----END PGP SIGNATURE-----