doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc3258.txt b/doc/rfc/rfc3258.txt
new file mode 100644
index 0000000..dcd4b34
--- /dev/null
+++ b/doc/rfc/rfc3258.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                          T. Hardie
+Request for Comments: 3258                                 Nominum, Inc.
+Category: Informational                                       April 2002
+
+
+  Distributing Authoritative Name Servers via Shared Unicast Addresses
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo describes a set of practices intended to enable an
+   authoritative name server operator to provide access to a single
+   named server in multiple locations.  The primary motivation for the
+   development and deployment of these practices is to increase the
+   distribution of Domain Name System (DNS) servers to previously
+   under-served areas of the network topology and to reduce the latency
+   for DNS  query responses in those areas.
+
+1.  Introduction
+
+   This memo describes a set of practices intended to enable an
+   authoritative name server operator to provide access to a single
+   named server in multiple locations.  The primary motivation for the
+   development and deployment of these practices is to increase the
+   distribution of DNS servers to previously under-served areas of the
+   network topology and to reduce the latency for DNS query responses in
+   those areas.  This document presumes a one-to-one mapping between
+   named authoritative servers and administrative entities (operators).
+   This document contains no guidelines or recommendations for caching
+   name servers.  The shared unicast system described here is specific
+   to IPv4; applicability to IPv6 is an area for further study.  It
+   should also be noted that the system described here is related to
+   that described in [ANYCAST], but it does not require dedicated
+   address space, routing changes, or the other elements of a full
+   anycast infrastructure which that document describes.
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 1]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+2.  Architecture
+
+2.1 Server Requirements
+
+   Operators of authoritative name servers may wish to refer to
+   [SECONDARY] and [ROOT] for general guidance on appropriate practice
+   for authoritative name servers.  In addition to proper configuration
+   as a standard authoritative name server, each of the hosts
+   participating in a shared-unicast system should be configured with
+   two network interfaces.  These interfaces may be either two physical
+   interfaces or one physical interface mapped to two logical
+   interfaces.  One of the network interfaces should use the IPv4 shared
+   unicast address associated with the authoritative name server.  The
+   other interface, referred to as the administrative interface below,
+   should use a distinct IPv4 address specific to that host.  The host
+   should respond to DNS queries only on the shared-unicast interface.
+   In order to provide the most consistent set of responses from the
+   mesh of anycast hosts, it is good practice to limit responses on that
+   interface to zones for which the host is authoritative.
+
+2.2 Zone file delivery
+
+   In order to minimize the risk of man-in-the-middle attacks, zone
+   files should be delivered to the administrative interface of the
+   servers participating in the mesh.  Secure file transfer methods and
+   strong authentication should be used for all transfers.  If the hosts
+   in the mesh make their zones available for zone transfer, the
+   administrative interfaces should be used for those transfers as well,
+   in order to avoid the problems with potential routing changes for TCP
+   traffic noted in section 2.5 below.
+
+2.3 Synchronization
+
+   Authoritative name servers may be loosely or tightly synchronized,
+   depending on the practices set by the operating organization.  As
+   noted below in section 4.1.2, lack of synchronization among servers
+   using the same shared unicast address could create problems for some
+   users of this service.  In order to minimize that risk, switch-overs
+   from one data set to another data set should be coordinated as much
+   as possible.  The use of synchronized clocks on the participating
+   hosts and set times for switch-overs provides a basic level of
+   coordination.  A more complete coordination process would involve:
+
+      a) receipt of zones at a distribution host
+      b) confirmation of the integrity of zones received
+      c) distribution of the zones to all of the servers in the mesh
+      d) confirmation of the integrity of the zones at each server
+
+
+
+
+Hardie                       Informational                      [Page 2]
+
+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                      [Page 3]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   the shared unicast address.  Applications like the DNS, whose
+   communication typically consists of independent request-response
+   messages each fitting in a single UDP packet present no problem.
+   Other applications, in which multiple packets must reach the same
+   endpoint (e.g., TCP) may fail or present unworkable performance
+   characteristics in some circumstances.  Split-destination failures
+   may occur when a router does per-packet (or round-robin) load
+   sharing, a topology change occurs that changes the relative metrics
+   of two paths to the same anycast destination, etc.
+
+   Four things mitigate the severity of this problem.  The first is that
+   UDP is a fairly high proportion of the query traffic to name servers.
+   The second is that the aim of this proposal is to diversify
+   topological placement; for most users, this means that the
+   coordination of placement will ensure that new instances of a name
+   server will be at a significantly different cost metric from existing
+   instances.  Some set of users may end up in the middle, but that
+   should be relatively rare.  The third is that per packet load sharing
+   is only one of the possible load sharing mechanisms, and other
+   mechanisms are increasing in popularity.
+
+   Lastly, in the case where the traffic is TCP, per packet load sharing
+   is used, and equal cost routes to different instances of a name
+   server are available, any DNS implementation which measures the
+   performance of servers to select a preferred server will quickly
+   prefer a server for which this problem does not occur.  For the DNS
+   failover mechanisms to reliably avoid this problem, however, those
+   using shared unicast distribution mechanisms must take care that all
+   of the servers for a specific zone are not participants in the same
+   shared-unicast mesh.  To guard even against the case where multiple
+   meshes have a set of users affected by per packet load sharing along
+   equal cost routes, organizations implementing these practices should
+   always provide at least one authoritative server which is not a
+   participant in any shared unicast mesh.  Those deploying shared-
+   unicast meshes should note that any specific host may become
+   unreachable to a client should a server fail, a path fail, or the
+   route to that host be withdrawn.  These error conditions are,
+   however, not specific to shared-unicast distributions, but would
+   occur for standard unicast hosts.
+
+   Since ICMP response packets might go to a different member of the
+   mesh than that sending a packet, packets sent with a shared unicast
+   source address should also avoid using path MTU discovery.
+
+   Appendix A. contains an ASCII diagram of an example of a simple
+   implementation of this system.  In it, the odd numbered routers
+   deliver traffic to the shared-unicast interface network and filter
+   traffic from the administrative network; the even numbered routers
+
+
+
+Hardie                       Informational                      [Page 4]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   deliver traffic to the administrative network and filter traffic from
+   the shared-unicast network.  These are depicted as separate routers
+   for the ease this gives in explanation, but they could easily be
+   separate interfaces on the same router.  Similarly, a local NTP
+   source is depicted for synchronization, but the level of
+   synchronization needed would not require that source to be either
+   local or a stratum one NTP server.
+
+3. Administration
+
+3.1 Points of Contact
+
+   A single point of contact for reporting problems is crucial to the
+   correct administration of this system.  If an external user of the
+   system needs to report a problem related to the service, there must
+   be no ambiguity about whom to contact.  If internal monitoring does
+   not indicate a problem, the contact may, of course, need to work with
+   the external user to identify which server generated the error.
+
+4. Security Considerations
+
+   As a core piece of Internet infrastructure, authoritative name
+   servers are common targets of attack.  The practices outlined here
+   increase the risk of certain kinds of attacks and reduce the risk of
+   others.
+
+4.1 Increased Risks
+
+4.1.1 Increase in physical servers
+
+   The architecture outlined in this document increases the number of
+   physical servers, which could increase the possibility that a server
+   mis-configuration will occur which allows for a security breach.  In
+   general, the entity administering a mesh should ensure that patches
+   and security mechanisms applied to a single member of the mesh are
+   appropriate for and applied to all of the members of a mesh.
+   "Genetic diversity" (code from different code bases) can be a useful
+   security measure in avoiding attacks based on vulnerabilities in a
+   specific code base; in order to ensure consistency of responses from
+   a single named server, however, that diversity should be applied to
+   different shared-unicast meshes or between a mesh and a related
+   unicast authoritative server.
+
+4.1.2 Data synchronization problems
+
+   The level of systemic synchronization described above should be
+   augmented by synchronization of the data present at each of the
+   servers.  While the DNS itself is a loosely coupled system, debugging
+
+
+
+Hardie                       Informational                      [Page 5]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   problems with data in specific zones would be far more difficult if
+   two different servers sharing a single unicast address might return
+   different responses to the same query.  For example, if the data
+   associated with www.example.com has changed and the administrators of
+   the domain are testing for the changes at the example.com
+   authoritative name servers, they should not need to check each
+   instance of a named authoritative server.  The use of NTP to provide
+   a synchronized time for switch-over eliminates some aspects of this
+   problem, but mechanisms to handle failure during the switchover are
+   required.  In particular, a server which cannot make the switchover
+   must not roll-back to a previous version; it must cease to respond to
+   queries so that other servers are queried.
+
+4.1.3 Distribution risks
+
+   If the mechanism used to distribute zone files among the servers is
+   not well secured, a man-in-the-middle attack could result in the
+   injection of false information.  Digital signatures will alleviate
+   this risk, but encrypted transport and tight access lists are a
+   necessary adjunct to them.  Since zone files will be distributed to
+   the administrative interfaces of meshed servers, the access control
+   list for distribution of the zone files should include the
+   administrative interface of the server or servers, rather than their
+   shared unicast addresses.
+
+4.2 Decreased Risks
+
+   The increase in number of physical servers reduces the likelihood
+   that a denial-of-service attack will take out a significant portion
+   of the DNS infrastructure.  The increase in servers also reduces the
+   effect of machine crashes, fiber cuts, and localized disasters by
+   reducing the number of users dependent on a specific machine.
+
+5. Acknowledgments
+
+   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 all
+   provided input and commentary on this work.  The editor wishes to
+   remember in particular the contribution of the late Scott Tucker,
+   whose extensive systems experience and plain common sense both
+   contributed greatly to the editor's own deployment experience and are
+   missed by all who knew him.
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 6]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+6. References
+
+   [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
+               and Operation of Secondary DNS Servers", BCP 16, RFC
+               2182, July 1997.
+
+   [ROOT]      Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
+               Name Server Operational Requirements", BCP 40, RFC 2870,
+               June 2000.
+
+   [ANYCAST]   Patridge, C., Mendez, T. and W. Milliken, "Host
+               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 Address
+
+   Ted Hardie
+   Nominum, Inc.
+   2385 Bay Road.
+   Redwood City, CA 94063
+
+   Phone: 1.650.381.6226
+   EMail: Ted.Hardie@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                     [Page 10]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                     [Page 11]
+