As per Relevance of the word distributing, we have this rfc below:
Network Working Group T.
Request for Comments: 3258 Nominum, Inc
Category: Informational April 2002
Distributing Authoritative Name Servers via Shared Unicast
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This memo describes a set of practices intended to enable
authoritative name server operator to provide access to a
named server in multiple locations. The primary motivation for
development and deployment of these practices is to increase
distribution of Domain Name System (DNS) servers to
under-served areas of the network topology and to reduce the
for DNS query responses in those areas
1.
This memo describes a set of practices intended to enable
authoritative name server operator to provide access to a
named server in multiple locations. The primary motivation for
development and deployment of these practices is to increase
distribution of DNS servers to previously under-served areas of
network topology and to reduce the latency for DNS query responses
those areas. This document presumes a one-to-one mapping
named authoritative servers and administrative entities (operators).
This document contains no guidelines or recommendations for
name servers. The shared unicast system described here is
to IPv4; applicability to IPv6 is an area for further study.
should also be noted that the system described here is related
that described in [ANYCAST], but it does not require
address space, routing changes, or the other elements of a
anycast infrastructure which that document describes
Hardie Informational [Page 1]
RFC 3258 Distributing Authoritative Name Servers April 2002
2.
2.1 Server
Operators of authoritative name servers may wish to refer
[SECONDARY] and [ROOT] for general guidance on appropriate
for authoritative name servers. In addition to proper
as a standard authoritative name server, each of the
participating in a shared-unicast system should be configured
two network interfaces. These interfaces may be either two
interfaces or one physical interface mapped to two
interfaces. One of the network interfaces should use the IPv4
unicast address associated with the authoritative name server.
other interface, referred to as the administrative interface below
should use a distinct IPv4 address specific to that host. The
should respond to DNS queries only on the shared-unicast interface
In order to provide the most consistent set of responses from
mesh of anycast hosts, it is good practice to limit responses on
interface to zones for which the host is authoritative
2.2 Zone file
In order to minimize the risk of man-in-the-middle attacks,
files should be delivered to the administrative interface of
servers participating in the mesh. Secure file transfer methods
strong authentication should be used for all transfers. If the
in the mesh make their zones available for zone transfer,
administrative interfaces should be used for those transfers as well
in order to avoid the problems with potential routing changes for
traffic noted in section 2.5 below
2.3
Authoritative name servers may be loosely or tightly synchronized
depending on the practices set by the operating organization.
noted below in section 4.1.2, lack of synchronization among
using the same shared unicast address could create problems for
users of this service. In order to minimize that risk, switch-
from one data set to another data set should be coordinated as
as possible. The use of synchronized clocks on the
hosts and set times for switch-overs provides a basic level
coordination. A more complete coordination process would involve
a) receipt of zones at a distribution
b) confirmation of the integrity of zones
c) distribution of the zones to all of the servers in the
d) confirmation of the integrity of the zones at each
Hardie Informational [Page 2]
RFC 3258 Distributing Authoritative Name Servers April 2002
e) coordination of the switchover times for the servers in
f) institution of a failure process to ensure that servers
did not receive correct data or could not switchover to the
data ceased to respond to incoming queries until the
could be resolved
Depending on the size of the mesh, the distribution host may also
a participant; for authoritative servers, it may also be the host
which zones are generated
This document presumes that the usual DNS failover methods are
only ones used to ensure reachability of the data for clients.
does not advise that the routes be withdrawn in the case of failure
it advises instead that the DNS process shutdown so that servers
other addresses are queried. This recommendation reflects a
between performance and operational complexity. While it would
possible to have some process withdraw the route for a
server instance when it is not available, there is
operational complexity involved in ensuring that this
reliably. Given the existing DNS failover methods, the
improvement in performance will not be sufficient to justify
additional complexity for most uses
2.4 Server
Though the geographic diversity of server placement helps reduce
effects of service disruptions due to local problems, it is
of placement in the network topology which is the driving
behind these distribution practices. Server placement
emphasize that diversity. Ideally, servers should be
topologically near the points at which the operator exchanges
and traffic with other networks
2.5
The organization administering the mesh of servers sharing a
address must have an autonomous system number and speak BGP to
peers. To those peers, the organization announces a route to
network containing the shared-unicast address of the name server
The organization's border routers must then deliver the
destined for the name server to the nearest instantiation.
to the administrative interfaces for the servers can use the
routing methods for the administering organization
One potential problem with using shared unicast addresses is
routers forwarding traffic to them may have more than one
route, and those routes may, in fact, reach different instances
Hardie Informational [Page 3]
RFC 3258 Distributing Authoritative Name Servers April 2002
the shared unicast address. Applications like the DNS,
communication typically consists of independent request-
messages each fitting in a single UDP packet present no problem
Other applications, in which multiple packets must reach the
endpoint (e.g., TCP) may fail or present unworkable
characteristics in some circumstances. Split-destination
may occur when a router does per-packet (or round-robin)
sharing, a topology change occurs that changes the relative
of two paths to the same anycast destination, etc
Four things mitigate the severity of this problem. The first is
UDP is a fairly high proportion of the query traffic to name servers
The second is that the aim of this proposal is to
topological placement; for most users, this means that
coordination of placement will ensure that new instances of a
server will be at a significantly different cost metric from
instances. Some set of users may end up in the middle, but
should be relatively rare. The third is that per packet load
is only one of the possible load sharing mechanisms, and
mechanisms are increasing in popularity
Lastly, in the case where the traffic is TCP, per packet load
is used, and equal cost routes to different instances of a
server are available, any DNS implementation which measures
performance of servers to select a preferred server will
prefer a server for which this problem does not occur. For the
failover mechanisms to reliably avoid this problem, however,
using shared unicast distribution mechanisms must take care that
of the servers for a specific zone are not participants in the
shared-unicast mesh. To guard even against the case where
meshes have a set of users affected by per packet load sharing
equal cost routes, organizations implementing these practices
always provide at least one authoritative server which is not
participant in any shared unicast mesh. Those deploying shared
unicast meshes should note that any specific host may
unreachable to a client should a server fail, a path fail, or
route to that host be withdrawn. These error conditions are
however, not specific to shared-unicast distributions, but
occur for standard unicast hosts
Since ICMP response packets might go to a different member of
mesh than that sending a packet, packets sent with a shared
source address should also avoid using path MTU discovery
Appendix A. contains an ASCII diagram of an example of a
implementation of this system. In it, the odd numbered
deliver traffic to the shared-unicast interface network and
traffic from the administrative network; the even numbered
Hardie Informational [Page 4]
RFC 3258 Distributing Authoritative Name Servers April 2002
deliver traffic to the administrative network and filter traffic
the shared-unicast network. These are depicted as separate
for the ease this gives in explanation, but they could easily
separate interfaces on the same router. Similarly, a local
source is depicted for synchronization, but the level
synchronization needed would not require that source to be
local or a stratum one NTP server
3.
3.1 Points of
A single point of contact for reporting problems is crucial to
correct administration of this system. If an external user of
system needs to report a problem related to the service, there
be no ambiguity about whom to contact. If internal monitoring
not indicate a problem, the contact may, of course, need to work
the external user to identify which server generated the error
4. Security
As a core piece of Internet infrastructure, authoritative
servers are common targets of attack. The practices outlined
increase the risk of certain kinds of attacks and reduce the risk
others
4.1 Increased
4.1.1 Increase in physical
The architecture outlined in this document increases the number
physical servers, which could increase the possibility that a
mis-configuration will occur which allows for a security breach.
general, the entity administering a mesh should ensure that
and security mechanisms applied to a single member of the mesh
appropriate for and applied to all of the members of a mesh
"Genetic diversity" (code from different code bases) can be a
security measure in avoiding attacks based on vulnerabilities in
specific code base; in order to ensure consistency of responses
a single named server, however, that diversity should be applied
different shared-unicast meshes or between a mesh and a
unicast authoritative server
4.1.2 Data synchronization
The level of systemic synchronization described above should
augmented by synchronization of the data present at each of
servers. While the DNS itself is a loosely coupled system,
Hardie Informational [Page 5]
RFC 3258 Distributing Authoritative Name Servers April 2002
problems with data in specific zones would be far more difficult
two different servers sharing a single unicast address might
different responses to the same query. For example, if the
associated with www.example.com has changed and the administrators
the domain are testing for the changes at the example.
authoritative name servers, they should not need to check
instance of a named authoritative server. The use of NTP to
a synchronized time for switch-over eliminates some aspects of
problem, but mechanisms to handle failure during the switchover
required. In particular, a server which cannot make the
must not roll-back to a previous version; it must cease to respond
queries so that other servers are queried
4.1.3 Distribution
If the mechanism used to distribute zone files among the servers
not well secured, a man-in-the-middle attack could result in
injection of false information. Digital signatures will
this risk, but encrypted transport and tight access lists are
necessary adjunct to them. Since zone files will be distributed
the administrative interfaces of meshed servers, the access
list for distribution of the zone files should include
administrative interface of the server or servers, rather than
shared unicast addresses
4.2 Decreased
The increase in number of physical servers reduces the
that a denial-of-service attack will take out a significant
of the DNS infrastructure. The increase in servers also reduces
effect of machine crashes, fiber cuts, and localized disasters
reducing the number of users dependent on a specific machine
5.
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak
Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato
Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg
provided input and commentary on this work. The editor wishes
remember in particular the contribution of the late Scott Tucker
whose extensive systems experience and plain common sense
contributed greatly to the editor's own deployment experience and
missed by all who knew him
Hardie Informational [Page 6]
RFC 3258 Distributing Authoritative Name Servers April 2002
6.
[SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "
and Operation of Secondary DNS Servers", BCP 16,
2182, July 1997.
[ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "
Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000.
[ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "
Anycasting Service", RFC 1546, November 1993.
Hardie Informational [Page 7]
RFC 3258 Distributing Authoritative Name Servers April 2002
Appendix A
__________________
Peer 1-| |
Peer 2-| |
Peer 3-| Switch |
Transit| | _________ _________
etc | |--|Router1|---|----|----------|Router2|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router3|---|----|----------|Router4|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router5|---|----|----------|Router6|---WAN-|
| | --------- | | --------- |
| | | | |
| | | | |
------------------ [NTP] [DNS] |
|
|
|
Hardie Informational [Page 8]
RFC 3258 Distributing Authoritative Name Servers April 2002
|
__________________ |
Peer 1-| | |
Peer 2-| | |
Peer 3-| Switch | |
Transit| | _________ _________ |
etc | |--|Router7|---|----|----------|Router8|---WAN-|
| | --------- | | ---------
| | | |
| | | |
------------------ [NTP] [DNS
Hardie Informational [Page 9]
RFC 3258 Distributing Authoritative Name Servers April 2002
7. Editor's
Ted
Nominum, Inc
2385 Bay Road
Redwood City, CA 94063
Phone: 1.650.381.6226
EMail: Ted.Hardie@nominum.
Hardie Informational [Page 10]
RFC 3258 Distributing Authoritative Name Servers April 2002
8. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Hardie Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
