MX Record on a wildcard zone

[Kevin Darcy]

Jim Reid wrote:

> >>>>> "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.

Why would something need to be done to every nameserver? At worst, only
the internal root zone needs to be updated on the root master, then the
addition will be visible to all of the other nameservers. Or, if one
wanted to be really lazy, one could just define a *root*-level wildcard
record, which would cause all mail to unknown TLD's to be forwarded
towards the Internet. I don't do this, because I want to catch mistyped
TLD's internally before they get forwarded to our firewalls (the ratio of
typo'ed TLD's to new TLD's is very high, in my experience, so I optimize
for the more common case).

> Or when the company opens/closes a pipe to the net of a
> business partner or supplier.

I'm not sure I quite understand this part. Yes, if you want
"special" routing for a trading partner, and your mail infrastructure
relies completely on MX records, you'll have to do some DNS tricks to
facilitate this "special" routing. But, again, you probably only have to
do this in one place. How is this any worse than making config changes in
sendmail.cf, mailertables, or whatever, and then having to push that out
to all of your mail servers, including to every new mail server that comes
on line?

Bottom line is that I prefer to control mail routing centrally in my
DNS database via MX records, than try to constantly keep up with the
configs of our hundreds of mail servers, which have a high rate of
turnover (we typically only lease our servers for 2 years).

>     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.

Exactly. As more and more mailers gain the capability to route mail via
MX records (even our Notes<->SMTP gateways are capable of this now), then
centrally managing mail routing via MX records becomes more and more
feasible. Hand-crafted local mailer configs are an endangered species,
IMO.


- Kevin