draft-ietf-dnsop-hardie-shared-root-server-04.txt   draft-ietf-dnsop-hardie-shared-root-server-05.txt 
IETF DNSOPS working group T. Hardie IETF DNSOPS working group T. Hardie
Internet draft Equinix, Inc Internet draft Equinix, Inc
Category: Work-in-progress March, 2001 Category: Work-in-progress April, 2001
draft-ietf-dnsop-hardie-shared-root-server-04.txt draft-ietf-dnsop-hardie-shared-root-server-05.txt
Distributing Authoritative Name Servers via Shared Unicast Addresses Distributing Authoritative Name Servers via Shared Unicast Addresses
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 49 skipping to change at line 49
named server in multiple locations. The primary motivation for the named server in multiple locations. The primary motivation for the
development and deployment of these practices is to increase the development and deployment of these practices is to increase the
distribution of DNS servers to previously under-served areas of the distribution of DNS servers to previously under-served areas of the
network topology and to reduce the latency for DNS query responses network topology and to reduce the latency for DNS query responses
in those areas. This document presumes a one-to-one mapping between in those areas. This document presumes a one-to-one mapping between
named authoritative servers and administrative entities (operators). named authoritative servers and administrative entities (operators).
This document contains no guidelines or recommendations for caching This document contains no guidelines or recommendations for caching
name servers. The shared unicast system described here is specific name servers. The shared unicast system described here is specific
to IPv4; IPv6 uses anycast differently from IPv4 and those to IPv4; IPv6 uses anycast differently from IPv4 and those
differences prevent this system from being used in IPv6 differences prevent this system from being used in IPv6
environments. environments. It should also be noted that the system described
here is related to that describe 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.
1. Architecture 1. Architecture
1.1 Server Requirements 1.1 Server Requirements
Operators of authoritative name servers may wish to refer to [1] and Operators of authoritative name servers may wish to refer to
[2] for general guidance on appropriate practice for authoritative [SECONDARY] and [ROOT] for general guidance on appropriate practice
name servers. In addition to proper configuration as a standard for authoritative name servers. In addition to proper configuration
authoritative name server, each of the hosts participating in a as a standard authoritative name server, each of the hosts
shared-unicast system should be configured with two network participating in a shared-unicast system should be configured with
interfaces. These interfaces may be either two physical interfaces two network interfaces. These interfaces may be either two physical
or one physical interface mapped to two logical interfaces. One of interfaces or one physical interface mapped to two logical
the network interfaces should use the IPv4 shared unicast address interfaces. One of the network interfaces should use the IPv4
associated with the authoritative name server. The other interface, shared unicast address associated with the authoritative name
referred to as the administrative interface below, should use a server. The other interface, referred to as the administrative
distinct IPv4 address specific to that host. The host should interface below, should use a distinct IPv4 address specific to that
respond to DNS queries only on the shared-unicast interface. In host. The host should respond to DNS queries only on the
order to provide the most consistent set of responses from the mesh shared-unicast interface. In order to provide the most consistent
of anycast hosts, it is good practice to limit responses on that set of responses from the mesh of anycast hosts, it is good practice
interface to zones for which the host is authoritative. to limit responses on that interface to zones for which the host is
authoritative.
1.2 Zone file delivery 1.2 Zone file delivery
In order to minimize the risk of man-in-the-middle attacks, zone In order to minimize the risk of man-in-the-middle attacks, zone
files should be delivered to the administrative interface of the files should be delivered to the administrative interface of the
servers participating in the mesh. Secure file transfer methods and servers participating in the mesh. Secure file transfer methods and
strong authentication should be used for all transfers. If the hosts strong authentication should be used for all transfers. If the hosts
in the mesh make their zones available for zone transer, the administrative 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 interfaces should be used for those transfers as well, in order to avoid
the problems with potential routing changes for TCP traffic the problems with potential routing changes for TCP traffic
skipping to change at line 110 skipping to change at line 115
mesh mesh
f) institution of a failure process to ensure that servers that f) institution of a failure process to ensure that servers that
did not receive correct data or could not switchover to the did not receive correct data or could not switchover to the
new data ceased to respond to incoming queries until the new data ceased to respond to incoming queries until the
problem could be resolved. problem could be resolved.
Depending on the size of the mesh, the distribution host may also be 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 a participant; for authoritative servers, it may also be the host on
which zones are generated. 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 the 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.
1.4 Server Placement 1.4 Server Placement
Though the geographic diversity of server placement helps reduce the Though the geographic diversity of server placement helps reduce the
effects of service disruptions due to local problems, it is effects of service disruptions due to local problems, it is
diversity of placement in the network topology which is the driving diversity of placement in the network topology which is the driving
force behind these distribution practices. Server placement should force behind these distribution practices. Server placement should
emphasize that diversity. Ideally, servers should be placed emphasize that diversity. Ideally, servers should be placed
topologically near the points at which the operator exchanges routes topologically near the points at which the operator exchanges routes
and traffic with other networks. and traffic with other networks.
skipping to change at line 289 skipping to change at line 307
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5. Acknowledgements 5. Acknowledgements
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, Akira Kato, Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, Akira Kato,
Suzanne Woolf, Scott Tucker, and Gunnar Lindberg all provided input Suzanne Woolf, Scott Tucker, Bernard Aboba, Casey Ajalat and Gunnar
and commentary on this work. Lindberg all provided input and commentary on this work.
6. References 6. References
[1] "Selection and Operation of Secondary Name Servers". R. Elz, R. Bush, [SECONDARY] "Selection and Operation of Secondary Name Servers".
S Bradner, M. Patton, BCP0016. R. Elz, R. Bush, S Bradner, M. Patton, BCP0016.
[2] "Root Name Server Operational Requirements". R. Bush, [ROOT] "Root Name Server Operational Requirements". R. Bush,
D. Karrenberg, M. Kosters, R. Plzak, BCP0040. D. Karrenberg, M. Kosters, R. Plzak, BCP0040.
[ANYCAST] "Host Anycasting Service". C. Patridge, T. Mendez, W. Milliken,
RFC1546.
7. Editor's address 7. Editor's address
Ted Hardie Ted Hardie
Equinix, Inc. Equinix, Inc.
2450 Bayshore Parkway 2450 Bayshore Parkway
Mountain View, CA 94043-1107 Mountain View, CA 94043-1107
hardie@equinix.com hardie@equinix.com
Tel: 1.650.316.6226 Tel: 1.650.316.6226
Fax: 1.650.315.6903 Fax: 1.650.315.6903
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/