tips

早期freebsd实现

	Here's some tips I've come up with in my months of running
DNS, as well as in development of dnswalk:

* Every Internet host should have a name.  Enough said.

* You shouldn't have any A records in an in-addr.arpa zone file.
  This includes NS glue records.  Just put the nameserver name in
  there and be done with it.  Why?  It's unnecessary, and just makes
  things harder when that nameserver changes its IP address.  You'll
  spend hours trying to figure out why random people still see the old
  address for some machine.

* Verify the data you just entered or changed by querying the
  resolver with 'dig' (or your favorite DNS tool) after a change.  A
  few seconds spent double checking can save hours of trouble, lost
  mail, and headaches.

* Don't forget to change the serial number.  Also, even though BIND
allows you to use a decimal in a serial number, don't use them.  If you
want to know why, read "DNS & BIND" (see below).

* Always remember your $ORIGIN.  If you don't put a '.' at the end
  of an FQDN, it's not an FQDN.  Double check, triple check, those dots.

* BE CONSISTENT!  If your $ORIGIN is "foo.org.", don't have entries
like:

tron		in	a	1.2.3.1
mcp.foo.org.	in	a	1.2.3.2

or even:

mcp		in	a	1.2.3.2
		in	mx	flynn.foo.org.	; why not just "flynn"?

Either use all FQDNs everywhere or used unqualified names everywhere.
Don't mix the two.  It just adds confusion and needless typing.  (Of
course this can't be avoided for RRs of hosts outside $ORIGIN)

* Be a good net.neighbor.  Use HINFO records.  Don't believe what you
  hear about the security concerns.  If you're too busy to worry about
  fixing known vendor security holes, then you shouldn't be on the
  Internet.  Don't forget that HINFO _requires_ two tokens, the machine
  type, and the operating system.  BIND won't complain if the second is
  missing, but will result in garbage and will confuse resolvers.

* On the other hand, don't use WKS records.  They're useless and obsolete.

* Pick friendly, easy to remember hostnames.  "rm5ws3" may tell you
  that it's the 3rd workstation in room 5, but what if you move rm5ws1
  and rm5ws2 to another room?  Also, don't succumb to the "Bond,
  James Bond" naming scheme.  "psuvm.psu.edu" is no more informative
  than "vm.psu.edu".  (Perpetuated by inferior networks like BITNET)

* Have a secondary outside your network.  If the secondary isn't under
  your control, periodically check up on them and make sure they're
  properly set up to secondary for you.  (queries to their nameserver
  about your machines should result in an "authoritative" response, etc)
  Use the 'doc' program for this one.

* make sure your parent domain has the same NS records (and same order)
  for your zone as you do.  (Don't forget the in-addr.arpa domain
  too!).  Use the 'doc' program if you're not sure how to check.

* If a site plans to receive mail, give it an MX record, EVEN IF IT
  POINTS TO ITSELF!  Some mailers will cache MX records, but will
  ALWAYS query to find an MX before sending mail.  If a site does not
  have an MX, then EVERY piece of mail will result in one more resolver
  query.  (most mailers do not implement negative caching)  If you put
  in an MX, then this data can be cached.  (Yes, Virginia, Internet
  SMTP mailers are REQUIRED BY RFCs to support the "MX" mechanism.
  Pound on sites that refuse to comply.)

* Wildcard MX's are only useful for non IP-connected sites.  If
  a site has any records, a wildcard MX won't apply to it.
e.g.
*.podunk.edu	in	mx	mail.podunk.edu.
mary.podunk.edu	in	A	1.2.3.4

  Mail for "mary.podunk.edu" will be sent to mary, while mail for
  "jane.podunk.edu" will be sent to mail.podunk.edu.

* Don't go overboard with CNAMEs.  Use them when moving/renaming machines,
  but plan to get rid of them.  (And inform your users)

* If a host is multi-homed, (more than on A record) make sure that all
  its IP addresses have a corresponding PTR record.  (not just the first
  one)

* As more useful RRs come into existence, use them.  (Like TXT, RP, etc).

* And of course, above all, use my dnswalk program.  :-)

----
	Dave Barr  <[e-mail]>