Wildcards in MX Record Domain Names

[Jim Reid]

>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    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.

    Kevin> Fixing? Circumventing the MX routing mechanism is a fix?

And you think polluting your root zone with cruft because broken or
stupid mail systems can't be configured properly for an intranet is a
fix? :-)

    Kevin> I think that cure is worse than the disease.

We'll have to agree to differ about that.

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

    Kevin> Broken in what way? I think using MX records is a perfectly
    Kevin> valid way to route mail. It seems to work fine for the
    Kevin> Internet, why not intranets as well?

I didn't say there was anything wrong with MX records, far from it.
What I did say was wrong is kludging your name space - and the root
zone in particular - because broken software mistakenly believes it is
on the Internet. [If someone put a gun to my head, I'd do this. But I
would *never* do it through choice. I've seen the problems - largely
self-inficted - this has caused some sites.] And for these broken mail
systems, there is an alternative: get them to punt their mail at
relays that can walk and chew gum at the same time. Fix the underlying
problem at source and all that.

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

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

True, but with smart mail relays, this approach isn't necessary. If
you've gone to the trouble of running an internal root to close off
the outside world, why re-introduce the outside world in the form of
wildcard MX records for TLDs and anything else that takes your fancy?
Doesn't that seem a little odd?

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

    Kevin> Well, mail routing is the only mechanism I can think of
    Kevin> which has its own record type in DNS apart from a generic
    Kevin> name-to-address or address-to-name mapping, and about which
    Kevin> one might conceivably want to "lie" in an internal-root
    Kevin> context.

The issue here is names and naming, not record types. How many "lies"
have to be put in your root zone and how easy is it to control and
maintain that conspiracy? [How much of the outside world are you
prepared or obliged to replicate in the internal root?] Eventually
this approach will break down. If it works for you at present, then
that's fine. It's your net and your name space after all. It wouldn't
be my choice, but then again I'm not running your net.

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

    Kevin> Hmmm... Running an internal root zone pretty much assumes
    Kevin> you have no need to resolve external names in the first
    Kevin> place, doesn't it? I'd never need an A record for ibm.com
    Kevin> since there is no way anyone internal can connect to it

I was using ibm.com as an example of what can go wrong if you start
adding cruft to the existing situation. Just suppose the Big Boss
demands you add such a name - he/he isn't interested in proxy servers
and wants to get to some important web site on the Internet. Now. What
do you say, "sorry, I can't because the company's email will break"?

    Kevin> (they'd have to go through an application proxy instead),
    Kevin> and therefore I never have these kinds of A-vs-MX
    Kevin> conflicts. If someone is polluting their internal root with
    Kevin> unnecessary A records, then I think they have a systemic
    Kevin> problem and MX records aren't the only things that are
    Kevin> going to suffer from it.

Indeed. But where we differ is where we draw the line. IMHO, adding
wildcard MX records for external names is already a step too far.

    Kevin> Well, as I said, I've made a special case for MX records,
    Kevin> because we happen to have software which can put them to a
    Kevin> good and valid use.  I hold the line on everything else,
    Kevin> and so my root zone is relatively cruft-free.

Fine. I hope it remains straightforward to keep the lid on this can of
worms, sorry I mean "special case".