Re: [DNSOP] Review of draft-livingood-dns-redirect-00

David Conrad <drc@virtualized.org> Thu, 16 July 2009 19:49 UTC

Return-Path: <drc@virtualized.org>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070E33A6A42 for <dnsop@core3.amsl.com>; Thu, 16 Jul 2009 12:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.58
X-Spam-Level:
X-Spam-Status: No, score=-5.58 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 no814p8y2037 for <dnsop@core3.amsl.com>; Thu, 16 Jul 2009 12:49:42 -0700 (PDT)
Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 2A08A3A68A5 for <dnsop@ietf.org>; Thu, 16 Jul 2009 12:49:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 9F0776C6827; Thu, 16 Jul 2009 12:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at virtualized.org
Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYkGzWZdCjyw; Thu, 16 Jul 2009 12:49:39 -0700 (PDT)
Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id 13EB66C6818; Thu, 16 Jul 2009 12:49:39 -0700 (PDT)
Message-Id: <9BD6F00D-876B-4BFD-AB7F-BE49E793B0A3@virtualized.org>
From: David Conrad <drc@virtualized.org>
To: Jeroen Massar <jeroen@unfix.org>
In-Reply-To: <4A5F74E5.3060708@spaghetti.zurich.ibm.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 16 Jul 2009 12:49:38 -0700
References: <C6849631.EF40%Jason_Livingood@cable.comcast.com> <4A5F2085.9000707@spaghetti.zurich.ibm.com> <F82B1DDF-709C-4F3A-8687-0B241B2FD7C6@virtualized.org> <4A5F74E5.3060708@spaghetti.zurich.ibm.com>
X-Mailer: Apple Mail (2.935.3)
Cc: IETF DNSOP WG <dnsop@ietf.org>
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2009 19:49:43 -0000

On Jul 16, 2009, at 11:43 AM, Jeroen Massar wrote:
>> Please.  Enough hyperbole.
> Unless you state that "The Internet" is only "The Web", there are  
> other
> users of "The Internet" though. Don't try and limit what other people
> can do with this public resource.

Could we ratchet down the rhetoric?

DNS redirection does not break the Internet.  DNS redirection can  
result in unanticipated responses.  Some applications can behave in  
sub-optimal ways in the face of these unanticipated responses.  This  
is a far cry from breaking "the Internet".

As far as I can tell, Comcast's network and their recursive servers  
are not a "public resource".  As folks on Comcast's network are not  
forced to be Comcast's customer nor (as far as I know) are they  
required to use Comcast's name servers, I don't see where you, this  
working group, or the IETF has a right to determine what Comcast does.

The point Andrew tried to make is that the lesson we (should have)  
learned with NAT is that folks are going to deploy technologies that  
some may consider ill-advised or impure or "evil" or whatever if they  
find it to be in their interests to do so, regardless of what this  
working group or the IETF may say.  In order to limit the  
proliferation of 'solutions', it is in the best interests of operators  
to standardize on an agreed upon approach and document the  
implications of that approach (both positive and negative) to ensure  
everyone understands what they're doing.  Blocking these efforts  
resulting in various broken ways of doing the same thing are far more  
detrimental to the Internet than the existence of the standardized  
solution.

>> DNSSEC doesn't touch anything after the validator.  It will have no
>> effect on the vast majority of Comcast (or other consumer oriented)
>> ISPs' customers.
>
> "The vast majority" aha, so discrimination of the people who do want  
> to
> actually have real truthful Internet is acceptable????

Might I suggest switching to decaffeinated?

My statement is merely the truth.  The vast majority of consumer  
oriented ISPs supply the DNS resolver settings to their customers.  As  
such, validation would occur prior to the insertion of redirected  
responses.  The exceptionally few applications that try to do  
validation on their own are so far in the noise as to be irrelevant.

> As a user of the Internet I *am* running a validating DNSSEC  
> recursor on
> my hosts. Thanks to ISC for the DLV :)
>
> I am fairly sure that a lot of other people will also want to do this.

A little perspective please.  I'm fairly sure that you and everyone  
else who runs a validating DNSSEC recursor on their host are an  
infinitesimal minority of Internet users.

More to the point, DNS redirection does not imply running your own  
recursor is disallowed.  Yes, it can be implemented in such a way as  
break running your own recursor, but if this occurs, the right answer  
is to vote with your feet.

Regards,
-drc