rfc2182.txt

RFC 的详细文档！


RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997


   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.  A server implemented in an ALG will usually be such
   a case.  Special care will need to be taken to allow such a server to
   return the correct responses to clients on each side.  That is,
   return only information about hosts reachable from that side and the
   correct IP address(es) for the host when viewed from that side.

   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.

5. How many secondaries?

   The DNS specification and domain name registration rules require at
   least two servers for every zone.  That is, usually, the primary and
   one secondary.  While two, carefully placed, are often 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 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 which must be well
   removed from the others.  For zones where even higher reliability is
   required, four, or even five, servers may be desirable.  Two, or



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


   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.
   This is because address to name translations are typically needed
   only when packets are being received from the address in question,
   and only by resolvers at or near the destination of the packets.
   This gives some assurances that servers located at or near the packet
   source, for example, on the the same network, will be reachable from
   the resolvers that need to perform the lookups.  Thus some of the
   failure modes that need to be considered when planning servers for
   forward zones may be less relevant when reverse zones are being
   planned.

5.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 servers 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.

   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.

6. Finding Suitable Secondary Servers

   Operating a secondary server is usually an almost automatic task.
   Once established, the server generally runs itself, based upon the
   actions of the primary server.  Because of this, large numbers of
   organisations are willing to provide a secondary server, if
   requested.  The best approach is usually to find an organisation of
   similar size, and agree to swap secondary zones - each organisation
   agrees to provide a server to act as a secondary server for the other



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


   organisation's zones.  Note that there is no loss of confidential
   data here, the data set exchanged would be available publically
   whatever the servers are.

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
   [RFC1982] for a more rigorous 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.  This informs
   secondary servers they need 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.  Never simply
   decrease the serial number.  Secondary servers will ignore that
   change, and further, will ignore any later 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
   2000000000, and wait for the secondary servers to update to that
   zone.  The value 2000000000 is chosen as a value a lot bigger than
   the current value, but less that 2^31 bigger (2^31 is 2147483648).
   This is then an increment of the serial number [RFC1982].

   Next, after all servers needing updating have the zone with that
   serial number, the serial number can be set to 4000000000.
   4000000000 is 2000000000 more than 2000000000 (fairly clearly), and



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


   is thus another increment (the value added is less than 2^31).

   Once this copy of the zone file exists at all servers, the serial
   number can simply be set to 11.  In serial number arithmetic, a
   change from 4000000000 to 11 is an increment.  Serial numbers wrap at
   2^32 (4294967296), so 11 is identical to 4294967307 (4294967296 +
    11).  4294967307 is just 294967307 greater than 4000000000, and
   294967307 is well under 2^31, this is therefore an increment.

   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.

   It is possible in essentially all cases to correct the serial number
   in two steps by being more aggressive in the choices of the serial
   numbers.  This however causes the numbers used to be less "nice", and
   requires considerably more care.

   Also, note that not all nameserver implementations correctly
   implement serial number operations.  With such servers as secondaries
   there is typically no way to cause the serial number to become
   smaller, other than contacting the administrator of the server and
   requesting that all existing data for the zone be purged.  Then that
   the secondary be loaded again from the primary, as if for the first
   time.

   It remains safe to carry out the above procedure, as the
   malfunctioning servers will need manual attention in any case.  After
   the sequence of serial number changes described above, conforming
   secondary servers will have been reset.  Then when the primary server
   has the correct (desired) serial number, contact the remaining
   secondary servers and request their understanding of the correct
   serial number be manually corrected.  Perhaps also suggest that they
   upgrade their software to a standards conforming implementation.

   A server which does not implement this algorithm is defective, and
   may be detected as follows.  At some stage, usually when the absolute
   integral value of the serial number becomes smaller, a server with
   this particular defect will ignore the change.  Servers with this
   type of defect can be detected by waiting for at least the time
   specified in the SOA refresh field and then sending a query for the
   SOA.  Servers with this defect will still have the old serial number.
   We are not aware of other means to detect this defect.




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


Security Considerations

   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.

   Administrators should be aware, however, that compromise of a server
   for a domain can, in some situations, compromise the security of
   hosts in the domain.  Care should be taken in choosing secondary
   servers so that this threat is minimised.

References

   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
               STD 13, RFC 1034, November 1987.

   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
               Specification", STD 13, RFC 1035, November 1987

   [RFC1631]   Egevang, K., Francis, P., "The IP Network Address Translator
               (NAT)", RFC 1631, May 1994

   [RFC1982]   Elz, R., Bush, R., "Serial Number Arithmetic",
               RFC 1982, August 1996.

   [RFC2181]   Elz, R., Bush, R., "Clarifications to the DNS specification",
               RFC 2181, July 1997.

Acknowledgements

   Brian Carpenter and Yakov Rekhter suggested mentioning NATs and ALGs
   as a companion to the firewall text.  Dave Crocker suggested
   explicitly exploding the myth.

Authors' Addresses

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

   EMail: [e-mail]








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


   Randy Bush
   RGnet, Inc.
   5147 Crystal Springs Drive NE
   Bainbridge Island, Washington,  98110
   United States.

   EMail: [e-mail]

   Scott Bradner
   Harvard University
   1350 Mass Ave
   Cambridge, MA,  02138
   United States.

   EMail: [e-mail]

   Michael A. Patton
   33 Blanchard Road
   Cambridge, MA,  02138
   United States.

   EMail: [e-mail]





























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