[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference gyro::internet_toolss

Title:Internet Tools
Notice:Report ALL NETSCAPE Problems directly to [email protected].rnet? Read note 448.L for beginner information.
Moderator:teco.mro.dec.com::tecotoo.mro.dec.com::mayer
Created:Fri Jun 25 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4714
Total number of notes:40609

4412.0. "MX wildcard record not visible?" by BIGUN::nessus.cao.dec.com::Mayne (Wake up, time to die) Wed Jan 22 1997 22:11

T.RTitleUserPersonal
Name
DateLines
4412.1teco.mro.dec.com::tecotoo.mro.dec.com::mayerDanny MayerThu Jan 23 1997 08:5635
4412.2BIGUN::nessus.cao.dec.com::MayneWake up, time to dieThu Jan 23 1997 16:0825
4412.3CFSCTC::SMITHTom Smith MRO1-3/D12 dtn 297-4751Thu Jan 23 1997 16:4324
4412.4teco.mro.dec.com::tecotoo.mro.dec.com::mayerDanny MayerFri Jan 24 1997 09:4110
	I think the real problem here is whether or not real Mail systems
  would be able to support wildcarding in this way.  If it's only in 
  sendmail 8.7 and later, that's probably not enough since people use many
  different mail servers to send mail out.  How would you ensure, for example,
  that mail sent via Exchange would be able to reach its intended recipient?
  I don't think you want to implement a solution that is only usable by some
  mail servers.  You want something that will always work for ALL mail servers,
  particularly if this is for a customer.

		Danny
4412.5QUICHE::PITTAlph a ha is better than no VAX!Tue Jan 28 1997 09:0616
This is very strange, because it usually works correctly on firewalls - as PJDM
knows, I have installed a good many for customers, and there are almost always
wildcard MX records involved.  Indeed I did a very similar thing for one
customer, where one subdomain was routed to one mailhub, and all the rest to
another - I didn't have to do anything special in DNS.

It's not possible, is it, that there are DNS caching and/or non-updated
secondary servers involved somewhere?

Have you tried sending mail in from one source only?  If so, perhaps there's a
problem there, rather than at the firewall/DNS.

I suppose the "workaround" is to put MX records in explicitly for
mailtest1.aph.gov.au, but I still don't think you should need to ...

T
4412.6BIGUN::nessus.cao.dec.com::MayneWake up, time to dieThu Jan 30 1997 22:3067
.3, .4:

The version of sendmail (which is the current Digital UNIX one, and therefore 
pre-V8) is irrelevant (so far), because it's the DNS lookup that's failing, 
demonstrated by using nslookup. (It may become relevant if I can figure out why 
the MX lookup is failing.)

.5:

The named database says:

@       IN      SOA     par115.aph.gov.au. root.aph.gov.au. (
                        1996112002      ; Serial   
                        10800           ; Refresh - 3 hours
                        3600            ; Retry - 1 hour
                        1209600         ; Expire - 2 weeks
                        43200 )         ; Minimum - 12 hours

An nslookup SOA lookup says:

Non-authoritative answer:
aph.gov.au
        primary name server = par115.aph.gov.au
        responsible mail addr = root.aph.gov.au
        serial  = 1996112002
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 1209600 (14 days)
        default TTL = 43200 (12 hours)

Given that the serial numbers match, that presumably knocks out incorrect caches 
or secondary name servers (?).

We've tried sending mail from several places and different domains: they all 
have the same problem. Except (as I said in .0) the firewall itself has no 
problem realising that mailtest1.aph.gov.au matches the wildcard MX record, and 
mail from the firewall does exactly what it's supposed to do.

This is strange.

I just tried something on the primary DNS server for cao.dec.com (an ULTRIX 
system).

        *.cao.dec.com   IN      MX      10      litlun.cao.dec.com.

An MX lookup on fred.cao.dec.com failed ("No address information is available"). 
Then I tried the following:

        *.cao.dec.com   IN      MX      10      litlun.cao.dec.com

(Note the lack of trailing dot.) An MX lookup on fred.cao.dec.com (or 
anything.cao.dec.com, for that matter) now returns what I expect ("mail 
exchanger = litlun.cao.dec.com").

Bizarre.

I'll try putting in an explicit MX record for mailtest1. (I don't think I should 
have to either.)

A thought just occurred to me. Is it possible that between the firewall (which 
correctly uses the wildcard MX record and the rest of the world, there is an 
old-fashioned DNS server (perhaps at the ISP) that doesn't know how to transmit 
wildcard MX records, and therefore stuffs this up? Is there a way of finding 
out?

PJDM

4412.7CFSCTC::SMITHTom Smith MRO1-3/D12 dtn 297-4751Fri Jan 31 1997 11:1214
    re: .-1
    
    Yes, you're right. The version of sendmail doesn't really matter.
    Wildcard MX's just don't work very well, period. Here's a more explicit
    comment from the sendmail V8.8.5 source directory README:
    
    "WILDCARD MX RECORDS ARE A BAD IDEA!  The only situation in which they
    work reliably is if you have two versions of DNS, one in the real world
    which has a wildcard pointing to your firewall, and a completely
    different version of the database internally that does not include
    wildcard MX records that match your domain.  ANYTHING ELSE WILL GIVE
    YOU HEADACHES!"
    
    -Tom    
4412.8BIGUN::nessus.cao.dec.com::MayneWake up, time to dieSun Feb 02 1997 15:323
Gee, I wish the AltaVista firewall engineers were reading this. 8-)

PJDM
4412.916.25.0.70::tecotoo.mro.dec.com::mayerDanny MayerMon Feb 03 1997 09:355
> Gee, I wish the AltaVista firewall engineers were reading this. 8-)

	Why?

		Danny
4412.10BIGUN::nessus.cao.dec.com::MayneWake up, time to dieMon Feb 03 1997 15:554
Because they're the ones that put the wildcard MX record in the DNS database. 
Presumably they have good reasons for doing so.

PJDM