Re: [DNSOP] AS112 for TLDs

Andrew Sullivan <ajs@commandprompt.com> Mon, 07 April 2008 19:36 UTC

Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@lists.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FCE3A6CCF; Mon, 7 Apr 2008 12:36:43 -0700 (PDT)
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 04CA63A693D for <dnsop@core3.amsl.com>; Mon, 7 Apr 2008 12:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.735
X-Spam-Level:
X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311]
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 YUiZKe7o89FD for <dnsop@core3.amsl.com>; Mon, 7 Apr 2008 12:36:36 -0700 (PDT)
Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by core3.amsl.com (Postfix) with ESMTP id B9BA928C2A3 for <dnsop@ietf.org>; Mon, 7 Apr 2008 12:36:35 -0700 (PDT)
Received: from commandprompt.com (227-54-222-209.mycybernet.net [209.222.54.227]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m37JbMF7019677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dnsop@ietf.org>; Mon, 7 Apr 2008 12:37:25 -0700
Date: Mon, 07 Apr 2008 15:36:45 -0400
From: Andrew Sullivan <ajs@commandprompt.com>
To: dnsop@ietf.org
Message-ID: <20080407193644.GD2303@commandprompt.com>
References: <20080404155638.GA15372@vacation.karoshi.com.> <200804042307.m34N7svX071381@drugs.dv.isc.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <200804042307.m34N7svX071381@drugs.dv.isc.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Mon, 07 Apr 2008 12:37:26 -0700 (PDT)
Subject: Re: [DNSOP] AS112 for TLDs
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

Dear colleagues,

Not to pick on Mark, but I have the sinking feeling that this
discussion is a good example of why some operators think the IETF
doesn't understand operational problems.

On Sat, Apr 05, 2008 at 10:07:54AM +1100, Mark Andrews wrote:

> 	I said COPY.  I did not say "THEIR OWN ROOT".  A copy needs to
> 	be kept up to date or it ceases to be a copy.  It becomes a
> 	snapshot.

The point of this exercise, as far as I recall, was to solve the
problem that "junk" queries go to the roots -- things like .local and
.txt.  Now, if I'm a mom & pop ISP being crunched by large carriers
(who are using every trick in the book to drive me out of business)
and expensive customer calls, I'm going to do whatever will make my
customers happy, right now, and get them off the phone.

So I'm going to say, "What's the harm in adding the entries for .local
into this instance that I'm already running for other TLDs anyway?"
It will make one failure mode go away for the customer, and it will
reduce my load on my systems.

By telling everyone to run their own authoritative copy for the top
level, you are effectively telling them that they can add _anything_
at the top level.  After all, you just told them to respond
authoritatively at that level.  And since they have the authority
server at that level, who'sFrom dnsop-bounces@ietf.org  Mon Apr  7 12:36:43 2008
Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 41FCE3A6CCF;
	Mon,  7 Apr 2008 12:36:43 -0700 (PDT)
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 04CA63A693D
	for <dnsop@core3.amsl.com>; Mon,  7 Apr 2008 12:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.735
X-Spam-Level: 
X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.000, 
	BAYES_00=-2.599, HELO_MISMATCH_COM=0.553,
	HOST_MISMATCH_NET=0.311]
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 YUiZKe7o89FD for <dnsop@core3.amsl.com>;
	Mon,  7 Apr 2008 12:36:36 -0700 (PDT)
Received: from lists.commandprompt.com (host-159.commandprompt.net
	[207.173.203.159])
	by core3.amsl.com (Postfix) with ESMTP id B9BA928C2A3
	for <dnsop@ietf.org>; Mon,  7 Apr 2008 12:36:35 -0700 (PDT)
Received: from commandprompt.com (227-54-222-209.mycybernet.net
	[209.222.54.227]) (authenticated bits=0)
	by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m37JbMF7019677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <dnsop@ietf.org>; Mon, 7 Apr 2008 12:37:25 -0700
Date: Mon, 7 Apr 2008 15:36:45 -0400
From: Andrew Sullivan <ajs@commandprompt.com>
To: dnsop@ietf.org
Message-ID: <20080407193644.GD2303@commandprompt.com>
References: <20080404155638.GA15372@vacation.karoshi.com.>
	<200804042307.m34N7svX071381@drugs.dv.isc.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <200804042307.m34N7svX071381@drugs.dv.isc.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0
	(lists.commandprompt.com [207.173.203.159]);
	Mon, 07 Apr 2008 12:37:26 -0700 (PDT)
Subject: Re: [DNSOP] AS112 for TLDs
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

Dear colleagues,

Not to pick on Mark, but I have the sinking feeling that this
discussion is a good example of why some operators think the IETF
doesn't understand operational problems.

On Sat, Apr 05, 2008 at 10:07:54AM +1100, Mark Andrews wrote:

> 	I said COPY.  I did not say "THEIR OWN ROOT".  A copy needs to
> 	be kept up to date or it ceases to be a copy.  It becomes a
> 	snapshot.

The point of this exercise, as far as I recall, was to solve the
problem that "junk" queries go to the roots -- things like .local and
.txt.  Now, if I'm a mom & pop ISP being crunched by large carriers
(who are using every trick in the book to drive me out of business)
and expensive customer calls, I'm going to do whatever will make my
customers happy, right now, and get them off the phone.

So I'm going to say, "What's the harm in adding the entries for .local
into this instance that I'm already running for other TLDs anyway?"
It will make one failure mode go away for the customer, and it will
reduce my load on my systems.

By telling everyone to run their own authoritative copy for the top
level, you are effectively telling them that they can add _anything_
at the top level.  After all, you just told them to respond
authoritatively at that level.  And since they have the authority
server at that level, who's to tell them that they shouldn't add the
extra entries?  It solves their operational problem, makes things easy
for their customers, and (since the point of this effort is to stop
leaking queries) doesn't harm anyone else.  Right?

The harm, of course, will come when people change ISPs and things
don't work quite the same; or when they run into surprises by carrying
their laptops into another network with a disjunct set of these
non-IANA-root entries.  This scheme more or less guarantees the end of
the pretense of a unified namespace (which is related, I think,
to the arguments elsewhere in this thread that such has already
happened anyway).  

A

-- 
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


 to tell them that they shouldn't add the
extra entries?  It solves their operational problem, makes things easy
for their customers, and (since the point of this effort is to stop
leaking queries) doesn't harm anyone else.  Right?

The harm, of course, will come when people change ISPs and things
don't work quite the same; or when they run into surprises by carrying
their laptops into another network with a disjunct set of these
non-IANA-root entries.  This scheme more or less guarantees the end of
the pretense of a unified namespace (which is related, I think,
to the arguments elsewhere in this thread that such has already
happened anyway).  

A

-- 
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop