Network Working Group T. Hardie
Request for Comments: 3258 Nominum, Inc.
Category: Informational April 2002
Distributing Authoritative Name Servers via Shared Unicast Addresses
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo describes a set of practices intended to enable an
authoritative name server operator to provide access to a single
named server in multiple locations. The primary motivation for the
development and deployment of these practices is to increase the
distribution of Domain Name System (DNS) servers to previously
under-served areas of the network topology and to reduce the latency
for DNS query responses in those areas.
1. Introduction
This memo describes a set of practices intended to enable an
authoritative name server operator to provide access to a single
named server in multiple locations. The primary motivation for the
development and deployment of these practices is to increase the
distribution of DNS 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. The shared unicast system described here is specific
to IPv4; applicability to IPv6 is an area for further study. It
should also be noted that the system described here is related to
that described in [ANYCAST], but it does not require dedicated
address space, routing changes, or the other elements of a full
anycast infrastructure which that document describes.
Hardie Informational [Page 1]
RFC 3258 Distributing Authoritative Name Servers April 2002
2. Architecture
2.1 Server Requirements
Operators of authoritative name servers may wish to refer to
[SECONDARY] and [ROOT] for general guidance on appropriate practice
for authoritative name servers. In addition to proper configuration
as a standard authoritative name server, each of the hosts
participating in a shared-unicast system should be configured with
two network 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 IPv4 shared
unicast address associated with the authoritative name server. The
other interface, referred to as the administrative interface below,
should use a distinct IPv4 address specific to that host. The host
should respond to DNS queries only on the shared-unicast interface.
In order to provide the most consistent 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 authoritative.
2.2 Zone file delivery
In order to minimize the risk of man-in-the-middle attacks, zone
files should be delivered to the administrative interface of the
servers participating in the mesh. Secure file transfer methods and
strong authentication should be used for all transfers. If the hosts
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 the problems with potential routing changes for TCP
traffic noted in section 2.5 below.
2.3 Synchronization
Authoritative name servers may be loosely or tightly synchronized,
depending on the practices set by the operating organization. As
noted below in section 4.1.2, lack of synchronization among servers
using the same shared unicast address could create problems for some
users of this service. In order to minimize that risk, switch-overs
from one data set to another data set should be coordinated as much
as possible. 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
b) confirmation of the integrity of zones received
c) distribution of the zones to all of the servers in the mesh
d) confirmation of the integrity of the zones at each server
Hardie Informational [Page 2]
datatracker.ietf.org