BERI@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@ivm.net) http://www.ivm.net/