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                     |
+------------------------+--------------------------------------------+