Re: [DNSOP] AS112 for TLDs

Mark Andrews <Mark_Andrews@isc.org> Mon, 07 April 2008 23:40 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 257E33A6A3F; Mon, 7 Apr 2008 16:40:58 -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 B17A23A6A3F for <dnsop@core3.amsl.com>; Mon, 7 Apr 2008 16:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level:
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599]
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 DAqpnnVlT8WL for <dnsop@core3.amsl.com>; Mon, 7 Apr 2008 16:40:55 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by core3.amsl.com (Postfix) with ESMTP id 556EC3A6CD4 for <dnsop@ietf.org>; Mon, 7 Apr 2008 16:40:43 -0700 (PDT)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m37NeoC0000415; Tue, 8 Apr 2008 09:40:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200804072340.m37NeoC0000415@drugs.dv.isc.org>
To: Andrew Sullivan <ajs@commandprompt.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Mon, 07 Apr 2008 15:36:45 -0400." <20080407193644.GD2303@commandprompt.com>
Date: Tue, 08 Apr 2008 09:40:50 +1000
Cc: dnsop@ietf.org
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>
MIME-Version: 1.0
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.

	Which in all cases results in processing the junk queries locally.

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

	You bring .local into existance for sites that are not using
	.local.

	The existing uses of AS112 don't bring zones into existance.
	They just *replicate* existing zones for local processing.

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

	No, I am not telling them that.  If I said "run your own root"
	I would be telling them that.

> After all, you just told them to respond authoritatively at that level.

	With the contents that they have copied from an authoritative
	source.  "local **** COPY ***** of the root zone"

> And since they have the authority
> server at that level, who's to tell them that they shouldn't add the
> extra entries?

	They can add entries today without having their own copy of the
	root zone.  Having a local copy of the root does not change that.

	zone tld {
		type stub;
		masters { ....; };
		file "tld.stub";
	};

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

	Creating a ".local" changes the response.  It also restricts
	future changes.
 
> 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).  

	That happens today.  There are ISP's which feel the need
	to use a alternate root.  Do you think they actually edit
	the local root zone or do they transfer it?

	Mark

> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop