MX Record on a wildcard zone

[Pete Ehlke]

On Fri, Jul 12, 2002 at 09:23:24PM +0100, 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.

I'm aware of your position on wildcard MX records; mine is not as
extreme. I agree that in the vast, vast majority of cases where an admin
has published a wildcard MX, it was the wrong way to approach whatever
condition was being addressed, and that using such records almost always
causes more problems than it solves. But I view wildcards as 'enough
rope' rather than 'an earthly manifestation of Gozer'. They have a place in
some situations, but they're most often used by inexperienced admins
to attempt to band-aid over other, poorly thought out architectures.

>     Pete> Testing labs, for example, where you're evaluating mail
>     Pete> server software.
> 
> True, but that's for testing, not production.

Which, coincidentally, is the environment that the original poster was
discussing. But that's sort of irrelevant to the discussion at hand ;)

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

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

Your scenario assumes that there is a standard for mail software that
applies across the entire scope of the network served by the same name
servers. That's not always the case; I've worked in environments where
network services (including DNS) was managed globally, but individual
operating companies, various national and regional operations,
divisions, departments and even workgroups were free to use the mail
system that they chose. I suspect that, hype about enterprise-wide mail
systems notwithstanding, this situation is more common than a lot of us
really want to admit. *Assuming competent network and DNS admins*, it's
more efficient on a global scale, if you're restricting outbound mail to
a small set of machines and other external access is proxy based, to
route mail internally based on MX records than it is to keep track of
everyone on the planet who is running a mail server inside the
enterprise.

> 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.
> 
Well I disagree that this is a problem. So you have to add a record on
your central master server. What's the difficulty? Again, on an
enterprise scale, it's easier than tracking down every mail server in
the company and having its admin update it.

And as Kevin noted, if you're doing MX based mail routing and you open or
close a private link to a partner, you make one change, in one place,
and everyone in the enterprise picks it up, regardless of their platform
or skill level. I consider that a win.

I agree that if you have a centrally managed, enterprise wide email
system with 100% penetration, the wildcard scenario loses its
justification. But that's part of my point. Wildcards are a tool,
appropriate to a few tasks but not right for most.

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

I think you place too much faith in the ability of the enterprise to
centrally manage all of its email infrastructure. My experience in large
scale operations has been that there is often an 'official' standard,
but that even the official systems are rarely completely centrally
managed. Some organizations splinter off, some run their own instances
loosely tied in to the parent company, administrators chafe when the
official configuration doesn't meet their users' needs and expectations,
and islands develop, even within the officially sanctioned enterprise
system. When all those systems speak IP and smtp, managing mail routing
across the enterprise with MX records instead of hundreds of local
configurations starts to make a lot of sense to me. I'd much rather
change one record in the DNS than deal with the calls from a dozen 
mail admins and vice presidents whose mail stopped working when the route to 
the outside world changed and they weren't on the distribution list for
the announcement.

-Pete