diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3258.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3258.txt | 619 |
1 files changed, 0 insertions, 619 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3258.txt b/contrib/bind9/doc/rfc/rfc3258.txt deleted file mode 100644 index dcd4b34b2b6e..000000000000 --- a/contrib/bind9/doc/rfc/rfc3258.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -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] - |