summaryrefslogtreecommitdiffstats
path: root/doc/rfc/rfc3258.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3258.txt')
-rw-r--r--doc/rfc/rfc3258.txt619
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]
+
generated by cgit (git 2.34.1) at 2024-04-26 23:16:56 +0000