DNS recommendations - the paper

BERI at etf.bg.ac.yu (Berislav Todorovic) wrote:

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

agreed.

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

True. Corrected.

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

I've added the explanation as well.

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

I like this explanation, so I added it.

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

I cannot second that. People tend more to have fewer NS servers than they
are about to add more than six. Maybe both statements should be included
here. I see no danger from more than six servers but I do see trouble
brewing if you only have one (which, btw, no NIC will accept).

I've added the part about "more than six".

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

Added them and removed the part about "trouble" in the MX section.

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

Yes, I think this is true. Problem is, this is not a real-life example.
My zones only contain something like
" 8	IN PTR	mail.cust.com."
since they are loaded as zones for (e.g.) 67.45.123.in-addr.arpa.

Maybe we should really complete the example as shown above (thanks, that was not
my own example, so I overlooked it).

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

Ah, you're addressing the drive-my-own-server customer here. Ok :-)
But I guess we need not go into the details of classless reverse delegation...

> * In the "Legal Characters" section add the following: "Comments in the zone

added (more briefly though)

> Some hints for future document extensions:
> 
> * Forwarders - pro et contra.
> * Security - xfer access lists - what to do and what not to do.

This concerns bind operation, not zones ;-)
If somebody wants to set up recommendations for this I'd be happy to read...

Regards,
	Elmi.

-- 
  | \  / |\/|  Gesellschaft fuer Internet, Vernetzung und Mehrwertdienste mbH
  |  \/  |  |  Zissener Str. 8 - D-53498 Waldorf - +49 2636 9769-0 - Fax -999

 The Net People.       Elmar K. Bins (ekb at ivm.net)        http://www.ivm.net/