RFC 3258 (rfc3258) - Page 3 of 11

Distributing Authoritative Name Servers via Shared Unicast Addresses

RFC 3258        Distributing Authoritative Name Servers       April 2002


      e) coordination of the switchover times for the servers in the
         mesh
      f) institution of a failure process to ensure that servers that
         did not receive correct data or could not switchover to the new
         data ceased to respond to incoming queries until the problem
         could be resolved.

   Depending on the size of the mesh, the distribution host may also be
   a participant; for authoritative servers, it may also be the host on
   which zones are generated.

   This document presumes that the usual DNS failover methods are the
   only ones used to ensure reachability of the data for clients.  It
   does not advise that the routes be withdrawn in the case of failure;
   it advises instead that the DNS process shutdown so that servers on
   other addresses are queried.  This recommendation reflects a choice
   between performance and operational complexity.  While it would be
   possible to have some process withdraw the route for a specific
   server instance when it is not available, there is considerable
   operational complexity involved in ensuring that this occurs
   reliably.  Given the existing DNS failover methods, the marginal
   improvement in performance will not be sufficient to justify the
   additional complexity for most uses.

2.4 Server Placement

   Though the geographic diversity of server placement helps reduce the
   effects of service disruptions due to local problems, it is diversity
   of placement in the network topology which is the driving force
   behind these distribution practices.  Server placement should
   emphasize that diversity.  Ideally, servers should be placed
   topologically near the points at which the operator exchanges routes
   and traffic with other networks.

2.5 Routing

   The organization administering the mesh of servers sharing a unicast
   address must have an autonomous system number and speak BGP to its
   peers.  To those peers, the organization announces a route to the
   network containing the shared-unicast address of the name server.
   The organization's border routers must then deliver the traffic
   destined for the name server to the nearest instantiation.  Routing
   to the administrative interfaces for the servers can use the normal
   routing methods for the administering organization.

   One potential problem with using shared unicast addresses is that
   routers forwarding traffic to them may have more than one available
   route, and those routes may, in fact, reach different instances of



Hardie                       Informational