IETF Logo Mail Archive

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

Matthew Dempsky <matthew@dempsky.org> Tue, 02 February 2010 16:58 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 1AEAB3A6964; Tue, 2 Feb 2010 08:58:59 -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 xGVYij4Gw32l; Tue, 2 Feb 2010 08:58:58 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 57DA53A6958; Tue, 2 Feb 2010 08:58:58 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NcM3G-000Fic-Ec for namedroppers-data0@psg.com; Tue, 02 Feb 2010 16:56:34 +0000
Received: from [209.85.216.204] (helo=mail-px0-f204.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <matthew@dempsky.org>) id 1NcM3B-000Fgz-0q for namedroppers@ops.ietf.org; Tue, 02 Feb 2010 16:56:29 +0000
Received: by pxi42 with SMTP id 42so469597pxi.5 for <namedroppers@ops.ietf.org>; Tue, 02 Feb 2010 08:56:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.115.112.8 with SMTP id p8mr4177506wam.136.1265129788471; Tue, 02 Feb 2010 08:56:28 -0800 (PST)
In-Reply-To: <5925D875-FCC0-4B7C-92A1-53D21E7D5B77@rfc1035.com>
References: <7c31c8cc1001271556w4918093er6e94e07cb92c4dc4@mail.gmail.com> <4B66E441.6090104@nic.cz> <4966825a1002010729m32b5ccfel94f7cb09d8b5e458@mail.gmail.com> <20100202113421.GA31244@nic.fr> <4966825a1002020355s41a182edvbc2fc8045af4a36e@mail.gmail.com> <5925D875-FCC0-4B7C-92A1-53D21E7D5B77@rfc1035.com>
Date: Tue, 02 Feb 2010 08:56:28 -0800
Message-ID: <d791b8791002020856g28fec4behbbc1d3bd96d093d3@mail.gmail.com>
Subject: Re: [dnsext] opt-in and draft-vandergaast-edns-client-ip-00.txt
From: Matthew Dempsky <matthew@dempsky.org>
To: Jim Reid <jim@rfc1035.com>
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
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 4:55 AM, Jim Reid <jim@rfc1035.com> wrote:
> For instance, what should a resolving server do if it doesn't support this
> EDNS option and gets such a query from a stub resolver?
> [...]
> What does a resolving
> server do when it does support the option but has disabled it for local
> policy reasons?
> [..]
> Likewise, what does an authoritative server do if (a) it doesn't
> support this EDNS0 option (FORMERR? NOTIMP? REFUSED? or just ignore it?);
> (b) chooses for some reason not to supply an "optimised" response.

It would seem a little absurd for an I-D to specify how software that
doesn't follow that I-D should behave.  Obviously, it behaves however
software today behaves already.

> Can the
> resolving server mangle the optimised response from the authoritative server
> (say for local policy reasons) before giving a reply to the stub resolver?
> [...]
> When the resolving server does support this option, is it permitted (or not)
> to modify the data before sending a query to an authoritative server?

Of course it can.  There's no requirement that resolving servers can't
arbitrarily change queries/responses as long as it fulfills the
client's requirements.

v2.23.0 | Report a Bug | By Email