draft-ietf-dnsop-hardie-shared-root-server-01.txt   draft-ietf-dnsop-hardie-shared-root-server-02.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 December 1999 Category: Work-in-progress June 2000
draft-ietf-dnsop-hardie-shared-root-server-01.txt draft-ietf-dnsop-hardie-shared-root-server-02.txt
Distributing Root or Authoritative 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
skipping to change at line 59 skipping to change at line 59
1. Architecture 1. Architecture
1.1 Server Requirements 1.1 Server Requirements
Root servers must meet the host requirements listed in [1], and Root servers must meet the host requirements listed in [1], and
operators of other authoritative name servers may also wish to refer operators of other authoritative name servers may also wish to refer
to it for guidance on appropriate practice. In addition to meeting to it for guidance on appropriate practice. In addition to meeting
those requirements, each of the hosts participating in a those requirements, 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. One of the network interfaces should use the shared 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 unicast address associated with the authoritative name server. The
other interface, referred to as the administrative interface below, other interface, referred to as the administrative interface below,
should use a distinct address specific to that host. The host should use a distinct address specific to that host. The host
should respond to DNS queries only on the shared-unicast interface. should respond to DNS queries only on the shared-unicast interface.
Responses on that interface should only relate to zones for which Responses on that interface should only relate to zones for which
the host is authoritative; the host should not be configured as a the host is authoritative; the host should not be configured as a
caching name server. The host should use the administrative caching name server. The host should use the administrative
interface and address for all mesh coordination. 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. 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 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. Authoritative expected part of the current operational environment. Authoritative
name servers may be loosely or tightly synchronized, depending on name servers may be loosely or tightly synchronized, depending on
the practices set by the operating organization. As noted below in the practices set by the operating organization. As noted below in
section 3.1.2, lack of synchronization among servers using the same section 3.1.2, lack of synchronization among servers using the same
shared unicast address could create problems for some users of this shared unicast address could create problems for some users of this
skipping to change at line 135 skipping to change at line 141
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. 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 circumstances. For split-destination failures to occur, the router
traffic must both have equal cost routes to the two different forwarding the traffic must both have equal cost routes to the two
instances and use a load sharing algorithm which does per-packet differentinstances and use a load sharing algorithm which does
rather than per-destination load sharing. per-packet 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 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
skipping to change at line 165 skipping to change at line 171
prefer a server for which this problem does not occur. The root prefer a server for which this problem does not occur. The root
server system distributes the root servers among multiple server system distributes the root servers among multiple
organizations, which automatically mitigates the problem by ensuring organizations, which automatically mitigates the problem by ensuring
that no single AS is announcing all of the salient servers. For 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 set of users affected by per packet load sharing along equal cost a 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. 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 not specific to shared-unicast
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
 End of changes. 

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