From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Subject: Re: MX record wildcard problem
Followup-To: comp.protocols.tcp-ip.domains 
Organization: Univ. Natal, Durban, S. Africa
Date: Sat, 22 Aug 1992 11:42:44 GMT

[ Followup-To: comp.protocols.tcp-ip.domains ]

In article <1992Aug20.170029.4752@progress.com>,
tucker@bedford.progress.COM writes:

> @       IN      SOA     progress.com.   tucker.progress.com (
                                                             ^ 
You forgot the trailing dot here.  It's important. ----------^
                        
>         111.111 ;Serial

Internally, the SOA serial number is a 32 bit integer.  Some
implementations pretend to allow decimal fractions, but it is better
not to rely on that.  I usually suggest using a format like yyyymmddx,
where yyyymmdd is the date and x is a number from 0 to 9.  If one ever
needs more than 10 revisions in one day, one can borrow from the next
day's allocation.

>         10800   ;Refresh
>         3600    ;Retry
>         432000  ;Expire
>         86400 ) ;Minimum
>         IN      NS      progress.com.

Only one nameserver?  You will need to have at least two.

I see that progress.com does not have an A record, but
progress.progress.com does have an A record.  I suspect one of the
following:

a) progress.progress.com and progress.com are indeed two separate systems.
   In which case, add the A record for progress.com.

b) progress.progress.com should not exist, and you meant to say
   progress.com instead.  In which case, change the A record from

        progress A 192.9.210.4

   to

        @        A 192.9.210.4

c) progress.progress.com should be an alias for progress.com.  In which
   case, change the A record as above, but also add this CNAME record:

        progress CNAME @

   which, due to the $ORIGIN, really means

        progress.progress.com. CNAME progress.com.

>         IN      MX      10 pscgate.progress.com.
>         IN      MX      20 ns3.psi.net.

OK, this says that mail for user@progress.com should go to pscgate or to
ns3.

>  pscgate         IN      A       192.77.186.1
>  introute        IN      A       192.77.186.99
>  progress        IN      A       192.9.210.4
>  tahiti          IN      A       192.9.223.18
>  localhost       IN      A       127.0.0.1

In the absence of MX records, mail for users at each of these systems will
be sent directly to the system itself; it will not be sent through pscgate
or ns3.  The effect is (almost) the same as if you had these MX records:

    pscgate     MX 0 pscgate
    introute    MX 0 introute
    progress    MX 0 progress
    tahiti      MX 0 tahiti

Even if this is what you want, I recommend adding the explicit MX
records rather than relying on the default behaviour.  Adding the explicit
MX records will allow remote hosts to cache the information, whereas
omitting the MX records requires remote hosts to query your nameserver
every time they need the information.  (Unless they do negative caching,
but I am not aware of any nameserver implementations that do that.)

>  Mail coming in to progress.com is fine, but I have tried a million
>  combos to add an MX for *.progress.com only to have it fail for
>  all mail.

If you add an MX like this:

   *.progress.com.      MX      10 pscgate.progress.com.
   *.progress.com.      MX      20 ns3.psi.net.

then mail for user@no-such-host.progress.com will be sent to pscgate
or to ns3, but mail for user@tahiti.progress.com will be delivered
directly to tahiti, because wildcards do not match domains that are
also mentioned in non-wildcard records.  When you say that it fails,
do you mean that it does not work like this, or that it does do this
but you were expecting something different?

>  All mail is handled by the name server system pscgate and handed off
>  to the system progress which is a non-DNS system.

Sorry to be so dense, but I don't understand what you mean here.  Do you
mean "All mail is currently handled by pscgate but I don't want that
to happen" or "I want all mail to be handled by pscgate but that is not
currently happening" or something else?  And what is a "non-DNS system"?

It might also help if you explained whether these systems will be
reachable from the Internet.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett
Newsgroups: comp.protocols.tcp-ip.domains