draft-ietf-dnsop-hardie-shared-root-server-03.txt   draft-ietf-dnsop-hardie-shared-root-server-04.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 January, 2001 Category: Work-in-progress March, 2001
draft-ietf-dnsop-hardie-shared-root-server-03.txt draft-ietf-dnsop-hardie-shared-root-server-04.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 46 skipping to change at line 46
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. name servers. The shared unicast system described here is specific
to IPv4; IPv6 uses anycast differently from IPv4 and those
differences prevent this system from being used in IPv6
environments.
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 [1] and
[2] for general guidance on appropriate practice for authoritative [2] for general guidance on appropriate practice for authoritative
name servers. In addition to proper configuration as a standard name servers. In addition to proper configuration as a standard
authoritative name server, 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. One of or one physical interface mapped to two logical interfaces. One of
the network interfaces should use the shared unicast address the network interfaces should use the IPv4 shared unicast address
associated with the authoritative name server. The other interface, associated with the authoritative name server. The other interface,
referred to as the administrative interface below, should use a referred to as the administrative interface below, should use a
distinct address specific to that host. The host should respond to distinct IPv4 address specific to that host. The host should
DNS queries only on the shared-unicast interface. In order to respond to DNS queries only on the shared-unicast interface. In
provide the most consistent set of responses from the mesh of order to provide the most consistent set of responses from the mesh
anycast hosts, it is good practice to limit responses on that of anycast hosts, it is good practice to limit responses on that
interface to zones for which the host is authoritative. 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
 End of changes. 

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