rfc2182.txt

RFC 的详细文档！

Network Working Group                                             R. Elz
Request for Comments: 2182                       University of Melbourne
BCP: 16                                                          R. Bush
Category: Best Current Practice                              RGnet, Inc.
                                                              S. Bradner
                                                      Harvard University
                                                               M. Patton
                                                              Consultant
                                                               July 1997


            Selection and Operation of Secondary DNS Servers

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Abstract

   The Domain Name System requires that multiple servers exist for every
   delegated domain (zone).  This document discusses the selection of
   secondary servers for DNS zones.  Both the physical and topological
   location of each server are material considerations when selecting
   secondary servers.  The number of servers appropriate for a zone is
   also discussed, and some general secondary server maintenance issues
   considered.























Elz, et al.              Best Current Practice                  [Page 1]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997




Contents

       Abstract  ...................................................   1
    1  Introduction  ...............................................   2
    2  Definitions  ................................................   2
    3  Secondary Servers  ..........................................   3
    4  Unreachable servers  ........................................   5
    5  How many secondaries?  ......................................   7
    6  Finding Suitable Secondary Servers  .........................   8
    7  Serial Number Maintenance  ..................................   9
       Security Considerations  ....................................  11
       References  .................................................  11
       Acknowledgements  ...........................................  11
       Authors' Addresses  .........................................  11




1. Introduction

   A number of problems in DNS operations today are attributable to poor
   choices of secondary servers for DNS zones.  The geographic placement
   as well as the diversity of network connectivity exhibited by the set
   of DNS servers for a zone can increase the reliability of that zone
   as well as improve overall network performance and access
   characteristics.  Other considerations in server choice can
   unexpectedly lower reliability or impose extra demands on the
   network.

   This document discusses many of the issues that should be considered
   when selecting secondary servers for a zone.  It offers guidance in
   how to best choose servers to serve a given zone.

2. Definitions

   For the purposes of this document, and only this document, the
   following definitions apply:

   DNS                    The Domain Name System [RFC1034, RFC1035].

   Zone                   A part of the DNS tree, that is treated as a
                          unit.

   Forward Zone           A zone containing data mapping names to host
                          addresses, mail exchange targets, etc.




Elz, et al.              Best Current Practice                  [Page 2]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   Reverse Zone           A zone containing data used to map addresses
                          to names.

   Server                 An implementation of the DNS protocols able to
                          provide answers to queries.  Answers may be
                          from information known by the server, or
                          information obtained from another server.

   Authoritative Server   A server that knows the content of a DNS zone
                          from local knowledge, and thus can answer
                          queries about that zone without needing to
                          query other servers.

   Listed Server          An Authoritative Server for which there is an
                          "NS" resource record (RR) in the zone.

   Primary Server         An authoritative server for which the zone
                          information is locally configured.  Sometimes
                          known as a Master server.

   Secondary Server       An authoritative server that obtains
                          information about a zone from a Primary Server
                          via a zone transfer mechanism.  Sometimes
                          known as a Slave Server.

   Stealth Server         An authoritative server, usually secondary,
                          which is not a Listed Server.

   Resolver               A client of the DNS which seeks information
                          contained in a zone using the DNS protocols.

3. Secondary Servers

   A major reason for having multiple servers for each zone is to allow
   information from the zone to be available widely and reliably to
   clients throughout the Internet, that is, throughout the world, even
   when one server is unavailable or unreachable.

   Multiple servers also spread the name resolution load, and improve
   the overall efficiency of the system by placing servers nearer to the
   resolvers.  Those purposes are not treated further here.

   With multiple servers, usually one server will be the primary server,
   and others will be secondary servers.  Note that while some unusual
   configurations use multiple primary servers, that can result in data
   inconsistencies, and is not advisable.





Elz, et al.              Best Current Practice                  [Page 3]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   The distinction between primary and secondary servers is relevant
   only to the servers for the zone concerned, to the rest of the DNS
   there are simply multiple servers.  All are treated equally at first
   instance, even by the parent server that delegates the zone.
   Resolvers often measure the performance of the various servers,
   choose the "best", for some definition of best, and prefer that one
   for most queries.  That is automatic, and not considered here.

   The primary server holds the master copy of the zone file.  That is,
   the server where the data is entered into the DNS from some source
   outside the DNS.  Secondary servers obtain data for the zone using
   DNS protocol mechanisms to obtain the zone from the primary server.

3.1. Selecting Secondary Servers

   When selecting secondary servers, attention should be given to the
   various likely failure modes.  Servers should be placed so that it is
   likely that at least one server will be available to all significant
   parts of the Internet, for any likely failure.

   Consequently, placing all servers at the local site, while easy to
   arrange, and easy to manage, is not a good policy.  Should a single
   link fail, or there be a site, or perhaps even building, or room,
   power failure, such a configuration can lead to all servers being
   disconnected from the Internet.

   Secondary servers must be placed at both topologically and
   geographically dispersed locations on the Internet, to minimise the
   likelihood of a single failure disabling all of them.

   That is, secondary servers should be at geographically distant
   locations, so it is unlikely that events like power loss, etc, will
   disrupt all of them simultaneously.  They should also be connected to
   the net via quite diverse paths.  This means that the failure of any
   one link, or of routing within some segment of the network (such as a
   service provider) will not make all of the servers unreachable.

3.2. Unsuitable Configurations

   While it is unfortunately quite common, servers for a zone should
   certainly not all be placed on the same LAN segment in the same room
   of the same building - or any of those.  Such a configuration almost
   defeats the requirement, and utility, of having multiple servers.
   The only redundancy usually provided in that configuration is for the
   case when one server is down, whereas there are many other possible
   failure modes, such as power failures, including lengthy ones, to
   consider.




Elz, et al.              Best Current Practice                  [Page 4]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


3.3. A Myth Exploded

   An argument is occasionally made that there is no need for the domain
   name servers for a domain to be accessible if the hosts in the domain
   are unreachable.  This argument is fallacious.

     + Clients react differently to inability to resolve than inability
       to connect, and reactions to the former are not always as
       desirable.
     + If the zone is resolvable yet the particular name is not, then a
       client can discard the transaction rather than retrying and
       creating undesirable load on the network.
     + While positive DNS results are usually cached, the lack of a
       result is not cached.  Thus, unnecessary inability to resolve
       creates an undesirable load on the net.
     + All names in the zone may not resolve to addresses within the
       detached network.  This becomes more likely over time.  Thus a
       basic assumption of the myth often becomes untrue.

   It is important that there be nameservers able to be queried,
   available always, for all forward zones.

4. Unreachable servers

   Another class of problems is caused by listing servers that cannot be
   reached from large parts of the network.  This could be listing the
   name of a machine that is completely isolated behind a firewall, or
   just a secondary address on a dual homed machine which is not
   accessible from outside.  The names of servers listed in NS records
   should resolve to addresses which are reachable from the region to
   which the NS records are being returned.  Including addresses which
   most of the network cannot reach does not add any reliability, and
   causes several problems, which may, in the end, lower the reliability
   of the zone.

   First, the only way the resolvers can determine that these addresses
   are, in fact, unreachable, is to try them.  They then need to wait on
   a lack of response timeout (or occasionally an ICMP error response)
   to know that the address cannot be used.  Further, even that is
   generally indistinguishable from a simple packet loss, so the
   sequence must be repeated, several times, to give any real evidence
   of an unreachable server.  All of this probing and timeout may take
   sufficiently long that the original client program or user will
   decide that no answer is available, leading to an apparent failure of
   the zone.  Additionally, the whole thing needs to be repeated from
   time to time to distinguish a permanently unreachable server from a
   temporarily unreachable one.




Elz, et al.              Best Current Practice                  [Page 5]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   And finally, all these steps will potentially need to be done by
   resolvers all over the network.  This will increase the traffic, and
   probably the load on the filters at whatever firewall is blocking
   this access.  All of this additional load does no more than
   effectively lower the reliability of the service.

4.1. Servers behind intermittent connections

   A similar problem occurs with DNS servers located in parts of the net
   that are often disconnected from the Internet as a whole.  For
   example, those which connect via an intermittent connection that is
   often down.  Such servers should usually be treated as if they were
   behind a firewall, and unreachable to the network at any time.

4.2. Other problem cases

   Similar problems occur when a Network Address Translator (NAT)
   [RFC1631] exists between a resolver and server.  Despite what
   [RFC1631] suggests, NATs in practice do not translate addresses
   embedded in packets, only those in the headers.  As [RFC1631]
   suggests, this is somewhat of a problem for the DNS.  This can
   sometimes be overcome if the NAT is accompanied by, or replaced with,
   an Application Layer Gateway (ALG).  Such a device would understand
   the DNS protocol and translate all the addresses as appropriate as
   packets pass through.  Even with such a device, it is likely to be
   better in any of these cases to adopt the solution described in the
   following section.

4.3. A Solution

   To avoid these problems, NS records for a zone returned in any
   response should list only servers that the resolver requesting the
   information, is likely to be able to reach.  Some resolvers are
   simultaneously servers performing lookups on behalf of other
   resolvers.  The NS records returned should be reachable not only by
   the resolver that requested the information, but any other resolver
   that may be forwarded the information.  All the addresses of all the
   servers returned must be reachable.  As the addresses of each server
   form a Resource Record Set [RFC2181], all must be returned (or none),
   thus it is not acceptable to elide addresses of servers that are
   unreachable, or to return them with a low TTL (while returning others
   with a higher TTL).

   In particular, when some servers are behind a firewall, intermittent
   connection, or NAT, which disallows, or has problems with, DNS
   queries or responses, their names, or addresses, should not be
   returned to clients outside the firewall.  Similarly, servers outside
   the firewall should not be made known to clients inside it, if the



Elz, et al.              Best Current Practice                  [Page 6]