draft-ietf-dnsop-hardie-shared-root-server-00.txt   draft-ietf-dnsop-hardie-shared-root-server-01.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 October 1999 Category: Work-in-progress December 1999
draft-ietf-dnsop-hardie-shared-root-server-00.txt draft-ietf-dnsop-hardie-shared-root-server-01.txt
Distributing Root Name Servers via Shared Unicast Addresses Distributing Root or 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 37 skipping to change at line 37
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
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 a root This memo describes a set of practices intended to enable an
server operator to provide access to a single named root server in authoritative name server operator to provide access to a single
multiple locations. This document presumes a one-to-one mapping named server in multiple locations. It was originally written to
between named root servers and administrative entities (operators). apply particularly to root server operations and later expanded to
The primary motivation for the development of these practices is to include the more general case of authoritative name servers. In
increase the distribution of root DNS servers to previously both cases, the primary motivation for the development and
under-served areas of the network topology and to reduce the latency deployment of these practices is to increase the distribution of DNS
for DNS query responses in those areas. 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. Architecture
1.1 Server Requirements 1.1 Server Requirements
In addition to meeting the host requirements for root servers listed Root servers must meet the host requirements listed in [1], and
in [1], each of the hosts should be configured with two network operators of other authoritative name servers may also wish to refer
to it for guidance on appropriate practice. In addition to meeting
those requirements, each of the hosts participating in a
shared-unicast system should be configured with two network
interfaces. One of the network interfaces should use the shared interfaces. One of the network interfaces should use the shared
unicast address associated with the root name server. The other unicast address associated with the authoritative name server. The
interface, referred to as the administrative interface below, should other interface, referred to as the administrative interface below,
use a distinct address specific to that host. The host should should use a distinct address specific to that host. The host
respond to DNS queries only on the shared-unicast interface. The should respond to DNS queries only on the shared-unicast interface.
host should use the administrative interface and address for all mesh Responses on that interface should only relate to zones for which
coordination. the host is authoritative; the host should not be configured as a
caching name server. The host should use the administrative
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. strong authentication should be used for all transfers.
1.3 Synchronization 1.3 Synchronization
The root name servers traditionally form a loosely synchronized The root name servers traditionally form a loosely synchronized
system and some delay in propagation of a specific zone file is an system and some delay in propagation of a specific zone file is an
expected part of the current operational environment. As noted expected part of the current operational environment. Authoritative
below in section 3.1.2, lack of synchronization among servers using name servers may be loosely or tightly synchronized, depending on
the same shared unicast address could create problems for some users the practices set by the operating organization. As noted below in
of this service. In order to minimize that risk, switch-overs from section 3.1.2, lack of synchronization among servers using the same
one data set to another data set should be coordinated as much as shared unicast address could create problems for some users of this
possible. The use of synchronized clocks on the participating hosts service. In order to minimize that risk, switch-overs from one data
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
receipt of zones at a distribution host, confirmation of the times for switch-overs provides a basic level of coordination. A
integrity of zones received, distribution of the zones to all of the more complete coordination process would involve:
servers in the mesh, confirmation of the integrity of the zones at
each server, coordination of the switchover times for the servers in a) receipt of zones at a distribution host
the mesh, and the institution of a failure process to ensure that b) confirmation of the integrity of zones received
servers that did not receive correct data or could not switchover to c) distribution of the zones to all of the servers in the
the new data ceased to respond to incoming queries until the problem mesh
could be resolved. 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 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.
1.5 Routing 1.5 Routing
The organization administering the mesh of servers sharing a unicast The organization administering the mesh of servers sharing a unicast
address must have an autonomous system number and speak BGP to its address must have an autonomous system number and speak BGP to its
peers. To those peers, the organization announces a route to the peers. To those peers, the organization announces a route to the
network containing the shared-unicast address of the root name network containing the shared-unicast address of the name server.
server. The organization's border routers must then deliver the The organization's border routers must then deliver the traffic
traffic destined for the root name server to the nearest destined for the name server to the nearest instantiation. Routing
instantiation. Routing to the administrative interfaces for the to the administrative interfaces for the servers can use the normal
servers can use the normal routing methods for the administering routing methods for the administering organization.
organization.
One potential problem with using shared unicast addresses is that One potential problem with using shared unicast addresses is that
routers forwarding traffic to them may have more than one available routers forwarding traffic to them may have more than one available
route, and those routes may, in fact, reach different instances of route, and those routes may, in fact, reach different instances of
the shared unicast address. Because UDP is self-contained, UDP the shared unicast address. Because UDP is self-contained, UDP
traffic from a single source reaching different instances presents traffic from a single source reaching different instances presents
no problem. TCP traffic, in contrast, may fail or present no problem. TCP traffic, in contrast, may fail or present
unworkable performance characteristics in a limited set of unworkable performance characteristics in a limited set of
circumstances. For failures to occur, the router forwarding the traffic circumstances. For failures to occur, the router forwarding the
must both have equal cost routes to the two different instances and traffic must both have equal cost routes to the two different
use a load sharing algorithm which does per-packet rather than instances and use a load sharing algorithm which does per-packet
per-destination load sharing. rather than per-destination load sharing.
Four things mitigate the severity of this problem. The first is Four things mitigate the severity of this problem. The first is
that UDP is a fairly high proportion of the traffic to the root 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 servers. The second is that the aim of this proposal is to
diversify the topological placement of the roots; for most users, diversify topological placement; for most users, this means that the
this means that any new instances of a root server will be at a coordination of placement will ensure that new instances of a name
significantly different cost metric from existing instances. Some server will be at a significantly different cost metric from
set of users may end up in the middle, but that should be relatively existing instances. Some set of users may end up in the middle, but
rare. The third is that per packet load sharing is only one of the that should be relatively rare. The third is that per packet load
possible load sharing mechanisms, and other mechanisms are sharing is only one of the possible load sharing mechanisms, and
increasing in popularity. Lastly, in the case where the traffic other mechanisms are increasing in popularity.
is TCP, per packet load sharing is used, and equal cost routes to
different instances of a root server are available, any Lastly, in the case where the traffic is TCP, per packet load
implementation which measures the performance of the roots to select sharing is used, and equal cost routes to different instances of a
a preferred server will quickly drop that root server. Performance name server are available, any implementation which measures the
might subsequently degrade, but the affected users will still have performance of servers to select a preferred server will quickly
access to the DNS through the other twelve root servers. prefer a server for which this problem does not occur. The root
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
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.
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 165 skipping to change at line 193
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, the root servers are a
common target of attack. The practices outlined here increase the common target of attack; authoritative name servers may also be
risk of certain kinds of attack and reduce the risk of others. 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 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 acting as roots, which could increase the physical servers, which could increase the possibility that a
possibility that a server mis-configuration will occur which allows server mis-configuration will occur which allows for a security
for a security breach. In general, the entity administering a mesh breach. In general, the entity administering a mesh should ensure
should ensure that patches and security mechanisms applied to a that patches and security mechanisms applied to a single member of
single member of the mesh are appropriate for and applied to all of the mesh are appropriate for and applied to all of the members of a
the members of a mesh. mesh.
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 different two 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 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 root name servers, they should not need to check each instance of a
named root server. The use of ntp to provide a synchronized time named root server. The use of ntp to provide a synchronized time
for switch-over eliminates some aspects of this problem, but for switch-over eliminates some aspects of this problem, but
mechanisms to handle failure during the switchover are required. mechanisms to handle failure during the switchover are required.
In particular, a server which cannot make the switchover must not In particular, a server which cannot make the switchover must not
roll-back to a previous version; it must cease to respond to roll-back to a previous version; it must cease to respond to
queries so that other root servers are queried. 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. 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 3.2 Decreased Risks
The increase in number of physical servers reduces, however, the The increase in number of physical servers reduces, however, the
likelihood that a denial-of-service attack will take out a likelihood that a denial-of-service attack will take out a
significant portion of the DNS infrastructure. The increase in significant portion of the DNS infrastructure. The increase in
servers also reduces the effect of machine crashes, fiber cuts, and servers also reduces the effect of machine crashes, fiber cuts, and
localized disasters by reducing the number of users dependent on localized disasters by reducing the number of users dependent on
a specific machine. a specific machine.
4. IANA Considerations 4. IANA Considerations
Any root server operator choosing to employ the practices described Any root server operator choosing to employ the practices described
in this document should do so in coordination with the Root Server in this document should do so in coordination with the Root Server
System Advisory Committee. In particular, since zone files will be System Advisory Committee. Since the aim of this set of practices
distributed to the administrative interfaces of meshed servers, the for root server operations is to increase the availability of root
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. Since the aim of
this set of practices is to increase the availability of root
servers in under-served areas of the network topology, coordination servers in under-served areas of the network topology, coordination
of the deployment of new servers would also be of benefit. of the deployment of new servers would also be of benefit.
5. Full copyright statement 5. 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,
skipping to change at line 263 skipping to change at line 292
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, and Gunnar Lindberg all provided input and
commentary on this work. commentary on this work.
[6]. References 6. References
1 "Root Name Server Operational Requirements". Randy Bush, Daniel [1] "Root Name Server Operational Requirements". Randy Bush, Daniel
Karrenberg, Mark Kosters, Raymond Plzak, Karrenberg, Mark Kosters, Raymond Plzak,
ftp://ftp.ietf.org/internet-drafts/draft-bush-dnsop-root-opreq-00.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsop-root-opreq-03.txt
7. Editor's address 7. Editor's address
Ted Hardie Ted Hardie
Equinix, Inc. Equinix, Inc.
901 Marshall St. 901 Marshall St.
Redwood City, CA 94063 Redwood City, CA 94063
hardie@equinix.com hardie@equinix.com
Tel: 1.650.817.2226 Tel: 1.650.817.2226
Fax: 1.650.298.0420 Fax: 1.650.298.0420
 End of changes. 

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