home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / domains / 826 < prev    next >
Encoding:
Text File  |  1993-01-11  |  2.8 KB  |  70 lines
  1. Newsgroups: comp.protocols.tcp-ip.domains
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!ux1.cso.uiuc.edu!mp.cs.niu.edu!rickert
  3. From: rickert@mp.cs.niu.edu (Neil Rickert)
  4. Subject: Re: CNAME records and MX/NS records
  5. Message-ID: <1993Jan11.203058.28778@mp.cs.niu.edu>
  6. Organization: Northern Illinois University
  7. References: <1993Jan11.192147.8578@maths.tcd.ie>
  8. Date: Mon, 11 Jan 1993 20:30:58 GMT
  9. Lines: 59
  10.  
  11. In article <1993Jan11.192147.8578@maths.tcd.ie> ajudge@maths.tcd.ie (Alan Judge) writes:
  12. >Am I correct in saying that the data in an MX or NS record may not
  13. >be a CNAME, so that
  14. >    foo.bar.        MX    mail.foo.bar.
  15. >    mail.foo.bar.        CNAME    realhost.foo.bar.
  16. >    (and similarly for ns.foo.bar.)
  17. >is incorrect?
  18.  
  19. Yes.  This is incorrect.
  20.  
  21. >If so, what do people do when they want a nice logical separation
  22. >between services and hosts.
  23.  
  24. The MX record should give you all the separation you need.  A user mails
  25. to 'user@foo.bar' and the mail gets to 'realhost.foo.bar'.  Why do you
  26. need any more separation than that?  Why is it easier to change a CNAME
  27. record in your DNS than to change an MX record?  The change is still
  28. the same in that it takes place in your local DNS data.  If you want
  29. more levels of separation you should be able to use M4 macros to generate
  30. all of your DNS data, and then hide whatever you want behind the M4
  31. macros.
  32.  
  33. >                             Is it permissible/reasonable to have
  34. >multiple A records for a single IP address?
  35.  
  36. It is permissible, and often done.  But this is unwise for dealing with
  37. MX records.  At certain stages of processing, your mail software needs
  38. to know if the MX record is pointing to itself.  It typically determines
  39. this by a case-insensitive string comparison of its own hostname and
  40. the hostname on the MX record.  You are apparently trying to defeat this
  41. mechanism, possibly resulting in mishandling of mail.
  42.  
  43. >                                             Will anything get
  44. >upset that a reverse lookup does not return the same name?
  45.  
  46. Probably not.  There is some software which follows a reverse lookup with
  47. a forward lookup and cross checks.  But there is little if any which uses
  48. the reverse lookup as a cross check on the forward lookup.
  49.  
  50. >Specifically, is something like
  51. >    foo.bar.    MX    mail.foo.bar.
  52. >    foo.bar.    NS    ns.foo.bar.
  53. >
  54. >    mail.foo.bar.        A    1.2.3.4
  55. >    realname.foo.bar.    A    1.2.3.4
  56. >
  57. >    ns.foo.bar.        A    1.2.3.5
  58. >    fred.foo.bar.        A    1.2.3.5
  59. >
  60. >a reasonable and sane thing to do.
  61.  
  62. This is permissible.  I won't comment on whether it is sane, but it
  63. surely does not seem reasonable.  It sometimes makes sense to "hide"
  64. the real name of a host from human users, so that configuration changes
  65. can be done with a minimum of effort.  But you are "hiding" real names
  66. from software which still needs to know those real names, so that if
  67. you ever change the names you need to the do appropriate configuration
  68. updates anyway.  I fail to see the purpose.
  69.  
  70.