[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

INTERNET-DRAFT                                                Peter Koch
Expires: August 1999                              Universitaet Bielefeld
                                                           February 1999

                   Recommendations for DNS SOA Values
                    draft-koch-dns-soa-values-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Editorial comments should be sent to the author, technical discussion
   is taking place on the RIPE DNS WG mailing list. See
   <http://www.ripe.net/wg/dns/> for details.

Abstract

   The configuration and maintainance of DNS zones offer many degrees of
   freedom and thus several opportunities of making mistakes. Most DNS
   zones today are small and have to be set up and maintained by non-
   experts. This document gives recommendations on which values to use
   for the SOA resource record of small, stable DNS zones to aid novice
   administartors and to contribute to DNS stability end efficiency.

1. Background

   Various DNS surveying activities show that the vast majority of
   today's DNS zones is populated by very few hosts. In most cases there
   is only an HTTP server announced under the common name "www",
   sometimes accompanied by distinct mail or DNS servers or a bastion



Koch                      Expires August 1999                   [Page 1]


INTERNET-DRAFT                 SOA Values                  February 1999


   host. For many of these zones the configuration is touched once when
   it is set up and then left alone without modification for a long
   time.

   These recommendations are aimed at small and stable DNS zones. There
   are many legitimate reasons to use different values, e.g. proposed
   changes or special purpose applications. Administrators of those
   zones should consult one of the various more detailed DNS guidelines
   or books.

   ISPs and DNS server vendors are encouraged to use this information
   for their customers [draft: once it has settled].

   For more information about initial name server setup and zone
   configuration see [DNSGUIDE1], [DNSGUIDE2].

2. Recommended SOA Values

   example.com.  3600  SOA  dns.example.com. hostmaster.example.com. (
                            1999022301   ; serial YYYYMMDDnn
                            86400        ; refresh (24 hours)
                            7200         ; retry (2 hours)
                            3600000      ; expire (1000 hours)
                            172800 )     ; minimum (2 days)

3. Remarks and Explanation

3.1. The MNAME Value

   The DNS specification explicitly states that the primary master
   server be named here. The value must be determined and used.
   Especially it is a mistake to repeat the zone name here, unless this
   also leads to a valid address of the primary master.

3.2. The RNAME Value

   The RNAME is to publish a mail address of a person or role account
   dealing with this zone with the "@" converted to a ".".

   The best practice is to define (and maintain) a dedicated mail alias
   "hostmaster" [RFC2142] for DNS operations.

3.3. The Serial Number

   The most imporatnt issue is that this value be incremented after any
   modification to the zone data. For debugging purposes it has shown to
   be helpful to encode the modification date into the serial number.
   The value "1999022301" so is an example of the YYYYMMDDnn scheme and



Koch                      Expires August 1999                   [Page 2]


INTERNET-DRAFT                 SOA Values                  February 1999


   must be replaced by proper values for the year (YYYY, four digits),
   month (MM, two digits), day of month (DD, two digits) and version per
   day (nn, two digits). The first version of the day should have the
   value "01".  It is important to preserve the order year - month -
   day.

3.4. The Refresh and Retry Values

   The refresh and retry values primarily affect the zone maintainer and
   the secondary service providers and may be negotiated between them.
   The values chosen here are aimed at scalability. Modern DNS software
   implements NOTIFY and reduces the need for frequent SOA checks, as
   does the assumption of stability of the zone.  While lower values
   would only slightly increase the bandwidth usage, they would increase
   the load on the secondary servers serving thousands of zones.

3.5. The Expire Value

   The primary goal is to ensure stability of the zone data, even if a
   mistake invalidating (non-authorizing) the zone or network outage
   last for several days. A value of a week or two has proven to be way
   too short, so a longer time must be used. The specific value was
   chosen for aesthetic and historic reasons and to disambiguate between
   the different proposed values of "long".

3.6. The Minimum TTL Value

   There are two meanings for this value with practical relevance.
   First, it serves as a default value for the TTL of all RRs without a
   given value.  To be cache-friendly this value was chosen to be two
   days, which also follows the stability assumption. The second meaning
   is the default negative TTL [RFC2309], which would call for a lower
   value. We are in a transition phase now with software implementing
   either of both meanings, so the TTL of one hour is recommended for
   the SOA itself, which will lead to nearly the same effect.

4. Security Considerations

   Filling in the recommended values will not directly influence
   security of the name servers for the particular zone, any system with
   a name in that zone or any other system in the Internet. However,
   following these guidelines will likely contribute to DNS stability
   and thus to reachability.

   Maintaining proper contact information in the SOA RNAME field helps
   people in reporting problems, although the address distributed there
   is not recommended as a primary security contact.




Koch                      Expires August 1999                   [Page 3]


INTERNET-DRAFT                 SOA Values                  February 1999


5. Acknowledgements

   This work is a product of the RIPE DNS working group.

6. References


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

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

   [RFC1123]     Braden,R., "Requirements for Internet Hosts -- Application
                 and Support", RFC 1123, STD 3, October 1989

   [RFC2142]     Crocker,D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
                 FUNCTIONS", RFC 2142, May 1997

   [RFC2309]     Andrews,M., "Negative Caching of DNS Queries (DNS
                 NCACHE)", RFC 2309, March 1998

   [DNSGUIDE1]   Liman,L., "SIMPLE DNS CONFIGURATION EXAMPLE", work in pro-
                 gress

   [DNSGUIDE2]   Koch,P., "RIPE Guide To Setting Up a DNS Server", work in
                 progress



7. Author's Address

   Peter Koch
   Universitaet Bielefeld
   Technische Fakultaet
   Postfach 10 01 31
   D-33501 Bielefeld
   Germany
   +49 521 106 2902
   <pk@TechFak.Uni-Bielefeld.DE>











Koch                      Expires August 1999                   [Page 4]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/