DNS recommendations - the paper

>> How far should this paper go into detail?

I think it should contain only necessary summary info, with links to RFC's
and other documents useful for DNS setup, where necessary. Some additional
hints and corrections, I found while reading your document:

* In the "Scope:" section add: "This document doesn't replace any DNS
  related RFC or any other good book dealing with DNS. It is a simple
  collection of hints for DNS administrators".

* In the SOA section: parentheses are placed wrongly - instead of:

>>   @ IN SOA ns.isp.net. hostmaster.isp.net.
>>                 ( 1998100100 86400 3600 604800 345600 )

  you should write (both in the syntax block and the example):

>>   @ IN SOA ns.isp.net. hostmaster.isp.net. (
>>                 1998100100 86400 3600 604800 345600 )

  EXPLANATION: parentheses are not a mandatory part of a SOA record - they
  only serve to tell the DNS that rdata is split over multiple lines. In
  other words, you can use them in other records too, e.g.

  www     IN   CNAME (
               server.domain.com. ) ; --- Of course, noone uses this

  as well as you can write the SOA record in one line:

  @ IN SOA ns.isp.net. hostmaster.isp.net. 1998100100 86400 3600 604800 345600

* Regarding "minimum TTL" - higher values make problems with zones that
  change more oftenly, while lower make a lot of unecessary traffic. I
  think the following text should be added to the section on "minimum TTL":

  "Minimum TTL should closely correspond to the average time interval
  between two successive zone contents changes, but not greater than
  345600 (4 days). For example, if the zone is changed almost once or
  twice a day, 86400 (1 day) is a reasonable value. If, however, the
  zone is changed not more than once a week, there is no need to have
  such a small value of minimum TTL".

* In the NS record section - the phrase: "There should be at least two
  of them for every zone," should be updated by: "There need not to be
  more than six servers for a zone".

* In the MX section, add the following after " ... a lot of trouble.":
  "Furthermore, it is forbidden by the current RFC documents".

* In the CNAME section add: "Avoid pointing CNAMEs to other CNAMEs".

* The PTR section contains a possible mistake - are you sure you can write:

>> 123.45.67.8     IN     PTR     mail.cust.com.

  Wouldn't say so - I think you'll get:

  123.45.67.8.67.45.123.in-addr.arpa.   IN   PTR   mail.cust.com.

  EXPLANATION: like all other records, PTR's have record name as the first
  parameter in the record. The server will automatically concatenate the
  reverse domain name if it doesn't find a trailing dot.

  Therefore, I would rewrite the whole section in the following manner:

Synopsis
        <ip-fragment> [<TTL>] IN PTR <hostname> [<hostname> ...]

Examples
        8.67.45.123.in-addr.arpa.        IN PTR mail.cust.com.

Semantics
        PTR records provide the reversed functionality of A records,
        resolving IP addresses to hostnames. <ip-fragment> is the
        reverse written IP address of the host, appended to "in-addr.arpa'.

Recommendations and remarks:
	Don't write whole names of PTR's (8.67.45.123.in-addr.arpa). If
	your inverse domain name is 67.45.123.in-addr.arpa, then use:

	8	IN	PTR	mail.cust.com.

	(copy other recommendations). Add the following:

	"If you're assigned a network less than /24 (former "C class"),
	read RFC 2317 and consult your ISP before you set up your reverse
	zone".

* In the "Legal Characters" section add the following: "Comments in the zone
  file are provided starting with a semicolon ';'. DON'T USE comment
  delimiters used in programming languages or operating system scripts
  (some exapmles of WRONG comment delimiters: #, !, C, /* */, //, { } ...).
  NOTE: this states for the ZONE FILES only! Comment delimiters in the boot
  file may differ (e.g. ';' is used in bind 4 named.boot file, while "//" is
  used in bind 8 named.conf file for comments; zone files, however, use ';'
  in both cases!).

Some hints for future document extensions:

* Forwarders - pro et contra.
* Security - xfer access lists - what to do and what not to do.

Regards,
Beri

.-------.
| --+-- |  Berislav Todorovic, B.Sc.E.E.     | E-mail: BERI at etf.bg.ac.yu
|  /|\     Hostmaster of the YU TLD          | 
|-(-+-)-|  School of Electrical Engineering  | Phone:  (+381-11) 3221-419
|  \|/     Bulevar Revolucije 73             |                   3370-106
| --+-- |  11000 Belgrade SERBIA, YUGOSLAVIA | Fax:    (+381-11) 3248-681
`-------' --------------------------------------------------------------------