Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt

[hardie@equinix.com]

Hi Gunnar,

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

I find your comment about controlling complexity interesting,
particularly in that it indicates a split between "DNS people" and
some other group (presumably "network people" or "routing people").  I
think many folks have seen this problem in terms of network
topology-related performance issues and so have focused the solutions
in those arenas.  Latency from the current root servers to some places
in the network is certainly a problem; redundant paths to some set of
root servers can also also a problem.


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

In the draft I put forward (and will soon revise), the idea is that
some organizations running root servers would make multiple boxes
available in multiple locations.  One of the reasons I prefer to have
a single organization responsible for the AS announcing the route to a
specific root server is that one group remains on the hook for
noticing/responding to/fixing problems like this.  

In that context, the problem you describe is not a lot different from
a bad route being injected now.  The organization serving the route
has to notice it, respond, and fix the problem.  Note that the
injected route being fixed affects how traffic gets to the
organization, where the "shared unicast" portion of the delivery takes
place internal to the organization.

In a context where multiple organizations manage a special AS, fixing
problems like that might have other characteristics.  Masataka may
want to respond to that idea.

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

One of the reasons I focused on synchronization of the various
instances of a specific root server is this problem.  If you got bad
data from a root server all the copies of it would have bad data; if
you got good data, all of the copies would have good data.  You also
have one organization to contact to correct the problem.


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

The problem here is that they are not really roots.  They derive their
data from what you call "Real Root Servers" and they act as a new
level in the hierarchy which is not reflected in the notation.  If I
understand your proposal correctly, rs1.their.provider would have to
respond to an SOA request by claiming to be authoritative for . to
avoid having internal servers just query up the chain to the Real Root
Servers. That seems to imply that they would have to re-write the data
they get from the Real Root Servers to claim that authority.  That
pretty much makes them an active man in the middle attack and open to
all sorts of problems, including a pretty easy form of splintering.

If I misunderstood your proposal, please help me see how you would
avoid this.
			regards,
				Ted Hardie

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