Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00
Alfred Hönes <ah@TR-Sys.de> Fri, 29 January 2010 02:22 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 A83CA3A692C; Thu, 28 Jan 2010 18:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.513
X-Spam-Level:
X-Spam-Status: No, score=-101.513 tagged_above=-999 required=5 tests=[AWL=1.586, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, 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 cUBvmLuyIS+7; Thu, 28 Jan 2010 18:22:30 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 80E533A68D0; Thu, 28 Jan 2010 18:22:30 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NagPp-000ENt-5r for namedroppers-data0@psg.com; Fri, 29 Jan 2010 02:16:57 +0000
Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <A.Hoenes@TR-Sys.de>) id 1NagPl-000ELY-J5 for namedroppers@ops.ietf.org; Fri, 29 Jan 2010 02:16:54 +0000
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA284911398; Fri, 29 Jan 2010 03:16:38 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id DAA11317; Fri, 29 Jan 2010 03:16:37 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201001290216.DAA11317@TR-Sys.de>
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00
To: namedroppers@ops.ietf.org
Date: Fri, 29 Jan 2010 03:16:37 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
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 29 Jan 2010 00:16:21 +0000, Alex Bligh wrote: > On 28 Jan 2010 17:06:43 -0500 Olafur Gudmundsson <ogud@ogud.com> wrote: > > "Is it one of DNS roles to provide information on where the query > originated from?" > > Define "where". That's the _primary_ question to be elaborated upon in a proper problem statement that indeed SHOULD precede a proposed solution. > > -- > Alex Bligh BTW #1: Has anybody of the draft authors considered interaction with IP Mobility? Please study MIP4, MIP6, PMIP6, Network Mobility, and all the flavors and optimization techniques already specified and/or currently being revised and advanced on the Standards Track! BTW #2: It's one of the annoyances I repeatedly suffer from: Wanting purposely an answer specifically from www.google.com or say, www.google.fr, and then being redirected to www.google.de . IMO, increasing lack of transparency in the middle is the real problem we have. Ever increasing "intelligence" in the middle (and the core) limits the future evolution of IP networking, and causes an ever increasing mess of hacks necessary to overcome the limitations enforced by these so-called "helpers". All this increases fragility. BTW #3 For content distribution, I observe that knowledge of straightforward techniques seems to have eroded substantially. HTML has BASE refs, which obviously mostly aren't used any more as intended, and HTTP has redirects. It is this application layer where user preferences and properties should be used (under strict policy control by the end user) to influence the content being served. Let the user decide, on a per-service or per-resource base, when and where he would like to get assistance by "helpers", and co-locate these with the service, not the core or the middle! BTW #4: Did you consider the consequences for error diagnostic, help desk functions, etc., of adding even more 'cheating' to the DNS? When a user does not get what he wants and the help desk located in, say, India, wants to reproduce the problem the user in, say, Ireland, has -- how many time and effort will it cost to figure out what's going wrong when both do not obtain the same responses for DNS queries sent to the public Internet? Does that outweigh the "commodity" of a few "global players" ? The primary objective of the DNS is consistency. RFC 1034, Section 2.2, "DNS Design Goals" starts with: - The primary goal is a consistent name space which will be used for referring to resources. ... and later containss: - We want name server transactions to be independent of the communications system that carries them. [...] Independence of "the communications system" implies independence of addresses used in the network layer carrying the transactions. >From this it should be clear that the answer to Olafur's initial question is: "no". Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+
- 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