home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / tcpip / domains / 594 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  4.7 KB
  1. Xref: sparky comp.protocols.tcp-ip.domains:594 comp.unix.admin:4639 comp.mail.sendmail:2124
  2. Newsgroups: comp.protocols.tcp-ip.domains,comp.unix.admin,comp.mail.sendmail
  3. Path: sparky!uunet!psgrain!ee.und.ac.za!daisy.ee.und.ac.za!barrett
  4. From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
  5. Subject: Re: MX record wildcard problem
  6. Message-ID: <1992Aug22.114244.19808@lucy.ee.und.ac.za>
  7. Followup-To: comp.protocols.tcp-ip.domains 
  8. Sender: usenet@lucy.ee.und.ac.za
  9. Nntp-Posting-Host: daisy.ee.und.ac.za
  10. Organization: Univ. Natal, Durban, S. Africa
  11. References: <1992Aug20.170029.4752@progress.com>
  12. Date: Sat, 22 Aug 1992 11:42:44 GMT
  13. Lines: 109
  14.  
  15. [ Followup-To: comp.protocols.tcp-ip.domains ]
  16.  
  17. In article <1992Aug20.170029.4752@progress.com>,
  18. tucker@bedford.progress.COM writes:
  19.  
  20. > @       IN      SOA     progress.com.   tucker.progress.com (
  21.                                                              ^ 
  22. You forgot the trailing dot here.  It's important. ----------^
  23.                         
  24. >         111.111 ;Serial
  25.  
  26. Internally, the SOA serial number is a 32 bit integer.  Some
  27. implementations pretend to allow decimal fractions, but it is better
  28. not to rely on that.  I usually suggest using a format like yyyymmddx,
  29. where yyyymmdd is the date and x is a number from 0 to 9.  If one ever
  30. needs more than 10 revisions in one day, one can borrow from the next
  31. day's allocation.
  32.  
  33. >         10800   ;Refresh
  34. >         3600    ;Retry
  35. >         432000  ;Expire
  36. >         86400 ) ;Minimum
  37. >         IN      NS      progress.com.
  38.  
  39. Only one nameserver?  You will need to have at least two.
  40.  
  41. I see that progress.com does not have an A record, but
  42. progress.progress.com does have an A record.  I suspect one of the
  43. following:
  44.  
  45. a) progress.progress.com and progress.com are indeed two separate systems.
  46.    In which case, add the A record for progress.com.
  47.  
  48. b) progress.progress.com should not exist, and you meant to say
  49.    progress.com instead.  In which case, change the A record from
  50.  
  51.         progress A 192.9.210.4
  52.  
  53.    to
  54.  
  55.         @        A 192.9.210.4
  56.  
  57. c) progress.progress.com should be an alias for progress.com.  In which
  58.    case, change the A record as above, but also add this CNAME record:
  59.  
  60.         progress CNAME @
  61.  
  62.    which, due to the $ORIGIN, really means
  63.  
  64.         progress.progress.com. CNAME progress.com.
  65.  
  66. >         IN      MX      10 pscgate.progress.com.
  67. >         IN      MX      20 ns3.psi.net.
  68.  
  69. OK, this says that mail for user@progress.com should go to pscgate or to
  70. ns3.
  71.  
  72. >  pscgate         IN      A       192.77.186.1
  73. >  introute        IN      A       192.77.186.99
  74. >  progress        IN      A       192.9.210.4
  75. >  tahiti          IN      A       192.9.223.18
  76. >  localhost       IN      A       127.0.0.1
  77.  
  78. In the absence of MX records, mail for users at each of these systems will
  79. be sent directly to the system itself; it will not be sent through pscgate
  80. or ns3.  The effect is (almost) the same as if you had these MX records:
  81.  
  82.     pscgate     MX 0 pscgate
  83.     introute    MX 0 introute
  84.     progress    MX 0 progress
  85.     tahiti      MX 0 tahiti
  86.  
  87. Even if this is what you want, I recommend adding the explicit MX
  88. records rather than relying on the default behaviour.  Adding the explicit
  89. MX records will allow remote hosts to cache the information, whereas
  90. omitting the MX records requires remote hosts to query your nameserver
  91. every time they need the information.  (Unless they do negative caching,
  92. but I am not aware of any nameserver implementations that do that.)
  93.  
  94. >  Mail coming in to progress.com is fine, but I have tried a million
  95. >  combos to add an MX for *.progress.com only to have it fail for
  96. >  all mail.
  97.  
  98. If you add an MX like this:
  99.  
  100.    *.progress.com.      MX      10 pscgate.progress.com.
  101.    *.progress.com.      MX      20 ns3.psi.net.
  102.  
  103. then mail for user@no-such-host.progress.com will be sent to pscgate
  104. or to ns3, but mail for user@tahiti.progress.com will be delivered
  105. directly to tahiti, because wildcards do not match domains that are
  106. also mentioned in non-wildcard records.  When you say that it fails,
  107. do you mean that it does not work like this, or that it does do this
  108. but you were expecting something different?
  109.  
  110. >  All mail is handled by the name server system pscgate and handed off
  111. >  to the system progress which is a non-DNS system.
  112.  
  113. Sorry to be so dense, but I don't understand what you mean here.  Do you
  114. mean "All mail is currently handled by pscgate but I don't want that
  115. to happen" or "I want all mail to be handled by pscgate but that is not
  116. currently happening" or something else?  And what is a "non-DNS system"?
  117.  
  118. It might also help if you explained whether these systems will be
  119. reachable from the Internet.
  120.  
  121. --apb
  122. Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
  123. RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett
  124.