home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / domains / 833 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.8 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!agate!garnet.berkeley.edu!cliff
  2. From: cliff@garnet.berkeley.edu (Cliff Frost)
  3. Newsgroups: comp.protocols.tcp-ip.domains
  4. Subject: Re: CNAME records and MX/NS records
  5. Message-ID: <1iv1no$8mb@agate.berkeley.edu>
  6. Date: 12 Jan 93 18:13:12 GMT
  7. References: <1993Jan11.192147.8578@maths.tcd.ie> <1993Jan11.203058.28778@mp.cs.niu.edu> <1isteb$nmc@agate.berkeley.edu> <fn51H7&8_b@atlantis.psu.edu>
  8. Organization: University of California, Berkeley
  9. Lines: 73
  10. NNTP-Posting-Host: garnet.berkeley.edu
  11.  
  12. |> In article <1isteb$nmc@agate.berkeley.edu> I wrote:
  13. |>
  14. |> >It appears reasonable (to me) if you think of providing these services on
  15. |> >multiple hosts, so that if one host goes down hard the other one is still
  16. |> >providing the function.  Eg:
  17. |> >
  18. |> >; sam and mary are identically configured for processing email:
  19. |> >
  20. |> >    sam.foo.bar.    A    1.2.3.4
  21. |> >    mary.foo.bar.    A    1.2.4.4
  22. |> >    mail.foo.bar.    A    1.2.3.4
  23. |> >            A    1.2.4.4
  24.  
  25. This has given some folks headaches or gas or something because it looks
  26. like an attempt to duplicate the function of MX records.  If that were
  27. what we were trying to do it would be gross.  Maybe it's gross anyway,
  28. but at least you should get sick for the right reasons.  ;-)
  29.  
  30. One reason for the A record is that you might want to use the name "mail"
  31. or "mailhost" as the target of some other programs than simply mail.  In
  32. that case you need the A record because you can't have the CNAME record
  33. because you already have the MX record.  You need the MX record rather 
  34. than a CNAME record because if you use a CNAME the sending mailer rewrites
  35. the header to the canonical name rather than the name used.  Why might you
  36. want to preserve the name "mail" or "mailhost" in email headers (rather
  37. than names like "mary" and "sam")?  Think about how long email messages
  38. are preserved and how long names that are programmed into gateway configs
  39. stay around.
  40.  
  41. Another reason is to provide machines which are configured with the
  42. ability to handle a lot of difficult email routing decisions.  This
  43. enables the administrators of several thousand local machines to punt
  44. on the difficult forms of email addresses and send them off to one central
  45. place for handling.  In most cases this could also be handled by MX'ing
  46. the name, but not all (for just one simple example, there are still mail
  47. programs out there which do not support MX records at all--including the
  48. default sendmail from a major Unix vendor).
  49.  
  50. |> >; fred and betsy are running identical authoritative nameservers:
  51. |> >
  52. |> >    fred.foo.bar.    A    1.2.3.5
  53. |> >    betsy.foo.bar.    A    1.2.4.5
  54. |> >    ns.foo.bar.    A    1.2.3.5
  55. |> >            A    1.2.4.5
  56. |> 
  57. |>     Why???  How often do you change your glue records?  Also, your
  58. |> parent domain is going to have to change his IP addresses for the glue
  59. |> records anyway, why confuse things like this?
  60. |> 
  61. |> >From experience we can say it works well for mail and less wonderfully (but
  62. |> >still useful) for nameservice.  The reason it is less useful for nameservice
  63. |> >is the slew of software out there which is configurable for one and only one
  64. |> >nameserver IP address.
  65. |> 
  66. |>     This may be true for stub resolvers, but how many nameservers
  67. |> only look at the first NS record?
  68.  
  69. Ok, I asked for trouble with the incoherencies here.  Sorry, I'll try again...
  70.  
  71. What works less than wonderfully is trying to provide extra reliability to
  72. client resolvers by providing redundant nameservers.  This issue has nothing
  73. to do with what the machines are named, of course.
  74.  
  75. So, why do we find it useful to split out the nameservers' names like this?
  76.  
  77. Well, we did it the second time we found ourselves faced with changing both
  78. the names and addresses of our nameservers.  It turns out that the process
  79. becomes much easier if all you have to do is change or add addresses.  Names
  80. have a greater tendency to get hard configured into nooks and crannies than
  81. IP addresses (although both do).
  82.  
  83.     Cliff Frost
  84.     UC Berkeley
  85.