home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 98 / Skunkware 98.iso / src / net / bind-contrib.tar.gz / bind-contrib.tar / contrib / dnswalk / TIPS < prev    next >
Encoding:
Text File  |  1996-10-25  |  6.1 KB  |  139 lines
  1.     Here's some tips I've come up with in my months of running
  2. DNS, as well as in development of dnswalk:
  3.  
  4. * Every Internet host should have a name.  Enough said.
  5.  
  6. * Allowable characters in a name are ONLY letters, digits, and
  7.   the '-' character (separated by '.' of course).  Domain names
  8.   may not be all numbers, but may have a leading digit.  (e.g. 3com.com)
  9.   (See RFC 1035 and 1123)
  10.  
  11. * You shouldn't have any A records in an in-addr.arpa zone file.
  12.   This includes NS glue records.  Just put the nameserver name in
  13.   there and be done with it.  Why?  It's unnecessary, and just makes
  14.   things harder when that nameserver changes its IP address.  You'll
  15.   spend hours trying to figure out why random people still see the old
  16.   address for some machine.  BIND 4.9.x handles this better, however.
  17.  
  18. * Verify the data you just entered or changed by querying the
  19.   resolver with 'dig' (or your favorite DNS tool) after a change.  A
  20.   few seconds spent double checking can save hours of trouble, lost
  21.   mail, and headaches.  Also be sure to check syslog output when you
  22.   reload the nameserver.
  23.  
  24. * Don't forget to change the serial number.  Also, even though BIND
  25.   allows you to use a decimal in a serial number, don't use them.  If you
  26.   want to know why, read "DNS & BIND" (see below).
  27.  
  28. * Always remember your $ORIGIN.  If you don't put a '.' at the end
  29.   of an FQDN, it's not an FQDN.  Double check, triple check, those dots.
  30.  
  31. * BE CONSISTENT!  If your $ORIGIN is "foo.org.", don't have entries
  32.   like:
  33.  
  34. tron        in    a    1.2.3.1
  35. mcp.foo.org.    in    a    1.2.3.2
  36.  
  37. or even:
  38.  
  39. mcp        in    a    1.2.3.2
  40.         in    mx    flynn.foo.org.    ; why not just "flynn"?
  41.  
  42. Either use all FQDNs everywhere or used unqualified names everywhere.
  43. Don't mix the two.  It just adds confusion and needless typing.  (Of
  44. course this can't be avoided for RRs of hosts outside $ORIGIN)
  45.  
  46. * Be a good net.neighbor.  Use HINFO records.  Don't believe what you
  47.   hear about the security concerns.  If you're too busy to worry about
  48.   fixing known vendor security holes, then you shouldn't be on the
  49.   Internet.  Don't forget that HINFO _requires_ two tokens, the machine
  50.   type, and the operating system.  BIND won't complain if the second is
  51.   missing, but will result in garbage and will confuse resolvers.
  52.  
  53. * On the other hand, don't use WKS records.  They're useless and obsolete.
  54.  
  55. * Pick friendly, easy to remember hostnames.  "rm5ws3" may tell you
  56.   that it's the 3rd workstation in room 5, but what if you move rm5ws1
  57.   and rm5ws2 to another room?  Also, don't succumb to the "Bond,
  58.   James Bond" naming scheme.  "psuvm.psu.edu" is no more informative
  59.   than "vm.psu.edu".  (Perpetuated by inferior networks like BITNET)
  60.  
  61. * Have a secondary outside your network.  If the secondary isn't under
  62.   your control, periodically check up on them and make sure they're
  63.   properly set up to secondary for you.  (queries to their nameserver
  64.   about your machines should result in an "authoritative" response, etc)
  65.   Use the 'doc' program for this one.
  66.  
  67. * make sure your parent domain has the same NS records for your zone
  68.   as you do.  (Don't forget the in-addr.arpa domain too!).  Use the
  69.   'doc' program if you're not sure how to check.
  70.  
  71. * If a site plans to receive mail, give it an MX record, EVEN IF IT
  72.   POINTS TO ITSELF!  Some mailers will cache MX records, but will
  73.   ALWAYS query to find an MX before sending mail.  If a site does not
  74.   have an MX, then EVERY piece of mail will result in one more resolver
  75.   query.  (most mailers do not implement negative caching)  If you put
  76.   in an MX, then this data can be cached.  (Yes, Virginia, Internet
  77.   SMTP mailers are REQUIRED BY RFCs to support the "MX" mechanism.
  78.   Pound on sites that refuse to comply.)
  79.  
  80. * Wildcard MX's are only useful for non IP-connected sites.  If
  81.   a site has any other records, a wildcard MX won't apply to it.
  82.  
  83. e.g.
  84. *.podunk.edu.        in    mx    mail.podunk.edu.
  85. mary.podunk.edu.    in    A    1.2.3.4
  86.  
  87.   Mail for "mary.podunk.edu" will be sent to mary, while mail for
  88.   "jane.podunk.edu" will be sent to mail.podunk.edu.  Really.
  89.  
  90.   Wildcard MX's can also be quite harmful, because they make some
  91.   operations succeed when they should fail instead.  Consider the case
  92.   where people try to send mail to "joe@larry" over in the accounting
  93.   department of "your.domain.com".  Unfortunately, the host "larry"
  94.   doesn't actually exist anymore, so the address should in fact
  95.   bounce.  But because of domain searching, the address gets resolved
  96.   to larry.your.domain.com, and because of the wildcard MX this is a
  97.   valid address according to DNS.  The mail message then gets routed to
  98.   the mail host, which proceeds to barf with strange error messages
  99.   like "I refuse to talk to myself!" or "Local configuration error!".
  100.  
  101.   Now, it is possible to tweak your mailer configuration to account
  102.   for such problems, but why would you want to?
  103.  
  104. * Wildcards can be used on other RR's too, but are generally a bad
  105.   idea.   They are confusing to users because resolver queries for
  106.   unknown hosts in a wildcarded domain give _emtpy_ responses instead
  107.   of NXDOMAIN.
  108.  
  109.   Wildcard A's and CNAME's are especially confusing to users.  I really
  110.   can't think of a valid reason for wildcard records other than MX.
  111.  
  112. * Don't go overboard with CNAMEs.  Use them when moving/renaming machines,
  113.   but plan to get rid of them.  (And inform your users)  CNAMEs ARE useful
  114.   (and encouraged) for generalized names for servers - "ftp" for your ftp
  115.   server, "www" for your Web server, "gopher" for your gopher server,
  116.   "news" for your news server, etc.
  117.  
  118. * Do NOT use CNAMEs with ANY other data.  Especially do NOT try to do
  119.   the following!:
  120.  
  121.   podunk.edu.    in    ns    mary.podunk.edu.
  122.   podunk.edu.    in    ns    sue.podunk.edu.
  123.   podunk.edu.    in    cname    mary.podunk.edu.
  124.  
  125.   DNS servers like BIND will see the CNAME and refuse to add any
  126.   more records to the zone.  More importantly, since "podunk.edu"
  127.   is now a CNAME only, all the entries under podunk.edu are ignored!
  128.  
  129. * If a host is multi-homed, (more than on A record) make sure that all
  130.   its IP addresses have a corresponding PTR record.  (not just the first
  131.   one)
  132.  
  133. * As more useful RRs come into existence, use them.  (Like TXT, RP, etc).
  134.  
  135. * And of course, above all, use my dnswalk program.  :-)
  136.  
  137. ----
  138.     Dave Barr  <barr@pop.psu.edu>
  139.