datatracker.ietf.org
Sign in
Version 5.7.1.p2, 2014-10-29
Report a bug

Distributing Authoritative Name Servers via Shared Unicast Addresses
RFC 3258

Document type: RFC - Informational (April 2002; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

This information refers to IESG processing after the RFC was initially published:
IESG State: RFC 3258 (Informational)
Responsible AD: Randy Bush
IESG Note: Responsible: Finished
Send notices to: <dmm@1-4-5.net>, <sra@hactrn.net>

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]

[include full document text]