MX Record on a wildcard zone

[Jim Reid]

>>>>> "Pete" == Pete Ehlke <pde at ehlke.net> writes:

    Pete> There are plenty of perfectly valid reasons for wanting to
    Pete> publish a wildcard MX for com.

I strongly disagree. See the previous discussions in this list about
wilcard MX records.

    Pete> Testing labs, for example, where you're evaluating mail
    Pete> server software.

True, but that's for testing, not production.

    Pete> The most common legitimate reason is in
    Pete> networks that communicate with the outside world only
    Pete> through application proxies. You set up false root servers
    Pete> that publish wildcard MX records for . pointing to a small
    Pete> set of smtp servers that are allowed to communicate with the
    Pete> outside world, and then simply deny outbound smtp from
    Pete> everyone else on the network.  You can avoid an incredible
    Pete> pile of mail server configuration hassles on large networks
    Pete> like this.

I dispute the use of "legitimate", but let's agree to differ.

In such environments, all the mail will presumably be required to be
relayed through centrally managed mail servers that scan inbound and
outbound messages for content control. And probably for billing. It's
unlikely the firewalls will allow a free-for-all of SMTP in and out of
the network too. So an internal root with split DNS and no wilcard MX
records is more likely. Granted, this implies more work on local mail
server configuration to deal with non-local mail. That may be desirable
for other reasons anyway. For example to ensure all sites run the
company standard mail software configured to the corporate standard or
to prevent bypass of billing systems or smut and virus filters.

And by introducing wildcard MX records, you'd pretty much shift the
configuration hassles to the name servers. For instance: possibly doing
something to every name server whenever a new TLD is introduced on the
internet. Or when the company opens/closes a pipe to the net of a
business partner or supplier.

    Pete> For a very interesting discussion of such an architecture,
    Pete> see Vixie and Scharf's paper "SENDS: a Tool for Managing
    Pete> Domain Naming and Electronic Mail in a Large Organization"
    Pete> from the proceedings of LISA '94.

It's an interesting paper and I used some of its ideas for a DNS
management system I built ~5 years ago. But the world of email has
moved on quite a bit since then. About a decade ago, there were very
few enterprise-wide mail systems based on things like Exchange or
Notes. They either didn't exist or else didn't use DNS to route and
deliver mail in those days. If you were lucky, those enterprise mail
systems could take incoming mail via SMTP. [Sometimes those SMTP
gateways even worked!] Few corporate nets were IP based in those
far-off days.