[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: crawdad@fnal.gov, dnsop@cafax.se, tal@research.bell-labs.com
From: Gunnar Lindberg <lindberg@cdg.chalmers.se>
Date: Thu, 19 Aug 1999 09:06:49 +0200 (MET DST)
In-Reply-To: <199908181646.LAA09041@gungnir.fnal.gov> <37BB0B78.54DFA9ED@research.bell-labs.com>
Sender: owner-dnsop@cafax.se
Subject: Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt

Hm. Did any of you expect Free Lunch? Of course not!

Increasing the number of Root Servers from "13" to "enough" will not
come free, like it or not. Complexity will increase and question is
"how much" and "where". The latter is important since it tells whether
complexity in controlled by DNS people or it shows up elsewhere, far
from DNS control.

Saying that clearly is not good/bad, it simply means being honest.

If you look at most of the other proposals they say "anycast" and hope
it's a done deal. I'm concerned:

    1)	It expects a routing behavior that is not well documented.

	What happens if someone (errounously) injects a Root Server's
	IP prefix originating from the wrong AS ("inconsistant AS
	path")? Today, i.e. cisco implementation, it still works,
	although there is a warning message on the console. What will
	happen tomorrow? Maybe that prefix gets dropped? To the best
	of my abilities I've not found that documented.

	If we're going to base the DNS, the very heart of the Internet,
	on "anycast", that default behavior at least needs to be
	documented in an RFC (carved in stone, rather). Btw, the BGP4
	draft has just expired.

    2)	How do you trace erronous information?

	Assume your DNS has cached bad root data. You know NS(.) by
	name and address, but none of those instances you reach when
	you go looking for it contains the error. Does this mean the
	the error is corrected? Or, is it still there, in some of the
	other "[a-m].root-servers.net" instances?

	How do you know which "[a-m].root-servers.net" there are?
	
My proposal is:

    1)	Don't. Use today's unicast routing as is. Simplicity. Good.

    2)	Let ISPs run RSs and let their customers be aware of reality.
	Tell customers that NS(.) =
	    rs1.their.provider [1.2.3.45]
	    rs2.their.provider [1.2.4.56]
	    rs3.their.provider [1.2.5.67]

	Less confusion when bad data shows up. Simplicity. Good.

To summarize: I'm concerned by the web of implicit dependencies that
the "anycast" stuff is likely to create. I think "the hair salon" is
still fairly safe :-) but other things/places are not.

		Gunnar Linbdberg

-----------------------------------------------------------------------
>From owner-dnsop@cafax.se  Wed Aug 18 18:51:25 1999
>Message-Id: <199908181646.LAA09041@gungnir.fnal.gov>
>To: dnsop@cafax.se
>From: "Matt Crawford" <crawdad@fnal.gov>

>> This does increase complexity, but
>> the increased complexity is kept entirely within the DNS itself.

>This is a *feature* ???

-----------------------------------------------------------------------
>From owner-dnsop@cafax.se  Wed Aug 18 21:39:54 1999
>Message-ID: <37BB0B78.54DFA9ED@research.bell-labs.com>
>Date: Wed, 18 Aug 1999 15:37:28 -0400
>From: Tom Limoncelli <tal@research.bell-labs.com>
>To: dnsop@cafax.se

>> This does increase complexity, but
>> the increased complexity is kept entirely within the DNS itself.

>This is an empty statement.  Where else could it add complexity?  At my
>hair salon?

>--tal

>P.S.  For those that just tuned in: complexity bad, simplicity good.


Home | Date list | Subject list