Re: [DNSOP] AS112 for TLDs

[[e-mail]]

> > 	Mark made the claim that a local copy of the root would stop the
> > 	traffic, which is false. a local copy of the root simply diffuses
> > 	the traffic.
> > 
> > 	the down sides to local copies of the root as seen from the 
> > 	peanut gallery:
> > 
> > 	) coherence of the avowed single namespace.  There have been
> > 	  a few threads over the past decade on "bit rot" in the root-hints
> > 	  data.  Local copies of the root zone will have the same bit-rot
> > 	  characteristics
> > 	) the IANA sanctioning alternate roots/namespaces ... "let a 
> > 	  thousand roots bloom..." 
> > 	) just how is the poor application/end user supposed to know 
> > 	  or discriminate some local, walled garden root varient from
> > 	  the one true ICANN root varient?
> 
> 	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.
> 
> 	zone "." {
> 		type slave;
> 		masters { <addresses of root servers>; };
> 	};

		er... a rather narrow, constrained view of the
	term "copy".   I have copies of some datasets that go back
	20 years or more.  same data set, at different points in time.
	apparently you mean a copy of the database, plus/minus some
	temporal value and not augmented/diminished in any material
	way.  

	your example of how to obtain a copy, that meets most of the 
	criteria - seems to have a couple of assuptions... 
	
		) yFrom [e-mail]  Fri Apr  4 20:46:23 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 417243A685E;
	Fri,  4 Apr 2008 20:46:23 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 72A1F3A67A4
	for <[e-mail]>; Fri,  4 Apr 2008 20:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[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 xUHm9PNCwgII for <[e-mail]>;
	Fri,  4 Apr 2008 20:46:21 -0700 (PDT)
Received: from vacation.karoshi.com (unknown
	[IPv6:2002:c620:68b:0:230:48ff:fe11:220a])
	by core3.amsl.com (Postfix) with ESMTP id 6D9FD3A685E
	for <[e-mail]>; Fri,  4 Apr 2008 20:46:20 -0700 (PDT)
Received: from karoshi.com (localhost.localdomain [127.0.0.1])
	by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id m353iwqM024664;
	Sat, 5 Apr 2008 03:44:58 GMT
Received: (from bmanning@localhost)
	by karoshi.com (8.12.8/8.12.8/Submit) id m353ijp7024661;
	Sat, 5 Apr 2008 03:44:45 GMT
Date: Sat, 5 Apr 2008 03:44:45 +0000
From: [e-mail]
To: Mark Andrews <[e-mail]>
Message-ID: <[e-mail].>
References: <[e-mail].>
	<[e-mail]>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Cc: Andrew Sullivan <[e-mail]>, [e-mail],
	[e-mail], David Conrad <[e-mail]>
Subject: Re: [DNSOP] AS112 for TLDs
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

> > 	Mark made the claim that a local copy of the root would stop the
> > 	traffic, which is false. a local copy of the root simply diffuses
> > 	the traffic.
> > 
> > 	the down sides to local copies of the root as seen from the 
> > 	peanut gallery:
> > 
> > 	) coherence of the avowed single namespace.  There have been
> > 	  a few threads over the past decade on "bit rot" in the root-hints
> > 	  data.  Local copies of the root zone will have the same bit-rot
> > 	  characteristics
> > 	) the IANA sanctioning alternate roots/namespaces ... "let a 
> > 	  thousand roots bloom..." 
> > 	) just how is the poor application/end user supposed to know 
> > 	  or discriminate some local, walled garden root varient from
> > 	  the one true ICANN root varient?
> 
> 	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.
> 
> 	zone "." {
> 		type slave;
> 		masters { <addresses of root servers>; };
> 	};

		er... a rather narrow, constrained view of the
	term "copy".   I have copies of some datasets that go back
	20 years or more.  same data set, at different points in time.
	apparently you mean a copy of the database, plus/minus some
	temporal value and not augmented/diminished in any material
	way.  

	your example of how to obtain a copy, that meets most of the 
	criteria - seems to have a couple of assuptions... 
	
		)ou state < addresses of root servers> ... which
		  ones?  
		) can you ensure that the "root-servers" listed actually
		  wills erve accurate data via xfr?

	wrt "copy" vs "their own root"...

you and i started this discussion w/ the following:

On Fri, Apr 04, 2008 at 09:05:25AM +1100, Mark Andrews wrote:
>                                                                               
>       There really is only one solution to preventing "bogus"                 
>       traffic reaching the root servers and that is to run a local            
>       copy of the root zone.                                                  

        er, it (the bogus ttraffic) still reaches the root.
        just your copy of the root, not mine.

--bill

	your statement that people should be encouraged to 
	run a local copy of the root zone begs the question,
	run it where?  to which my assumption is ... they 
	run in on their own server, which, being authoritative
	for the root now, becomes their own root server.
	Did I err?

	and where is the "thou shalt NOT" modify/augment/diminish
	the contents of the database in the "local" copy ...
	
> 
> 	Mark
> 
> > 	but you, no doubt, see a much clearer picture.  please convince
> > 	me that my doubts are groundless... that bit-rot won't happen,
> 
> 	It is possible to check the masters similarly to the way
> 	we check the roots servers today.

	coordinating btwn a dozen orgs is one thing, coordinating
	btwn an unbounded number is something else.  as an analogy,
	how many AS112 instances are there and how can one check
	for coherent data ebing served by them?

> > 	that the avowed single namespace will remain intact,
> 	It will if you keep the copy up to date.

	"copy up to date"... so you acknowledge copies can and will
	age/diverge over time.   and you assume that augmentation
	"frosting" will not be applied to the local copy each time
	a fresh copy is aquired... presumably from some well known
	set of servers


> >	 and that
> > 	there will be trival ways for end users to discover the root of
> > 	the namespace they are using...
> 
> 	dig NS .

	please...  get real here.

> 
> >       if the recommendation to run your own copy of the root is approved.
> 	Note the zone will expire if you don't keep the masters up
> 	to date unlike failures to keep the root hints up to date.

	rndc reload .... to use a bind specific example of reloading
	
> 
> 	Mark
> 
> > --bill
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


 you state < addresses of root servers> ... which
		  ones?  
		) can you ensure that the "root-servers" listed actually
		  wills erve accurate data via xfr?

	wrt "copy" vs "their own root"...

you and i started this discussion w/ the following:

On Fri, Apr 04, 2008 at 09:05:25AM +1100, Mark Andrews wrote:
>                                                                               
>       There really is only one solution to preventing "bogus"                 
>       traffic reaching the root servers and that is to run a local            
>       copy of the root zone.                                                  

        er, it (the bogus ttraffic) still reaches the root.
        just your copy of the root, not mine.

--bill

	your statement that people should be encouraged to 
	run a local copy of the root zone begs the question,
	run it where?  to which my assumption is ... they 
	run in on their own server, which, being authoritative
	for the root now, becomes their own root server.
	Did I err?

	and where is the "thou shalt NOT" modify/augment/diminish
	the contents of the database in the "local" copy ...
	
> 
> 	Mark
> 
> > 	but you, no doubt, see a much clearer picture.  please convince
> > 	me that my doubts are groundless... that bit-rot won't happen,
> 
> 	It is possible to check the masters similarly to the way
> 	we check the roots servers today.

	coordinating btwn a dozen orgs is one thing, coordinating
	btwn an unbounded number is something else.  as an analogy,
	how many AS112 instances are there and how can one check
	for coherent data ebing served by them?

> > 	that the avowed single namespace will remain intact,
> 	It will if you keep the copy up to date.

	"copy up to date"... so you acknowledge copies can and will
	age/diverge over time.   and you assume that augmentation
	"frosting" will not be applied to the local copy each time
	a fresh copy is aquired... presumably from some well known
	set of servers


> >	 and that
> > 	there will be trival ways for end users to discover the root of
> > 	the namespace they are using...
> 
> 	dig NS .

	please...  get real here.

> 
> >       if the recommendation to run your own copy of the root is approved.
> 	Note the zone will expire if you don't keep the masters up
> 	to date unlike failures to keep the root hints up to date.

	rndc reload .... to use a bind specific example of reloading
	
> 
> 	Mark
> 
> > --bill
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop