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


To: Mark.Andrews@isc.org
CC: dnsop@cafax.se
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Date: Fri, 14 Nov 2003 01:59:36 +0900
In-Reply-To: <200311131525.hADFPFNQ000618@drugs.dv.isc.org>
Sender: owner-dnsop@cafax.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Subject: Re: well-known addresses / was DNS discovery

Mark;

>>>	WKA adds yet one more set of addresses that need to be
>>>	filtered at the organisation's boundaries.
>>
>>No. Read the draft section 4.1.
 
> 	I believe organisations will continue to want to use split
> 	DNS.

If you are talking about not organizations but organizations
doing something special, say so from the beginning.

>       Running split DNS will become much more than just
> 	runing nameservers and telling the clients where they are.
> 	It also involves reconfiguring routers to filter routes.

Split DNS costs, a lot. That's all.

>>>	It is easy to accidently introduce single points of failure
>>>	into anycast solutions even though you have topologically
>>>	spread your nameservers.  It much harder to do this with
>>>	a non-anycast solution.
>>
>>Anycast, just like multicast, itself is no robust. Read the
>>draft section 4.1.
> 
> 
> 	I did read the draft.

Read, and then, properly quote the draft. But, you actually don't
even read the draft.

>       You draft is forcing the use of
> 	anycast to get load sharing.

No, not at all. To quote the draft, instead of you, it says:

   Within a static boundary, there may be a single server for each
   anycast address, or there may be multiple servers sharing an anycast
   address, which may be useful for load distribution.

that there is no forcing.

Even if there are, it has nothing to do with your point that:

>>>	It is easy to accidently introduce single points of failure
 
>>>	WKA doesn't remove the need to have another solution to
>>>	supply the search list.
>>
>>That is not a requirement.
> 
> 
> 	It's not a requirement if the ONLY thing you want clients
> 	to know about the DNS is the addresses of nameservers.  In
> 	the real world there are lots of organisations that want
> 	to push other configuration details out.  The proposals
> 	you are competing with can support this.
> 
> 	There have been cases where I have wanted to push out the
> 	other DNS configuration and times when I don't.  The lack
> 	of support for this is reason enough to reject this solution.

You are talking about organizations wanting a lot "stateful"
configuration, which is out of the scope of the discussion.
 
> 	You draft also states that the anycast addresses will have
> 	global scope.  Does this mean that we are going to have to
> 	introduce the concept of stub routers so that the correct
> 	prefixes are configured for nodes on a routerless network?

As anycast servers advertise routes to themself, that is, they
are routers, that the network with them is not routerless.

But, I'm not sure what you want to do with DNS on such network.

							Masataka Ohta

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list