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@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 `-------' --------------------------------------------------------------------