Wildcards in MX Record Domain Names

[Kevin Darcy]

Jim Reid wrote:

> >>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:
>
>     >> > *.org IN MX 10 firewallrelay.mayo.org
>     >> > *.gov IN MX 10 firewallrelay.mayo.org
>     >> > *.  IN MX 10 firewallrelay.mayo.org
>     >> Yes.  But this is probably not the right way of doing this.
>     >> You should really put a relay host into your sendmail.cf file,
>     >> to send all non-local e-mail to your firewall.
>
>     Kevin> Why? Is it easier to custom-configure dozens or hundreds of
>     Kevin> sendmail.cf's than it is one master file on an internal
>     Kevin> root server? And what if you want redundancy or
>     Kevin> load-balancing for outbound email? Sure, you could probably
>     Kevin> hack that logic into the sendmail.cf too, but why bother
>     Kevin> when you can just add a few more MX records to the internal
>     Kevin> root?
>
> Because fixing the mail systems is the Right Thing to do.

Fixing? Circumventing the MX routing mechanism is a fix? I think that
cure is worse than the disease.

> After all
> it's them that are broken, not the DNS.

Broken in what way? I think using MX records is a perfectly valid way to
route mail. It seems to work fine for the Internet, why not intranets as
well? And it means your internal mailer configurations can be based on
the same routing paradigm as an Internet-connected mailer, which is
easier for some Internet-oriented junior admins to comprehend. Firewalls,
as usual, are often an exception here.

> It's also not a good idea to
> pollute your internal root zone with this sort of cruft, especially
> wildcard MX records.

I don't see this as pollution, or at worst, relatively benign pollution.
All I have in my internal root zone (other than the mandatory stuff like
SOA and NS records of course) are wildcard MX'es and delegations. Not
very crufty. And any admin trying to troubleshoot a mail routing problem
can just do an MX query anywhere on the network to see how their mail is
being routed, instead of having to parse out the smarthost name from a
sendmail.cf.

> It sets a precedent. When the next item of
> defective or misconfigured software comes along, you don't have a
> strong justification to refuse to kludge the DNS for that as well. If
> you're not careful, your root zone will end up in a mess of kludges
> and hacks that are hard to maintain or understand.

Well, mail routing is the only mechanism I can think of which has its own
record type in DNS apart from a generic name-to-address or
address-to-name mapping, and about which one might conceivably want to
"lie" in an internal-root context. If SRV or some other record type ever
evolves to this stage, then I would definitely reconsider my methodology.
But for the foreseeable future, MX'es are the only record type which get
"special" treatment in my internal root zone.

> These might also be
> interdependent in subtle and weird ways. The wildcarding could even
> break. Suppose you then have to add an A record for an external web
> site - say ibm.com - to your root zone because of some other broken
> application or stupid misconfiguration. Now the idiot mailers can't
> send mail to ibm.com because the A record for ibm.com will take
> precedence over the *.com MX wilcard. The more cruft that goes into
> the root zone, the worse that problem becomes.

Hmmm... Running an internal root zone pretty much assumes you have no
need to resolve external names in the first place, doesn't it? I'd never
need an A record for ibm.com since there is no way anyone internal can
connect to it (they'd have to go through an application proxy instead),
and therefore I never have these kinds of A-vs-MX conflicts. If someone
is polluting their internal root with unnecessary A records, then I think
they have a systemic problem and MX records aren't the only things that
are going to suffer from it.

> Sure, adding the wildcard MX records to the root zone is a quick and
> dirty hack. It's definitely much quicker to do than fix every internal
> mail system. However the long-term costs of maintaining and supporting
> this set-up are probably going to be far higher than the costs of
> doing things right from the outset. Just think of the extra (and
> unnecessary) complexity in the root zone and all the nasty problems
> that could flow from that name space pollution. And once you've
> started down that slippery slope, it's very hard to go back. Removing
> legacy cruft from the root zone can be almost impossible. Once it's
> there, people will use and abuse it for all sorts of things.

Well, as I said, I've made a special case for MX records, because we
happen to have software which can put them to a good and valid use.
I hold the line on everything else, and so my root zone is relatively
cruft-free. As for maintenance costs, we have hundreds of sendmail
instances internally which are quite happy just relying on MX records
than with some "smarthost" forward-up-the-line kind of configuration that
offers less options for load-balancing or redundancy. Since I'm
responsible for both the SMTP routing and the DNS architecture around
here, I find this to be the best of both worlds. Low maintenance,
relatively headache-free. I haven't had any reason to change my root zone
*or* make any major changes to a production sendmail.cf for months (and
the minor sendmail.cf change was only necessary because I like to keep
the Solaris sendmail.cf's as much in synch with the vendor-supplied
version as possible).

>     Kevin> Plus, you're assuming they're running sendmail or something
>     Kevin> equally manipulable...
>
> True. But even the most brain-dead mail software will usually have an
> option somewhere to forward mail via SMTP to a smart relay. "I'm too
> stupid or inflexible to route mail properly, but I know how to punt
> stuff to another mail server that can do this for me." In fact some
> of these idiot mail systems might not even need to be configured to
> know about MX records or use the DNS at all.

Point well taken, but this is my biggest gripe about such brain-dead mail
systems. Their lack of MX-awareness severely impairs their ability to
sanely do failover and/or load-balancing. Strategically, I think it's
better to hammer on the vendors to make their mailers MX-aware than to
dumb down one's own mail routing paradigm to the lowest common
denominator. They *have* to become MX-aware anyway, if anyone is going to
use them as Internet mail gateways, so it's in everybody's interests to
speed up that evolution.


- Kevin