MX records and multiple IP addresses

Joseph S D Yao jsdy at cospo.osis.gov
Wed Aug 25 17:58:32 UTC 1999


> We have a client who is requesting the following:
> 
> They currently have an email server with an MX record pointing back to it.  So
> let's say the record is mailserver.nih.gov. IN MX 10 mailserver.nih.gov.  They
> wish to have another email server, mailserver2.nih.gov, that will be on the same
> IP address, but will be used for IIS web access to exchange.

Two separate, distinct machines on the same IP address?  You mean, e.g.,
	mailserver1.nih.gov.	IN  A	128.231.90.80
	mailserver2.nih.gov.	IN  A	128.231.90.80
?

How are you possibly going to be able to distinguish to which host you
are sending what packets?  This could conceivably be a communications
nightmare.  Why would your client want that?

On the other hand, if you are talking about two different pieces of
server software running on the same hardware, and you are just setting
up two different aliases for the fun of making them seem a little
different, then that should be no problem.

Alternately, if you are talking about two separate "private internets"
that will never, ever have to communicate with each other, then this is
also not a problem - although it doesn't sound like this is what you're
talking about.

> If they are registering mailserver2.nih.gov to the same IP address as
> mailserver.nih.gov will it need another MX record that points to mailserver2?
> In other words, mailserver2.nih.gov. IN MX 10 mailserver2.nih.gov.  Or, should
> the MX record point back to mailserver.nih.gov.

Let's talk about what MX records mean.

If I send standards-based e-mail to
	user at host
then the mail will actually be delivered to "host" ... UNLESS there is
an MX record with "host" on the left hand side, in which case it will
be delivered to the system on the right hand side.  In other words, if
I have:
	$ORIGIN		nih.gov.
	nih.gov.	IN  MX		mailserver1.nih.gov.
	virus.nih.gov.	IN  MX		mailserver1.nih.gov.
then mail to keller at nih.gov or keller at virus.nih.gov will both be
delivered to mailserver1.nih.gov.  As will mail to mailserver1.nih.gov,
despite its lack of an MX record!  Many prefer to put in the MX record,
though, and I agree that this is good configuration management.

However, in this example, mail to keller at mailserver2.nih.gov will be
delivered to mailserver2.nih.gov, and mail to keller at microbe.nih.gov
will be delivered to microbe.nih.gov.  Lack of MX records causes mail
to be delivered to the system itself.  Again, though, good configuration
management would suggest explicitly inserting MX records.

The interesting thing is that MX records are TOTALLY MEANINGLESS
outside the narrow sphere of standards-based e-mail delivery.  I don't
know how it affects your Web-based MS Exchange ... client or server,
you didn't say?  But if mail is only being sent from this, and not to
it, then you not only don't need an MX record, but you MUST NOT have
one.  Conversely, if STANDARDS-BASED e-mail for a specific set of host
and domain names should be sent to this server, then each of those
should have MX records specifying that server.

I keep stressing STANDARDS-BASED because many proprietary mail servers
use peculiar proprietary mail delivery schemes.  [E.g., I've noticed
problems with many MS products.]  Some, even most, of these may have
nothing whatsoever to do with DNS, much less MX records.

Note also that it doesn't matter which of several names for a machine
you use on the right hand side of an MX record, as long as it has its
own A record specifying that machine's IP address.  A machine or domain
name on the left hand side may not also be on the left side of a CNAME
record.

> In addition, will multiple MX records on the same IP address cause any kind of
> problems routing e-mail or with name resolution?

Absolutely not, as long as the MX records are all correct.

--
Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.


More information about the bind-users mailing list