draft-ietf-dnsop-hardie-shared-root-server-06.txt   draft-ietf-dnsop-hardie-shared-root-server-07.txt 
IETF DNSOPS working group T. Hardie IETF DNSOPS working group T. Hardie
Internet draft Nominum, Inc Internet draft Nominum, Inc
Category: Work-in-progress November, 2001 Category: Work-in-progress January, 2002
draft-ietf-dnsop-hardie-shared-root-server-06.txt draft-ietf-dnsop-hardie-shared-root-server-07.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 48 skipping to change at line 48
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. 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; applicability to IPv6 is an area for further study. It
differences prevent this system from being used in IPv6 should also be noted that the system described here is related to
environments. It should also be noted that the system described that described in [ANYCAST], but it does not require dedicated
here is related to that describe in [ANYCAST], but it does not address space, routing changes, or the other elements of a full
require dedicated address space, routing changes, or the other anycast infrastructure which that document describes.
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 Operators of authoritative name servers may wish to refer to
[SECONDARY] and [ROOT] for general guidance on appropriate practice [SECONDARY] and [ROOT] for general guidance on appropriate practice
for authoritative name servers. In addition to proper configuration for authoritative name servers. In addition to proper configuration
as a standard authoritative name server, each of the hosts as a standard authoritative name server, each of the hosts
participating in a shared-unicast system should be configured with participating in a shared-unicast system should be configured with
skipping to change at line 83 skipping to change at line 81
set of responses from the mesh of anycast hosts, it is good practice 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 to limit responses on that interface to zones for which the host is
authoritative. 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 transfer, 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
Authoritative name servers may be loosely or tightly synchronized, Authoritative name servers may be loosely or tightly synchronized,
depending on the practices set by the operating organization. As depending on the practices set by the operating organization. As
noted below in section 3.1.2, lack of synchronization among servers noted below in section 3.1.2, lack of synchronization among servers
using the same shared unicast address could create problems for some using the same shared unicast address could create problems for some
skipping to change at line 153 skipping to change at line 151
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 name server. network containing the shared-unicast address of the name server.
The organization's border routers must then deliver the traffic The organization's border routers must then deliver the traffic
destined for the name server to the nearest instantiation. Routing destined for the name server to the nearest instantiation. Routing
to the administrative interfaces for the servers can use the normal to the administrative interfaces for the servers can use the normal
routing methods for the administering organization. routing methods for the administering 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. Applications like the DNS, whose
traffic from a single source reaching different instances presents communication typically consists of independent request-response
no problem. TCP traffic, in contrast, may fail or present messages each fitting in a single UDP packet presents no problem.
unworkable performance characteristics in a limited set of Other applications, in which multiple packets must reach the same
circumstances. For split-destination failures to occur, the router endpoint (e.g., TCP) may fail or present unworkable performance
forwarding the traffic must both have equal cost routes to the two characteristics in some circumstances. Split-destination failures
different instances and use a load sharing algorithm which does may occur when a router does per-packet (or round-robin) load
per-packet rather than per-destination load sharing. 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 Four things mitigate the severity of this problem. The first is
that UDP is a fairly high proportion of the query traffic to name 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 topological placement; for most users, this means that the diversify topological placement; for most users, this means that the
coordination of placement will ensure that new instances of a name coordination of placement will ensure that new instances of a name
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 DNS 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. For prefer a server for which this problem does not occur. For the DNS
authoritative servers, care must be taken that all of the servers failover mechanisms to reliably avoid this problem, however, those
for a specific zone are not participants in the same shared-unicast using shared unicast distribution mechanisms must take care that all
mesh. To guard even against the case where multiple meshes have a of the servers for a specific zone are not participants in the same
set of users affected by per packet load sharing along equal cost shared-unicast mesh. To guard even against the case where multiple
routes, organizations implementing these practices should always meshes have a set of users affected by per packet load sharing along
provide at least one authoritative server which is not a participant equal cost routes, organizations implementing these practices should
in any shared unicast mesh. Those deploying shared-unicast meshes always provide at least one authoritative server which is not a
should note that any specific host may become unreachable to a participant in any shared unicast mesh. Those deploying
client should a server fail, a path fail, or the route to that host shared-unicast meshes should note that any specific host may become
be withdrawn. These error conditions are, however, not specific to unreachable to a client should a server fail, a path fail, or the
shared-unicast distributions, but would occur for standard unicast route to that host be withdrawn. These error conditions are,
hosts. 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 Since ICMP response packets might go to a different member of the
this system. In it, the odd numbered routers deliver traffic to the mesh than that sending a packet, packets sent with a shared unicast
shared-unicast interface network and filter traffic from the source address should also avoid using path MTU discovery.
administrative network; the even numbered routers deliver traffic to
the administrative network and filter traffic from the shared-unicast Appendix A. contains an ASCII diagram of a example of a simple
network. These are depicted as separate routers for the ease this implementation of this system. In it, the odd numbered routers
gives in explanation, but they could easily be separate interfaces deliver traffic to the shared-unicast interface network and filter
on the same router. Similarly, a local NTP source is depicted for traffic from the administrative network; the even numbered routers
synchronization, but the level of synchronization needed would not deliver traffic to the administrative network and filter traffic
require that source to be either local or a stratum one NTP server. 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. Administration
2.1 Points of Contact 2.1 Points of Contact
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, authoritative name As a core piece of Internet infrastructure, authoritative name
servers are common targets of attack. The practices outlined here servers are common targets of attack. The practices outlined here
increase the risk of certain kinds of attack and reduce the risk of increase the risk 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
skipping to change at line 304 skipping to change at line 309
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
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. Acknowledgments
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, Bernard Aboba, Casey Ajalat and Gunnar Suzanne Woolf, Scott Tucker, Bernard Aboba, Casey Ajalat and Gunnar
Lindberg all provided input and commentary on this work. Lindberg all provided input and commentary on this work.
6. References 6. References
[SECONDARY] "Selection and Operation of Secondary Name Servers". [SECONDARY] "Selection and Operation of Secondary Name Servers".
R. Elz, R. Bush, S Bradner, M. Patton, BCP0016. R. Elz, R. Bush, S Bradner, M. Patton, BCP0016.
 End of changes. 

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