DNS recommendations - the paper

Randy, thanks for your comments.
I already changed the paper partially according to them...

randy at psg.com (Randy Bush) wrote:

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

Can you provide one? ;-)

> s/netmaster/hostmaster/   see RFC 2142

True.

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

Nobody stops you from having a real hostmaster mailbox (like I have :-) )

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

I've added them although I don't think that anybody really cares...

> > 	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.

Good heavens - I never understood that part (arithmetics...). Can you give an
easy explanation or would the audience think that "beware of possible wrapping"
might suffice here?

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

The originating server need not at all be exposed in one of the NS records as
long as it exists (think of "hidden primary" setups). I don't even know whether
this machine needs to exist (given the RNAME is valid). This is the reason why
I chose "originating". Any other comments on this one? RFC pointers?

> > 		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.

I'm not speaking of aliases here, but of role accounts which may or may not
have real mailboxes. Maybe we should make clear that true mailboxes are
recommended for more failsafe  operation. I've added a paragraph to the SOA
semantics part:

                To ensure reachability even in case of serious DNS and other
                problems, make this address point to a true mailbox, not an
                alias.


> > 	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.

Well you have your satellite dish - maybe it needs cleaning? ;-)
Honest, if you have RETRY set to the appropriate value (let it have
a couple hundred tries) it should work (lest there are broken lines
involved which I always fix by making the zone primary until the
problem is solved...).


> > 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?

It's just the syntax example. If we get a simple running config together it
of course should have two NS records per zone minimum.
Or should we add them here already?

> > 	authoritative server:
> 
> mabe hammer in that cnames are not allowed here.

nailed.

> > 	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.

Thanks for this line. Added ;-)

> > Synopsis
> > 	[<hostname>] [<TTL>] IN A <IPV4 address> [<IPV4 address> ...]
> 
> please do not use the term 'hostname' as it causes great controversy re
> charset.

Hmm. What term would be most appropriate?

> is this syntax legal?  i believe you need
> 
>         www     A 123.45.67.10
>                   123.45.67.11

True and changed (*blush*)

> \340?

Oh, I tried to be french here :-D (a-accent-grave)

> > Synopsis
> > 	<alias> [<TTL>] IN CNAME <hostname>
> 
> again, not 'hostname' please.  i believe that the rdata for a cname is an
> arbitrary domain name.

Hmm. Wouldn't "hostname" help the beginner without confusing the pro?
Otherwise we'd have to define a couple RDATA types...

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

I couldn't come up with an easy explanation of what's possible. The RFC
is not very readable in many places, and the term "owner" sure wouldn't
do good here, would it? Any ideas on how to change this?

> > 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/

Hmm. I took this paragraph from the original. I'm not sure I have understood
what you call "glue" correctly...RFC2181 reads

 "Glue" above includes any record in a zone file that is not properly
 part of that zone, including nameserver records of delegated sub-
 zones (NS records), address records that accompany those NS records
 (A, AAAA, etc), and any other stray data that might appear.


So I took glue for the import interface ;-)

Can anyone come up with a good explanation? (Have me be the experiment
candidate for this ;-) ).



> 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.

Added a bit about this. Reads now:

        Only A-Z/a-z (case does not matter), 0-9 and - are recommended,
        even if a wider character set is in use in certain areas
        (e.g., classless in-addr resolution). If you can do without special
        characters, avoid them.



> i would add rfcs 1982, 2181, 2182.

Added these too.


One for general discussion:

How far should this paper go into detail?
The basic intention was to have a guideline on how to set up stable DNS
servers. The professional should IMHO at one time or another try to
understand the RFCs...

Regards,
	Elmi.

PS: Oh well, to avoid mailing the paper too often, the current version can
    always be found at http://detebe.org/~ekb/dns/recommendations.txt

-- 
  | \  / |\/|  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/