One document matched: draft-ietf-dnsind-2ndry-01.txt

Differences from draft-ietf-dnsind-2ndry-00.txt

Network Working Group                                         Robert Elz
Internet Draft                                   University of Melbourne
Expiration Date: October 1996
                                                              Randy Bush
                                                             RGnet, Inc.

                                                              April 1996


                   Selection of Secondary DNS Servers


                     draft-ietf-dnsind-2ndry-01.txt

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

1. Abstract

   This draft discusses the selection of secondary servers for DNS
   zones, and related issues.

2. Introduction

   Poor choice of secondary servers for DNS zones seems to currently be
   an endemic problem.  This draft discusses some of the issues, and
   attempts to give some guidance in the matter of the selection of the
   required secondary DNS server(s).








kre/randy                                                       [Page 1]

Internet Draft       draft-ietf-dnsind-2ndry-01.txt           April 1996


3. 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 used to map host names
                          and domains to addresses, mail exchange
                          targets, etc.  Contrasts with Reverse Zone,
                          used to map addresses back 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.












kre/randy                                                       [Page 2]

Internet Draft       draft-ietf-dnsind-2ndry-01.txt           April 1996


4. Secondary Servers

   A prime purpose of secondary servers is to allow information from the
   Domain Name System to be available widely and reliably to clients
   throughout the Internet (that is, throughout the world), even when
   the primary server is unavailable or unreachable.  They can also
   spread the name resolution load, that purpose is not treated further
   here.

   When selecting secondary servers, attention should be given to the
   various likely failure modes, and 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, as they are
   susceptible, together, to being disconnected from the Internet due to
   a single link failure, or a site (or sometimes, building or even
   room) wide power failure.

   Secondary servers should 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.  The should also be connected to
   the net via quite diverse paths, so the failure of any one link, or
   of routing within some segment of the network (such as an ISP) will
   not make all of the servers unreachable.

   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 provided in that configuration is for the case
   when one server is down, whereas there are many other possible
   failure modes.

5. Unreachable servers

   Similarly, listing as a server, or as the address of a server, a name
   or value that cannot be reached from much of the network is
   undesirable.  Not only does such a server add no reliability at all,
   it actually causes the network as a whole (the Internet) problems, as
   the lack of reachability cannot be ascertained other than by
   attempted use and the subsequent lack of response (or occasionally
   ICMP error response).  Further, even that is generally



kre/randy                                                       [Page 3]

Internet Draft       draft-ietf-dnsind-2ndry-01.txt           April 1996


   indistinguishable from a simple packet loss, so the sequence must be
   repeated, several times, to give any real evidence of an unreachable
   server.  Further, the whole thing needs to be repeated from time to
   time to distinguish a permanently unreachable server from a
   temporarily unreachable one.  Worst of all, all this may potentially
   be done by every other DNS server on the Internet.

   To avoid this problem, NS records for a zone returned in any response
   should list only servers that the client requesting the information,
   and others to which it may forward the reply, are likely to be able
   to reach.  Additionally, addresses of the servers returned must all
   be reachable.  As the addresses of each server form a Resource Record
   Set [KRE1996b], 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, which
   disallows 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 clients would be unable to query those servers.  Implementing
   this usually requires dual DNS setups, one for internal use, the
   other for external use.  Such a setup often solves other problems
   with environments like this.

   When a server is at a firewall boundary, reachable from both sides,
   but using different addresses, that server should be given two names,
   each name associated with appropriate A records, such that each
   appears to be reachable only on the appropriate side of the firewall.
   This should then be treated just like two servers, one on each side
   of the firewall.  Special care will need to be taken to allow such a
   server to return the correct responses to clients on each side.

   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.  A similar solution may need to be adopted, though here
   much of the zone information can often be replicated, with only NS
   records being adjusted.

   Servers in this environment often need special provision to give them
   access to the root servers.  Often this is accomplished via "fake
   root" configurations.  In such a case the servers should be kept well
   isolated from the rest of the DNS, lest their unusual configuration
   pollute others.





kre/randy                                                       [Page 4]

Internet Draft       draft-ietf-dnsind-2ndry-01.txt           April 1996


6. How many secondaries?

   The DNS specification requires at least two servers for every zone.
   That is, usually, the primary and one secondary.  While two,
   carefully placed, are usually sufficient, occasions where two are
   insufficient are frequent enough that we advise the use of more than
   two listed servers.  Various problems can cause a server to be
   unavailable for extended periods - during such a period, a zone with
   only two listed servers is actually running with just one.  Since any
   server may occasionally be unavailable, for all kinds of reasons,
   this zone is likely, at times, to have no functional servers at all.

   On the other hand, having large numbers of servers adds little
   benefit, while adding costs.  At the simplest, more servers cause
   packets to be larger, so requiring more bandwidth.  This may seem,
   and realistically is, trivial, however there is a limit to the size
   of a DNS packet, and causing that limit to be reached has more
   serious performance implications.  It is wise to stay well clear of
   it.  More servers also increase both the likelihood that one server
   will be misconfigured, or malfunction, without being detected.

   It is recommended that three servers be provided for most
   organisation level zones, with at least one well removed from the
   others.  For zones where even higher reliability is required, four,
   or even five, servers may be desirable.  Two, or occasionally three
   of five, would be at the local site, with the others not
   geographically or topologically close to the site, or each other.
   Reverse zones, that is, sub-domains of .IN-ADDR.ARPA, tend to be less
   crucial, and less servers, less distributed, will often suffice.

6.1. Stealth Servers

   Servers which are authoritative for the zone, but not listed in NS
   records (also known as "stealth" servers) are not included in the
   count of servers.

   It can often be useful for all servers at a site to be authoritative
   (secondary), but only one or two be listed servers, the rest being
   unlisted for all local zones, that is, to be stealth servers.

   This allows those servers to provide answers to local queries
   directly, without needing to consult another server.  If it were
   necessary to consult another server, it would usually be necessary
   for the root servers to be consulted, in order to follow the
   delegation tree - that the zone is local would not be known.  This
   would mean that some local queries may not be able to be answered if
   external communications were disrupted.




kre/randy                                                       [Page 5]

Internet Draft       draft-ietf-dnsind-2ndry-01.txt           April 1996


   Listing all such servers in NS records, if more than one or two,
   would cause the rest of the Internet to spend unnecessary effort
   attempting to contact all servers at the site when the whole site is
   inaccessible due to link or routing failures.

7. Serial Number Maintenance

   Secondary servers use the serial number in the SOA record of the zone
   to determine when it is necessary to update their local copy of the
   zone.

   Serial numbers are basically just 32 bit unsigned integers that wrap
   around from the biggest possible value to zero again.  See [KRE1996a]
   for a more complete definition of the serial number.

   The serial number must be incremented every time a change, or group
   of changes, is made to the zone on the primary server, in order to
   cause secondary servers to update their copies of the zone.  Note
   that it is not possible to decrement a serial number, increments are
   the only defined modification.

   Occasionally due to editing errors, or other factors, it may be
   necessary to cause a serial number to become smaller.  Do not simply
   decrease the serial number, secondary servers will ignore that
   change, and further, will ignore any further increments until the
   earlier large value is exceeded.

   Instead, given that serial numbers wrap from large to small, in
   absolute terms, increment the serial number, several times, until it
   has reached the value desired.  At each step, wait until all
   secondary servers have updated to the new value before proceeding.

   For example, assume that the serial number of a zone was 10, but has
   accidentally been set to 1000, and it is desired to set it back to
   11.  Do not simply change the value from 1000 to 11, a secondary
   server that has seen the 1000 value (and in practice, there is always
   at least one) will ignore this change, and continue to use the
   version of the zone with serial number 1000, until the primary
   server's serial number exceeds that value.  This may be a long time -
   in fact, the secondary often expires its copy of the zone before the
   zone is ever updated again.

   Instead, for this example, set the primary's serial number to
   2147484647, and wait for the secondary servers to update to that
   zone.  The value 2147484647 is calculated by taking the current
   serial number (1000), adding 2^31 (2147483648) and subtracting 1, and
   taking the result modulo 4294967296 (2^32).  That is by adding
   2^31 - 1 (2147483647), which is the largest defined serial number



kre/randy                                                       [Page 6]

Internet Draft       draft-ietf-dnsind-2ndry-01.txt           April 1996


   increment [KRE1996a].  This value is a serial number that is larger
   than 1000, and further, is the biggest serial number that is larger
   than 1000.  This latter attribute is not essential to the procedure,
   a slightly smaller number could be chosen.

   Next, after all servers needing updating have the zone with that
   serial number, the serial number can be set to 11, as
   2147484647 + 2147483647 is 4294968294, and 4294968294 modulo
   4294967296 is 998, which is bigger than 11.  Hence the change from
   2147484647 to 11 is an increment.

   Note that secondary servers that had not updated to the 1000 version
   of the zone will ignore the first step in this procedure and remain
   with their serial number set at 10, as 2147484647 is more than
   2147483647 bigger than 10, and hence appears as an older version of
   the zone (that is, in serial number arithmetic, 2147484647 < 10,
   whereas 2147484647 > 1000).  Clearly it is neither important, nor
   possible, to wait for those servers to follow this procedure.
   However, the second increment, to 11, will be seen as an increment by
   all servers, which will all update their copies of the zone, and
   hence all be consistent again.

   When following this procedure, it is essential to verify that all
   relevant servers have been updated at each step, never assume
   anything.  Failing to do this can result in a worse mess than existed
   before the attempted correction.  Also beware that it is the
   relationship between the values of the various serial numbers that is
   important, not the absolute values.  The values used above are
   correct for that one example only.

8. Security Considerations

   This document does not consider security.

   The mention of firewalls in section 5 is purely because they are a
   fact of life (and an impediment to orderly communications).  It is
   not intended to imply that a firewall is in any way useful for
   security purposes.

   It is not believed that anything in this document adds to any
   security issues that may exist with the DNS, nor does it do anything
   to lessen them.









kre/randy                                                       [Page 7]

Internet Draft       draft-ietf-dnsind-2ndry-01.txt           April 1996


9. References

   [RFC1034]   Domain Names - Concepts and Facilities,
               P. Mockapetris, ISI, November 1987.

   [RFC1035]   Domain Names - Implementation and Specification,
               P. Mockapetris, ISI, November 1987

   [KRE1996a]  Serial Number Arithmetic,
               R. Elz, R. Bush,
               Work in Progress (internet-draft), April 1996.

   [KRE1996b]  Clarifications to the DNS specification,
               R. Elz, R. Bush,
               Work In Progress (internet-draft), February 1996.

10. Authors' Addresses

   Robert Elz
   Computer Science
   University of Melbourne
   Parkville, Vic,  3052
   Australia.

   EMail: kre@munnari.OZ.AU

   Randy Bush
   RGnet, Inc.
   9501 SW Westhaven
   Portland, Oregon,  97225
   United States.

   EMail: randy@psg.com


















kre/randy                                                       [Page 8]