Re: 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@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 `-------' --------------------------------------------------------------------
* 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".
we may have a human language problem here. "need not be" means "is allowed but is not required."
* In the MX section, add the following after " ... a lot of trouble.": "Furthermore, it is forbidden by the current RFC documents".
and eliminate the stuff about trouble.
* The PTR section contains a possible mistake - are you sure you can write:
123.45.67.8 IN PTR mail.cust.com.
yes, but only in the in-addr.arpa. zone does it have useful meaning. randy
randy@psg.com (Randy Bush) wrote:
* The PTR section contains a possible mistake - are you sure you can write:
123.45.67.8 IN PTR mail.cust.com.
yes, but only in the in-addr.arpa. zone does it have useful meaning.
Seems like I was fighting with line length limitation here ;-) 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/
> * 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". we may have a human language problem here. "need not be" means "is allowed but is not required." It also means "there's usually no point in having more". Piet
participants (4)
-
Berislav Todorovic -
Elmar K. Bins -
Piet Beertema -
Randy Bush