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


To: Ralph Droms <rdroms@cisco.com>
cc: dnsop@cafax.se
From: Pekka Savola <pekkas@netcore.fi>
Date: Thu, 7 Aug 2003 15:54:18 +0300 (EEST)
In-Reply-To: <4.3.2.7.2.20030807060857.04196320@funnel.cisco.com>
Sender: owner-dnsop@cafax.se
Subject: Re: the well-known address approach

On Thu, 7 Aug 2003, Ralph Droms wrote:
> I believe there is also a scaling issue.  If the well-known address 
> mechanism is truly limited to unicast (and not anycast) addressing, an 
> enterprise can only deploy as many recursive name servers as there are 
> reserved, well-known addresses.

It depends on what you mean by "anycast" here.

If well-known addresses are shared-unicast addresses (by the terminology 
of draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt), it might go easier.

You could just deploy the same (service) address in a lot of different
nodes, and just propagate host routes to those service addresses in the
internal routing; so, there could be more servers, but based on one node's
temporal view of the topology, it could only see N (e.g. three) at the
time and the place.
 
> Another potential issue is that deployment of hosts using the well-known 
> addresses will force network operators to support DNS service at those 
> well-known addresses, even if some other service architecture would be 
> better suited to that network's requirements.

Agreed, this may be an issue.  However, just as well you could redirect 
all of those to a box (even a router) which could proxy those requests to 
some otherwise configured DNS servers.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

Home | Date list | Subject list