DNS recommendations - the paper

great improvement.  but i will make comments if only to cause discussion.

i would also ask what happened to the idea of a concrete simple example?

> 	@ IN SOA ns.isp.net. netmaster.isp.net.
> 	         ( 1998100100 86400 3600 604800 345600 )

s/netmaster/hostmaster/   see RFC 2142

or, i think it was piet who recommended being conservative, and do not
relying on aliases, rather use a real mailbox name.

> Semantics
> 	originating dns server:
> 	dottified admin email:

why not use, or at least refer to, the proper names for the fields, per
1035, MNAME, RNAME, ...?

> 	serial number:
> 		Changed zones are only reloaded if a higher serial number
> 		than the already known one is encountered, so be sure to
> 		increase this number with every change you want to be seen.

and note that 'higher' is in modulo arithmetic as defined in RFC 1982, which
gives cute tricks for 'rolling' in the space.

> 	originating dns server:
> 		As stated above, insert the name of the originating
> 		server that is reachable from the Internet.

s/originating/primary/

> 		Remember: This email address must be valid. So it
> 		seems to be good practice to use a role account address
> 		instead of a personal address - just in case your admin
> 		leaves your company.

this is controversial.  i think it was piet who recommended that it not be
an alias, because when dns is broken, other things like alias resolution may
be broken as well.

> 	expire:
> 		604800 (7 days) is the value used here. [ekb]

ghaque!  i use 30 days.  maybe i am more liberal because i secondary for
a lot of zones in very difficult to reach places.  i think piet recommended
30 days for tlds and 7 for others.  so i guess this is ok, as we're not
talking tlds here.

> Examples
> 	    IN NS ns.isp.net.		; NS for all of the zone's domain
> 	bla IN NS ns.cust.com. 		; subdelegation for bla.<zone>

might it be best if you showed the correct practice of two serverd for each
zone?

> 	authoritative server:
> 		The <authoritative server> given must be the FQDN
> 		for the nameserver machine. Check its correctness in
> 		advance and don't forget the trailing dot.

mabe hammer in that cnames are not allowed here.

> ==============================
> MX	Mail Exchanger Records
> ==============================
> 
> 	preference:
> 		This field is the numerical preference for mail delivery
> 		to the machine mentioned. Lower values are tried first.

while 'preference' is the proper name for the field, it is often called
'cost', the higher the less preferred.

> =======================
> A	Address Records
> =======================
> 
> Synopsis
> 	[<hostname>] [<TTL>] IN A <IPV4 address> [<IPV4 address> ...]

please do not use the term 'hostname' as it causes great controversy re
charset.

> 	www  IN A 123.45.67.10 123.45.67.11	; multiple hardware

is this syntax legal?  i believe you need

        www     A 123.45.67.10
                  123.45.67.11

> Recommendations and remarks
> 		Do not use FQDNs in the <host> part. Hosts in subdomains
> 		\340 la "www.internal", which resolve to "www.internal.<zone>"
> 		are okay though. Remember that IP addresses do not end in
> 		a dot. Do not forget to maintain reverse delegation as well.

\340?

> ==============================
> CNAME	Canonical Name Records
> ==============================
> 
> Synopsis
> 	<alias> [<TTL>] IN CNAME <hostname>

again, not 'hostname' please.  i believe that the rdata for a cname is an
arbitrary domain name.


> Semantics
> 		CNAME records provide a means to give aliases to machines.

not just machines.

> Glue records
> 	"Glue records" is a term that describes entering A records into
> 	a zone for machines whose hostnames do not lie within <zone>.

s/do not/do/

i.e.

    foo.  soa ()

	  ns  bar
	  ns  feen
    bar   a	  666.42.77.11
    feen  a	  147.28.0.42

and it is absolutely critical that you do NOT have glue rrs for names
outside the current zone.  a cute and good sanity check is, a glue rr must
never need a terminating dot on the label.

> Legal characters: 
>       Only A-Z/a-z (case does not matter), 0-9 and - are recommended.
> 	In fact, the full range of 8 bit characters is allowed everywhere
> 	but in hostnames. Yet to be on the secure side, do not use more
> 	than the range mentioned above. Some services may be more restricted
> 	than DNS.

it may be worth noting that conventions in certain areas (classless in-addr,
etc.) use a wider character set.  but when not so needed, it is wise to
avoid special chars.

> Additional reading and references:

i would add rfcs 1982, 2181, 2182.

randy