Re: [dnsext] Re: a definition of consistency
Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 29 January 2010 16:51 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 D0FE03A6822; Fri, 29 Jan 2010 08:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 4T+nQHCJE6y9; Fri, 29 Jan 2010 08:51:54 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 163D03A67EF; Fri, 29 Jan 2010 08:51:54 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Natwl-000DH6-Iy for namedroppers-data0@psg.com; Fri, 29 Jan 2010 16:43:51 +0000
Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <nweaver@ICSI.Berkeley.EDU>) id 1Natwj-000DFe-L6 for namedroppers@ops.ietf.org; Fri, 29 Jan 2010 16:43:49 +0000
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o0TGhgKZ012781; Fri, 29 Jan 2010 08:43:42 -0800 (PST)
References: <201001290216.DAA11317@TR-Sys.de> <6f5b6fe71001290132s258b9eb3i1cdbd3e6f4c75f7f@mail.gmail.com> <2F01D84C-6633-499F-B3D3-ACE924AD40DF@rfc1035.com> <6f5b6fe71001290223h77443b7cy21eb884a868daf46@mail.gmail.com> <BB97B845-9302-4D3E-8A4A-5D685CC97099@rfc1035.com> <20100129115845.GA4343@nic.fr> <OFDAA3A915.ACDE3F37-ON802576BA.0044DEEC-802576BA.00494044@nominet.org.uk>
In-Reply-To: <OFDAA3A915.ACDE3F37-ON802576BA.0044DEEC-802576BA.00494044@nominet.org.uk>
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <DFED682E-1859-4CC2-8B7F-AB5F05FA6B3D@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, namedroppers@ops.ietf.org
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [dnsext] Re: a definition of consistency
Date: Fri, 29 Jan 2010 08:43:41 -0800
To: Ray.Bellis@nominet.org.uk
X-Mailer: Apple Mail (2.1077)
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 Jan 29, 2010, at 5:20 AM, Ray.Bellis@nominet.org.uk wrote: > > > But you are off-topic here: the draft under discussion does not > > suggest to change the DNS protocol or to standardize auth. servers > > behavior or to mandate an algorithm to load-balancing, it is mostly > > about a way to indicate something about the client. There is no reason > > for the authors to prove that it affects Security & Stability (except > > if the use of unknown EDNS option codes prove to break many > > firewalls, which is still a possibility). > > It will certainly cause some home gateway proxies to reject the packets. > > In SAC035 we found at least one that FORMERR'ed any EDNS0 option, and another that dropped the packets on the floor. This I think is why its clear that only requests containing an EDNS0 option should be replied to with the EDNS0 option, so such gateways etc either shouldn't be a problem, or should be manageabre by the requestor. This should be universal for ANY EDNS0 extension.
- Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edn… Alfred Hönes
- Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edn… Colm MacCárthaigh
- Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edn… Alex Bligh
- [dnsext] a definition of consistency Jim Reid
- [dnsext] Market forces and protocol engineering Jim Reid
- [dnsext] mangling DNS responses based on proximity Jim Reid
- Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edn… Colm MacCárthaigh
- [dnsext] Re: a definition of consistency Colm MacCárthaigh
- [dnsext] Re: mangling DNS responses based on prox… Stephane Bortzmeyer
- [dnsext] Re: mangling DNS responses based on prox… Colm MacCárthaigh
- Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edn… Alex Bligh
- Re: [dnsext] Re: a definition of consistency Jim Reid
- [dnsext] Re: a definition of consistency Stephane Bortzmeyer
- [dnsext] Sending different DNS responses based on… Stephane Bortzmeyer
- [dnsext] Re: a definition of consistency Stephane Bortzmeyer
- Re: [dnsext] Re: a definition of consistency Colm MacCárthaigh
- Re: [dnsext] Sending different DNS responses base… Jim Reid
- Re: [dnsext] Re: a definition of consistency George Barwood
- [dnsext] Reflection of the resolver's IP address … Stephane Bortzmeyer
- Re: [dnsext] Re: a definition of consistency Ray.Bellis
- [dnsext] Re: Going through broken proxies (Was: a… Ray.Bellis
- [dnsext] Going through broken proxies (Was: a def… Stephane Bortzmeyer
- Re: [dnsext] Re: a definition of consistency Jim Reid
- Re: [dnsext] Re: a definition of consistency Colm MacCárthaigh
- Re: [dnsext] Re: a definition of consistency Nicholas Weaver
- Re: [dnsext] Re: a definition of consistency Ondřej Surý
- Re: [dnsext] Re: a definition of consistency Wilmer van der Gaast
- Re: [dnsext] Re: a definition of consistency Nicholas Weaver
- Re: [dnsext] Re: a definition of consistency Ondřej Surý
- Re: [dnsext] Re: a definition of consistency Nicholas Weaver
- RE: [dnsext] Re: a definition of consistency Everhart, Craig