summaryrefslogtreecommitdiff
path: root/doc/draft/draft-ietf-dnsop-hardie-shared-root-server-03.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-ietf-dnsop-hardie-shared-root-server-03.txt')
-rw-r--r--doc/draft/draft-ietf-dnsop-hardie-shared-root-server-03.txt396
1 files changed, 0 insertions, 396 deletions
diff --git a/doc/draft/draft-ietf-dnsop-hardie-shared-root-server-03.txt b/doc/draft/draft-ietf-dnsop-hardie-shared-root-server-03.txt
deleted file mode 100644
index 209d6340..00000000
--- a/doc/draft/draft-ietf-dnsop-hardie-shared-root-server-03.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-IETF DNSOPS working group T. Hardie
-Internet draft Equinix, Inc
-Category: Work-in-progress January, 2001
-
-draft-ietf-dnsop-hardie-shared-root-server-03.txt
-
-
- Distributing Authoritative Name Servers via Shared Unicast Addresses
-
-
-
-Status of this memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 1999. 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 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.
-
-
-1. Architecture
-
-1.1 Server Requirements
-
- Operators of authoritative name servers may wish to refer to [1] and
- [2] 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 shared unicast address
- associated with the authoritative name server. The other interface,
- referred to as the administrative interface below, should use a
- distinct 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.
-
-
-1.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 transer, 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 1.5 below.
-
-1.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 3.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
- 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.
-
-
-1.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.
-
-1.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
- the shared unicast address. Because UDP is self-contained, UDP
- traffic from a single source reaching different instances presents
- no problem. TCP traffic, in contrast, may fail or present
- unworkable performance characteristics in a limited set of
- circumstances. For split-destination failures to occur, the router
- forwarding the traffic must both have equal cost routes to the two
- different instances and use a load sharing algorithm which does
- per-packet rather than per-destination load sharing.
-
- 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 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
- authoritative servers, care must be taken 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.
-
- Appendix A. contains an ASCII diagram 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 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.
-
-
-2. Administration
-
-2.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.
-
-
-3. 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 attack and reduce the risk of
- others.
-
-3.1 Increased Risks
-
-3.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.
-
-3.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 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 root 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.
-
-3.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.
-
-3.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.
-
-
-4. Full copyright statement
-
- Copyright (C) The Internet Society 1999. 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.
-
-5. Acknowledgements
-
- Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
- Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, Akira Kato,
- Suzanne Woolf, Scott Tucker, and Gunnar Lindberg all provided input
- and commentary on this work.
-
-
-6. References
-
-[1] "Selection and Operation of Secondary Name Servers". R. Elz, R. Bush,
-S Bradner, M. Patton, BCP0016.
-
-[2] "Root Name Server Operational Requirements". R. Bush,
-D. Karrenberg, M. Kosters, R. Plzak, BCP0040.
-
-
-7. Editor's address
-
- Ted Hardie
- Equinix, Inc.
- 2450 Bayshore Parkway
- Mountain View, CA 94043-1107
- hardie@equinix.com
- Tel: 1.650.316.6226
- Fax: 1.650.315.6903
-
-
-
-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] |
- |
- |
- |
- |
- __________________ |
-Peer 1-| | |
-Peer 2-| | |
-Peer 3-| Switch | |
-Transit| | _________ _________ |
-etc | |--|Router7|---|----|--------------|Router8|---WAN-|
- | | --------- | | ---------
- | | | |
- | | | |
- ------------------ [NTP] [DNS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-