Wildcards in MX Record Domain Names

[DNS Administration]

Jim Reid wrote:

> >>>>> "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? :-)

The mail systems are only "broken" or "stupid" if they can't get the job
done. But they *can* get the job done, using MX records, with a minimum
of muss and fuss, so are they really "broken" or "stupid", and do they
really need to be "fixed"? And if the "brokenness" or
"stupidity" consists only of the requirement to "pollute" the
internal-root zone with wildcards, then this strikes me as a bit of a
circular argument.

(Yes, I see the smiley, but in context  I took it as a half-smiley at
most).

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

I guess it's a matter of perspective, then. To me, a mailer that relies
on MX records isn't suffering from some sort of delusion that it's on the
Internet; it is simply trying to use a particular facility to route its
mail. The fact that this happens to be the same mail-routing facility as
the predominant one on the Internet is just a happy coincidence. Now, if
one chooses to implement that facility on one's intranet, fine. If one
chooses to use some other mail-routing facility or methodology, then
that's fine too, although I prefer MX routing because of the central
administration, flexibility and fault-tolerance. But I don't see anything
fundamentally "broken" or "wrong" with either approach.

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

And my viewpoint is that if wildcard TLD MX'es have caused problems at
some sites, it's not because the concept is fundamentally wrong, but
because it was not implemented correctly.

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

How "smart" is the relay if it can't failover or load-balance its
outbound Internet gateways? Sure, it's *possible* for a relay to just
"punt" mail, but is that *preferable* if you have the option of using
MX records? You seem to be valuing the abstract "purity" of internal-root
zones over the concrete benefits of MX-based routing for outbound
Internet mail. I think I'm being more pragmatic in this respect: an
internal root zone isn't created just to sit there and look pretty; it's
created to work and create value for the enterprise, and if that means it
needs to get a little dirty and "polluted" in order to reap the benefits
of MX-based routing, then so be it.

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

No, not really. MX records just tell a mailer who handles mail for a
particular name or set of names. It's not a "lie" to say that gateway
X on my intranet handles mail for "ibm.com": it's the god-honest truth.
See, that's why MX records are fundamentally different conceptually from
A records -- they don't describe a *thing*, only a way to get somewhere;
more like directions to a house than a house itself. So it doesn't bother
me in the least that my MX records for a name or set of names differ from
the Internet's; because the reality is that the way of getting mail to
that organization from a mailer on my intranet is different from the way
that same mailer would deliver it if it were directly connected to the
Internet (okay, admittedly, one route is a *superset* of the other, but
they're still different ways).

>     >> 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?]

Only TLD MX wildcards, until someone can demonstrate to me that there are
tangible benefits -- like failover and load-balancing options -- to
adding any other kind of records.

> Eventually this approach will break down.

Not if you set the proper pain-vs.-gain threshold. Our wildcards right
now benefit us much more than they cost in maintenance and/or complexity
costs. I'm not going to add anything else just because J. Random User or
even J. Random Manager thinks it would be a neat idea. I can articulate
the value of MX-based routing in management-speak that gets heard,
understood and accepted. And likewise, I can articulate the value of
NOT adding other kinds of data to the internal root zone. The cruft stops
here.

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

If, hypothetically, such a thing were to transpire, I could always create
lower-level MX wildcards (*.ibm.com or whatever) to accommodate the
"intruding" A record. So it's an ugly problem, but not an intractable
one. Such a requirement is highly unlikely to arise, though, since we
have a strict security policy in place against direct connections to the
Internet, and, frankly, not a lot of infrastructure that could support
such a thing. Last I checked, our routers didn't even have default routes
pointing in that direction. So it wouldn't just be a DNS change; it'd be
a major infrastructure change.

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

Well, if the only technical reason for not adding the wildcards is to
prevent any potential conflicts with fake Internet A records, aren't you
*inviting* a greater evil? I'd rather tell the Big Boss that his A record
is going to break email unless $XXX,XXX is paid to redo our
infrastructure than to admit that I've carefully paved the way for its
addition, and, oh yes, feel free to have me create others so I can
maintain that cruft for the rest of my life. Sometimes the best answer is
a negative answer, regardless of whom it pisses off. And, as every good
DNS admin knows, the TTL for a negative cache entry is almost always
shorter than for a positive one :-)

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

It has been so far. I guess some organizations are better at securing
worm-can-lids than others. Part of the secret is to ensure the worms
don't know anything exists outside of their can. :-)


- Kevin