draft-ietf-dnsop-hardie-shared-root-server-02.txt   draft-ietf-dnsop-hardie-shared-root-server-03.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 June 2000 Category: Work-in-progress January, 2001
draft-ietf-dnsop-hardie-shared-root-server-02.txt draft-ietf-dnsop-hardie-shared-root-server-03.txt
Distributing Root or 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 39 skipping to change at line 39
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 1999. All Rights Reserved. Copyright (C) The Internet Society 1999. All Rights Reserved.
Abstract Abstract
This memo describes a set of practices intended to enable an This memo describes a set of practices intended to enable an
authoritative name server operator to provide access to a single authoritative name server operator to provide access to a single
named server in multiple locations. It was originally written to named server in multiple locations. The primary motivation for the
apply particularly to root server operations and later expanded to development and deployment of these practices is to increase the
include the more general case of authoritative name servers. In distribution of DNS servers to previously under-served areas of the
both cases, the primary motivation for the development and network topology and to reduce the latency for DNS query responses
deployment of these practices is to increase the distribution of DNS in those areas. This document presumes a one-to-one mapping between
servers to previously under-served areas of the network topology and named authoritative servers and administrative entities (operators).
to reduce the latency for DNS query responses in those areas. This This document contains no guidelines or recommendations for caching
document presumes a one-to-one mapping between named authoritative name servers.
servers and administrative entities (operators). This document
contains no guidelines or recommendations for caching name servers.
1. Architecture 1. Architecture
1.1 Server Requirements 1.1 Server Requirements
Root servers must meet the host requirements listed in [1], and Operators of authoritative name servers may wish to refer to [1] and
operators of other authoritative name servers may also wish to refer [2] for general guidance on appropriate practice for authoritative
to it for guidance on appropriate practice. In addition to meeting name servers. In addition to proper configuration as a standard
those requirements, each of the hosts participating in a authoritative name server, each of the hosts participating in a
shared-unicast system should be configured with two network shared-unicast system should be configured with two network
interfaces. These interfaces may be either two physical interfaces interfaces. These interfaces may be either two physical interfaces
or one physical interface mapped to two logical interfaces. or one physical interface mapped to two logical interfaces. One of
One of the network interfaces should use the shared the network interfaces should use the shared unicast address
unicast address associated with the authoritative name server. The associated with the authoritative name server. The other interface,
other interface, referred to as the administrative interface below, referred to as the administrative interface below, should use a
should use a distinct address specific to that host. The host distinct address specific to that host. The host should respond to
should respond to DNS queries only on the shared-unicast interface. DNS queries only on the shared-unicast interface. In order to
Responses on that interface should only relate to zones for which provide the most consistent set of responses from the mesh of
the host is authoritative; the host should not be configured as a anycast hosts, it is good practice to limit responses on that
caching name server. The host should use the administrative interface to zones for which the host is authoritative.
interface and address for all mesh coordination.
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
noted in section 1.5 below. noted in section 1.5 below.
1.3 Synchronization 1.3 Synchronization
The root name servers traditionally form a loosely synchronized Authoritative name servers may be loosely or tightly synchronized,
system and some delay in propagation of a specific zone file is an depending on the practices set by the operating organization. As
expected part of the current operational environment. Authoritative noted below in section 3.1.2, lack of synchronization among servers
name servers may be loosely or tightly synchronized, depending on using the same shared unicast address could create problems for some
the practices set by the operating organization. As noted below in users of this service. In order to minimize that risk, switch-overs
section 3.1.2, lack of synchronization among servers using the same from one data set to another data set should be coordinated as much
shared unicast address could create problems for some users of this as possible. The use of synchronized clocks on the participating
service. In order to minimize that risk, switch-overs from one data hosts and set times for switch-overs provides a basic level of
set to another data set should be coordinated as much as possible. coordination. A more complete coordination process would involve:
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 a) receipt of zones at a distribution host
b) confirmation of the integrity of zones received b) confirmation of the integrity of zones received
c) distribution of the zones to all of the servers in the c) distribution of the zones to all of the servers in the
mesh mesh
d) confirmation of the integrity of the zones at each server d) confirmation of the integrity of the zones at each server
e) coordination of the switchover times for the servers in the e) coordination of the switchover times for the servers in the
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
skipping to change at line 161 skipping to change at line 155
server will be at a significantly different cost metric from server will be at a significantly different cost metric from
existing instances. Some set of users may end up in the middle, but 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 that should be relatively rare. The third is that per packet load
sharing is only one of the possible load sharing mechanisms, and sharing is only one of the possible load sharing mechanisms, and
other mechanisms are increasing in popularity. other mechanisms are increasing in popularity.
Lastly, in the case where the traffic is TCP, per packet load Lastly, in the case where the traffic is TCP, per packet load
sharing is used, and equal cost routes to different instances of a sharing is used, and equal cost routes to different instances of a
name server are available, any implementation which measures the name server are available, any implementation which measures the
performance of servers to select a preferred server will quickly performance of servers to select a preferred server will quickly
prefer a server for which this problem does not occur. The root prefer a server for which this problem does not occur. For
server system distributes the root servers among multiple
organizations, which automatically mitigates the problem by ensuring
that no single AS is announcing all of the salient servers. For
authoritative servers, care must be taken that all of the servers authoritative servers, care must be taken that all of the servers
for a specific zone are not participants in the same shared-unicast for a specific zone are not participants in the same shared-unicast
mesh. To guard even against the case where multiple meshes have mesh. To guard even against the case where multiple meshes have a
a set of users affected by per packet load sharing along equal cost set of users affected by per packet load sharing along equal cost
routes, organizations implementing these practices should always routes, organizations implementing these practices should always
provide at least one authoritative server which is not a participant provide at least one authoritative server which is not a participant
in any shared unicast mesh. Those deploying shared-unicast meshes in any shared unicast mesh. Those deploying shared-unicast meshes
should note that any specific host may become unreachable to a client should note that any specific host may become unreachable to a
should a server fail, a path fail, or the route to that host be withdrawn; client should a server fail, a path fail, or the route to that host
these error conditions are not specific to shared-unicast 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 Appendix A. contains an ASCII diagram of a simple implementation of
this system. In it, the odd numbered routers deliver traffic to the this system. In it, the odd numbered routers deliver traffic to the
shared-unicast interface network and filter traffic from the shared-unicast interface network and filter traffic from the
administrative network; the even numbered routers deliver traffic to administrative network; the even numbered routers deliver traffic to
the administrative network and filter traffic from the shared-unicast the administrative network and filter traffic from the shared-unicast
network. These are depicted as separate routers for the ease this network. These are depicted as separate routers for the ease this
gives in explanation, but they could easily be separate interfaces gives in explanation, but they could easily be separate interfaces
on the same router. Similarly, a local NTP source is depicted for on the same router. Similarly, a local NTP source is depicted for
synchronization, but the level of synchronization needed would not synchronization, but the level of synchronization needed would not
skipping to change at line 201 skipping to change at line 194
A single point of contact for reporting problems is crucial to the A single point of contact for reporting problems is crucial to the
correct administration of this system. If an external user of the correct administration of this system. If an external user of the
system needs to report a problem related to the service, there must system needs to report a problem related to the service, there must
be no ambiguity about whom to contact. If internal monitoring does be no ambiguity about whom to contact. If internal monitoring does
not indicate a problem, the contact may, of course, need to work not indicate a problem, the contact may, of course, need to work
with the external user to identify which server generated the with the external user to identify which server generated the
error. error.
3. Security Considerations 3. Security Considerations
As a core piece of internet infrastructure, the root servers are a As a core piece of internet infrastructure, authoritative name
common target of attack; authoritative name servers may also be servers are common targets of attack. The practices outlined here
targets of attack. The practices outlined here increase the risk increase the risk of certain kinds of attack and reduce the risk of
of certain kinds of attack and reduce the risk of others. others.
3.1 Increased Risks 3.1 Increased Risks
3.1.1 Increase in physical servers 3.1.1 Increase in physical servers
The architecture outlined in this document increases the number of The architecture outlined in this document increases the number of
physical servers, which could increase the possibility that a physical servers, which could increase the possibility that a
server mis-configuration will occur which allows for a security server mis-configuration will occur which allows for a security
breach. In general, the entity administering a mesh should ensure breach. In general, the entity administering a mesh should ensure
that patches and security mechanisms applied to a single member of 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 the mesh are appropriate for and applied to all of the members of a
mesh. 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 3.1.2 Data synchronization problems
The level of systemic synchronization described above should be The level of systemic synchronization described above should be
augmented by synchronization of the data present at each of the augmented by synchronization of the data present at each of the
servers. While the DNS itself is a loosely coupled system, servers. While the DNS itself is a loosely coupled system,
debugging problems with data in specific zones would be far more debugging problems with data in specific zones would be far more
difficult if two different servers sharing a single unicast address difficult if two different servers sharing a single unicast address
might return different responses to the same query. For example, might return different responses to the same query. For example,
if the data associated with example.com has changed and the if the data associated with www.example.com has changed and the
administrators of the domain are testing for the changes at the administrators of the domain are testing for the changes at the
root name servers, they should not need to check each instance of a example.com authoritative name servers, they should not need to
named root server. The use of ntp to provide a synchronized time check each instance of a named root server. The use of ntp to
for switch-over eliminates some aspects of this problem, but provide a synchronized time for switch-over eliminates some aspects
mechanisms to handle failure during the switchover are required. of this problem, but mechanisms to handle failure during the
In particular, a server which cannot make the switchover must not switchover are required. In particular, a server which cannot make
roll-back to a previous version; it must cease to respond to the switchover must not roll-back to a previous version; it must
queries so that other servers are queried. cease to respond to queries so that other servers are queried.
3.1.3 Distribution risks 3.1.3 Distribution risks
If the mechanism used to distribute zone files among the servers is 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 not well secured, a man-in-the-middle attack could result in the
injection of false information. Digital signatures will alleviate injection of false information. Digital signatures will alleviate
this risk, but encrypted transport and tight access lists are a this risk, but encrypted transport and tight access lists are a
necessary adjunct to them. Since zone files will be distributed to necessary adjunct to them. Since zone files will be distributed to
the administrative interfaces of meshed servers, the access control the administrative interfaces of meshed servers, the access control
list for distribution of the zone files should include the list for distribution of the zone files should include the
administrative interface of the server or servers, rather than administrative interface of the server or servers, rather than
their shared unicast addresses. their shared unicast addresses.
3.2 Decreased Risks 3.2 Decreased Risks
The increase in number of physical servers reduces, however, the The increase in number of physical servers reduces the likelihood
likelihood that a denial-of-service attack will take out a that a denial-of-service attack will take out a significant portion
significant portion of the DNS infrastructure. The increase in of the DNS infrastructure. The increase in servers also reduces
servers also reduces the effect of machine crashes, fiber cuts, and the effect of machine crashes, fiber cuts, and localized disasters
localized disasters by reducing the number of users dependent on by reducing the number of users dependent on a specific machine.
a specific machine.
4. IANA Considerations
Any root server operator choosing to employ the practices described
in this document should do so in coordination with the Root Server
System Advisory Committee. Since the aim of this set of practices
for root server operations is to increase the availability of root
servers in under-served areas of the network topology, coordination
of the deployment of new servers would also be of benefit.
5. Full copyright statement 4. Full copyright statement
Copyright (C) The Internet Society 1999. All Rights Reserved. Copyright (C) The Internet Society 1999. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works. paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such However, this document itself may not be modified in any way, such
skipping to change at line 298 skipping to change at line 286
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, and Gunnar Lindberg all provided input and Suzanne Woolf, Scott Tucker, and Gunnar Lindberg all provided input
commentary on this work. and commentary on this work.
6. References 6. References
[1] "Root Name Server Operational Requirements". Randy Bush, Daniel [1] "Selection and Operation of Secondary Name Servers". R. Elz, R. Bush,
Karrenberg, Mark Kosters, Raymond Plzak, S Bradner, M. Patton, BCP0016.
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-root-opreq-03.txt
[2] "Root Name Server Operational Requirements". R. Bush,
D. Karrenberg, M. Kosters, R. Plzak, BCP0040.
7. Editor's address 7. Editor's address
Ted Hardie Ted Hardie
Equinix, Inc. Equinix, Inc.
901 Marshall St. 2450 Bayshore Parkway
Redwood City, CA 94063 Mountain View, CA 94043-1107
hardie@equinix.com hardie@equinix.com
Tel: 1.650.817.2226 Tel: 1.650.316.6226
Fax: 1.650.298.0420 Fax: 1.650.315.6903
Appendix A. Appendix A.
__________________ __________________
Peer 1-| | Peer 1-| |
Peer 2-| | Peer 2-| |
Peer 3-| Switch | Peer 3-| Switch |
Transit| | _________ _________ Transit| | _________ _________
etc | |--|Router1|---|----|--------------|Router2|---WAN-| etc | |--|Router1|---|----|--------------|Router2|---WAN-|
| | --------- | | --------- | | | --------- | | --------- |
 End of changes. 

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