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

[Gunnar Lindberg <lindberg@cdg.chalmers.se>]

Ted,

Let me make a half-technical/non-technical remark first and then do
some more comments in-line:

I agree that one single Root Server organization would be a good
thing. However, I see no reasonable way to get that in place, to get
funding for it (from users or from ISPs), etc, etc, and to make it
scale to "enough" number of Root Servers.

As I've written in my draft I think the need is one or more Root
Servers per ISP - maybe not all for pure technical reasons, but no
ISP in their right mind would ever admit (or allow) that their users
totally depend on Root Servers located at, and controlled by, their
main competitor. I know there are several ISP people on this list -
please correct me if I'm wrong...

Therefore, we're into several organizations operating instances of
Root Server(s) (instances with - hopefully - identical content).

>From owner-dnsop@cafax.se  Fri Aug 20 00:50:26 1999
>Message-Id: <199908192248.PAA01033@kiwi.equinix.com>
>Subject: Re: I-D ACTION:draft-lindberg-dnsop-isp-root-server-00.txt
>To: lindberg@cdg.chalmers.se (Gunnar Lindberg)
>Date: Thu, 19 Aug 1999 15:48:31 -0700 (PDT)
>Cc: dnsop@cafax.se
>From: 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.

If I was to provide a vital service for a large community I would be
careful to base it on things closely under my control and for every-
thing else have that be as simple as possible. That way it's less
likely that things fail, or change under my feet. Then, at times it
pays off to violate this "layered approach"; fine, but then one should
document what behavior is expected from other layers and not try to
hide that under the carpet.

My split between "DNS people" and "routing people" comes from this
observation and a concern that the <idr> WG people might not always
know what undocumented behavior other people expect and depend on
(e.g. at unintended events like "inconsistent AS path"). I put my
draft together in an effort to minimize that dependency and a hope
that existing dependencies/expectations be documented.

I know "anycast" has been discussed for use with Multicast RPs and
I am attracted by the idea, but I also think most of us agree it's
some difference between Multicast RPs and the DNS Root Servers...

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

As I said above, I agree that one single org would be good. But, for
the resons I presented I think we have the multi-org situation and
that we must plan for it.

As for synchroniztion it is of course the intent that all instances
are identical at all times. However, in a real world with real people
sh*t happens and my concern is how to act when sh*t has happened;
e.g. someone finds he has bad cache data about equinix.com and now
you're trying to verify what went wrong and get the error corrected.
In a situation where there is an unknown number of [198.41.0.4] spread
out over the entire Internet, I expect that to be a hard task.

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

I think there are 3 different issues:

    1)	SOA content.
	As <Harald@Alvestrand.no> already responded, the fields that
	you might want to change are not interpreted by computers,
	so 'MNAME' & 'RNAME' (RFC1035, pp 19) can either be left as
	is or be changed. I don't have a strong opinion.

    2)	List of NS(.).
	This of course has to be modified to point at the provider's
	IRSs; to yield rs1.their.provider, rs2.their.provider, etc.

    3)	DNSSEC signing.
	As Harald also said in his response, this is hard and nasty.
	I don't have an answer right now.

Hm, I didn't make your "1.2 Zone file delivery" point; will add that.

	    Gunnar Lindberg

>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" st