Slightly OT - MX RR Santity Check requested...

Kevin P. Knox bind-users at rc4systems.net
Thu Mar 29 02:31:52 UTC 2007


I'm starting to think that I'm just not explaining this well.  The strategy 
I'm trying to explain came straight out of the ORA book, "Building Internet 
Firewalls"....albeit years ago.   It's on my list of things to do to 
configure SMTP server v-hosting transports under Postfix and then we really 
won't need to use MX RRs the way we do.  But until that time, this is the way 
we do it.

This strategy is used to protect a relatively "important" SMTP server, while 
permitting a "bastion host" to relay.  SMTP is "forced" by the MX RRs and the 
fact that the important SMTP server isn't reachable.  Our "bastion" performs 
layer 3 (IP) blacklisting, as well as content scanning for malware and 
UCE/SPAM.

Here's the way it works...

There are two MX RRs for the domain.  The most preferred is assigned to the 
heavily defended SMTP server.  The less preferred is assigned to the DMZ 
(bastion) SMTP server.  There's a firewall (or packet filtering router) 
between both SMTP servers and the outside world.  But the firewall is 
configured to only permit TCP/25 connections from the outside world to the 
less preferred mail server.

Sending mail servers query the DNS and attempt a TCP/25 connection to the most 
preferred MXer.  But this host is blocked by the firewall.  So they "should" 
choose the next preferred MX RR and try that server.  That server is the DMZ 
mail server.  

The DMZ mail server has been configured to relay e-mail for the important 
server.  The MX algorithm states that the DMZ server should discard all MX 
RRs of equal or higher preference than its own, which in our case simply 
leaves that of the defended mail server, and so uses that MX RR and delivers 
back to that server.

Is ANYBODY running SMTP services like this any more?  I'm starting to think 
not.  

I didn't really mean for this to turn into a protracted discussion on DNS and 
SMTP.  I'm just trying to find out why a very few sending hosts don't ever 
query past the most preferred MX RRs for our domains.

... Kev

On Wednesday 28 March 2007 09:39 pm, Kal Feher wrote:
> Why do you have a lower pref for an unavailable (from an outside
> perspective) server?
> If you wanted to preference the hidden mail server from internal systems,
> you could configure it as either a smart host or set up views to have an
> alternate order for the internal systems.
> You could try having the same preference for both, but if the dodgy mail
> server doesn't follow part of the RFC, there's no guarantee they'll follow
> the rest of it specifying the checking of all lowest pref servers.
>
> On 29/3/07 10:56 AM, "Kevin P. Knox" <bind-users at rc4systems.net> wrote:
> > You mean "their" configuration is broken?  The sending mail server is NOT
> > ours.  We're on the receiving end.
> >
> > Our MX RRs are not empty.  We've got two MX RRs for the domain in
> > question. Pref 5 is an internally firewalled server.  Pref 10 is a DMZ
> > (world reachable) SMTP server.  99% of the SMTP servers sending us mail,
> > query the MX RRs, select the most preferred, but the connection times out
> > because THAT MX host isn't world reachable.  So they fall back to our
> > pref 10 mailserver, which spools and delivers to the firewalled
> > mailserver.
> >
> > ...except for a few, which I'm trying to narrow down to some common
> > factor.
> >
> > RFC 2821 section 5 certainly strongly suggests that mail transport agents
> > support multiple MX records.
> >
> > ... Kev
> >
> > On Wednesday 28 March 2007 08:04 pm, Mark Andrews wrote:
> >>> I've encountered a specific problem FOUR times in the past six months
> >>> now and
> >>>
> >>> am kindly asking Bind-Users for some insight.
> >>>
> >>> The problem is sending SMTP servers that don't ever query past the
> >>> first (hi pref) MX RRs.  The first time we encountered this problem, it
> >>> was with an e-mail list server appliance (don't know the exact
> >>> type/make/model) at a local university in our area.
> >>>
> >>> The second and third times were with new MS Exchange servers.
> >>>
> >>> Now today, I'm working on the same problem with a domain who's SMTP
> >>> services are hosted by Network Solutions Inc. (NSI).
> >>>
> >>> We use a strategy whereby our lowest numbered (high pref) MX RR is a
> >>> firewalled host.  The higher numbered (lower pref) MX RR designates our
> >>> DMZ SMTP server, which handles e-mail on behalf of the server in the
> >>> other MX RR.
> >>>
> >>> The DMZ SMTP server is world reachable on TCP/25.  It's straight out of
> >>> the ORA Nutshell book, "Building Internet Firewalls".  We process 4
> >>> million messages per month, so I'm pretty sure that other organizations
> >>> are still using MX and firewalls to force mail through the DMZ SMTP
> >>> server, and then deliver back to a better protected mail server.
> >>>
> >>> I've verified that the sending SMTP server only ever queries the first
> >>> (low numbered - high pref) MX RR.  After that...NOTHING.  It never
> >>> tries the second.
> >>>
> >>> The net result is that the sender (in this case) will queue SMTP
> >>> traffic for our domain indefinitely....because they never look up MX
> >>> RRs any lower than the highest pref MX RR.
> >>>
> >>> Has anybody else run into this lately?
> >>>
> >>> For the curious....   YES!  We plan on configuring transports in place
> >>> of the
> >>>
> >>> old Firewall/MX strategy on our Postfix servers ASAP.
> >>>
> >>> Thanks in advance. :-)
> >>>
> >>> ... Kev
> >>
> >> Your configuration is broken.
> >>
> >> RFC 974
> >>
> >>    If the list of MX RRs is not empty, the mailer should try to deliver
> >>    the message to the MXs in order (lowest preference value tried
> >>    first).  The mailer is required to attempt delivery to the lowest
> >>    valued MX.  Implementors are encouraged to write mailers so that they
> >>    try the MXs in order until one of the MXs accepts the message, or all
> >>    the MXs have been tried.  A somewhat less demanding system, in which
> >>    a fixed number of MXs is tried, is also reasonable.  Note that
> >>    multiple MXs may have the same preference value.  In this case, all
> >>    MXs at with a given value must be tried before any of a higher value
> >>    are tried.  In addition, in the special case in which there are
> >>    several MXs with the lowest preference value,  all of them should be
> >>    tried before a message is deemed undeliverable.



More information about the bind-users mailing list