Routing mail between two domains via an internal route

[Kevin Darcy]

Anthony Mandic wrote:

> I've been tasked by a client to look at relieving a mail problem by
> routing email via an internal route between two sites rather than
> thru a clogged route out to the internet.
>
> Both sites are state government departments headed by the same
> minister. They are required to have a private link (ISDN) between
> them and are visible to each other.
>
> This isn't really my field of expertise and, as such, I've been
> doing a lot of research to learn more but time is short.
>
> The two domains are fisheries.nsw.gov.au (who is my direct client)
> and minerals.nsw.gov.au. The internal IP addresses are 172.16.20.x
> and 150.1.1.x.
>
> At first I thought I could get the MX records at both ends recognised
> by each other and get sendmail to route email internally as needed.
> However, the process doesn't appear to be that simple.
>
> Fisheries has two nameservers and one mail exchanger. I'm using one
> nameserver from Minerals but it appears to have up to four mail servers.
> I changed /etc/resolv.conf on Fisheries' mail server to use 'search'
> and added the Minerals domain and nameserver. Unfortunately, I found
> that this alone doesn't work (the Minerals nameserver isn't used unless
> the Fisheries ones aren't up. Switching things around did work but isn't
> the solution).
>
> I then found the forwarders solution for named.boot (version 4 is used).
> This appeared to work in that nslookup was able to report the MX record
> for the other nameserver. However, I found that the named.boot files
> for the primary and secondary nameservers in Fisheries were not identical
> and that there were odd differences in how they worked as a result (a
> MX lookup against the other found the Minerals details via the Internet
> route rather than internally).
>
> What I would like to know is -
>
> Are changes to resolv.conf required if I only want sendmail to find
> the MX record for the other site?

The resolv.conf just tells the resolver -- in this case, the built-in
resolver that sendmail uses -- what nameserver(s) to use for resolution. So
the question really is: can you find one or more nameservers that give you
the data you need to route mail properly? Once that question is answered,
then the resolv.conf question follows suit.

> Should I configure sendmail instead?

You could do that, but sendmail hacks quickly tend to become unmanageable.
If the correct DNS data is available, it is generally recommended that you
make that data available to the nameserver and then have sendmail rely on
that data and run as pure a sendmail configuration as possible.

> Should the named.boot files be identical for the primary and secondary
> nameservers at Fisheries?

That's hard to say without knowing the whole Fisheries name-resolution
architecture. Perhaps what you are calling a "primary" is really a
special-purpose machine that only certain clients should be using. Or maybe
the "secondary" is a special-purpose machine. Or maybe they both are. Did
you ask the administrators of those nameservers why they resolve those MX'es
differently, or which server(s) you should be using for routing mail to
Minerals?

> Is there another way to add the other MX record and its domain?

Only by maintaining your own "fake" copy of the domain, which would be a
super-ugly solution.

> I added the Minerals nameserver forwarder address before the Internet
> forwarders address to named.boot.

Why? The forwarders in a forwarders list are only there for *redundancy*,
not to get a "second opinion" on whether a given name exists or not. If
forwarder #1 says that a certain name doesn't exist, named isn't going to go
ask the other forwarders about it. This is a common misconception. You're
going to get inconsistent behavior if the forwarders in the forwarders list
are returning inconsistent answers to the same question.

> I believe this will impact the
> internal link with Internet domain searches. Is this correct and, if
> so, is there anyway to minimise this impact?
>
> Is it possible to have things only do lookups for the other domain
> against only the other nameserver?

Well, sure. If you upgrade to a reasonably-modern (safe!) version of BIND 8,
or to BIND 9, then you can use "per-domain forwarding", i.e. forwarding to a
particular forwarder or set of forwarders, only for names in a particular
domain. Note however, that forwarding is generally to be avoided, and a
"type stub" zone might be a better solution here (just make sure to specify
"forwarders { }" in the stub-zone definition if there are any subzones
involved).

Even with a backlevel version of BIND, you could become a slave (a
"secondary" in named.boot parlance) of the zone in question, assuming that
the master allows your server to do zone transfers from it. Bear in mind,
however, that with BIND 4, combining slaving with forwarding will require
you to slave *every* subzone of that domain. Yuck. The BIND 8 capabilities
are much better in this regard.


- Kevin