DNS recommendations - the paper
- Previous message (by thread): DNS recommendations - the paper
- Next message (by thread): remove
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elmar K. Bins
ekb at ivm.net
Wed Nov 25 11:18:24 CET 1998
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/
- Previous message (by thread): DNS recommendations - the paper
- Next message (by thread): remove
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]