>> In particular I'd like to hear opinions concerning the structure, volume and
>> topics covered. The SOA values recommended here are a proposal for the
>> thursday WG meeting.
Personally, I find the contents and structure to be a good skeleton for
future work. Few comments:
>> Now that you have a domain name, a list of secondaries for serving
>> your zone and some address space, you can start constructing a zone.
>> Consult the documentation of your DNS server software for where to
>> start, this document will assist you in filling in the proper values.
I'd add the following text:
Generally speaking, most DNS software packages require two configuration file
sets to operate: boot file and zone files. The boot file (e.g. named.boot in
BIND 4, named.conf in BIND 8) contains the list of domains, being served by
the DNS server, as well as some other necessary global operational parameters.
The zone files contain information about particular domains they represent.
In other words, each domain is represented by a separate zone file.
>> ...
>> DNS zone. For efficiency reasons, serial numbers are compared
>> only. If the serial number at the primary is higher than the
>> secondary's local copy, the zone is copied. (*)
I'd add a footnote here:
(*) To be precise, serial number comaprison is being done using modulo 2^31
arithmetic, i.e. "higher" means "higher modulo 2^31". Please refer to the
RFC 1982 for more details. Also see chapter XXX of RFC 1537 for more details
on one practical implication of such comparison.
>> update their copy. Modern DNS server software will send out
>> additional notifications from the primary to the secondaries upon
>> reload of a modified zoen, so usually the information is
>> distributed much faster than this.
I'd add:
(NOTE - to be able to use this feature, called NOTIFY option [RFC 1996], the
secondary server has to support this feature. BIND 8 supports this feature).
>> The NS RRs tell the world who is able to give out information about
>> your zone. Enter a single NS RR for every server which is intended
>> to provide secondary service for your zone, see the list mentioned
>> earlier. Do not enter random nameservers' names just because you have
>> seen them somewhere. The administrators may not want to deal with
>> that additional load and they may even - as a defense - provide
>> explicit non-service.
Add the following text, for better reference:
(this is oftenly called "lame delegation").
>> the order of NS records is not important
The order of any records is not of any importance - DNS oftenly does its own
record sorting!
Concerning the MX section: I'd put it AFTER the CNAME section. In the MX
section I'd change:
>> 3) The domain name used must directly resolve into an address, which
>> means you must not use an alias name here and an A resource record
>> must exist for that name. Note that unless the name is part of
>> your namespace you must not enter that A record yourself.
Between "alias name" and "here and an ..." insert "(CNAME record)".
>> For domain names in general, no character restrictions apply.
>> Hostnames are restricted to letters (since the DNS is case
I didn't get this clear. Seems to me like two mutually exclusive phrases.
Things to be done:
* Reverse mapping (with references to RIPE-185 (Guide to European LIRs),
RFC 2317 (Classless IN-ADDR.ARPA Delegation)).
* Add a separate chapter, called "DNS Recursion" and explain recursive and
non-recursive mode of operation, forwarder and slave servers. That can
be done in no more than 20 lines.
Generally speaking, you're doing good work! Keep on moving ... ;-)
Regards,
Beri
.-------.
| --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu
| /|\ Hostmaster of the YU TLD |
|-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419
| \|/ Bulevar Revolucije 73 | 3218-350
| --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681
`-------' --------------------------------------------------------------------
