multiple MX records versus DNS round robin

Laurent Verhoest lolofarwest at my-deja.com
Tue Jul 13 07:45:29 UTC 1999


In article <0YKh3.2317$Pu4.11581413 at firenze.visi.net>,
  "Stamey" <Stamey at Farther.com> wrote:
> That is just too simple.
> @    IN    MX    10    Mail1.domain.com.
> @    IN    MX    20    Mail2.domain.com.
> @    IN    MX    30    Mail3.domain.com
>
> You put your first preference with the lowest "cost" and if that one's
down,
> it will go the the next higher cost server diesignated in the mail
records.
>

this is only for "backup recovery" : if your first mail server fails
down, then the second is still there to handle the mail traffic.

>
> Erwin Richard wrote in message <3777cf9a at rba-bone>...
> Hello,
>
> We are considering implementing a redundant sendmail server in
parallel to
> our existing mailhost. It should share the normal load as well as
provide a
> backup if one of the servers is down. As I see it now, we have two
> possibilities:
>
> 1. define multiple MX records with the same preference level
>
> 2. define multiple A records for our mailhost
>
> What's the better solution? Solution 1 would require to change all
zone
> files that have MX records that point to our mailhost but I'm willing
to do
> this if it gives us considerable benefits. Any recommendations?
>

in fact, you don't have such 2 possibilities, but one : using both
solution at the same time. Because they don't answer the same issues.

Multiple MX records provides you a "fail safe" mode.

Multiple AA records for your mailhost gives you a load sharing (not load
balancing...) via DNS round robin.

@            IN MX 10 mailhost.domain.com.
@            IN MX 20 backup.domain.com.       ; if mailhost is down,
backup gets the traffic

mailhost     IN CNAME realmailhost.domain.com.
backup       IN CNAME realbackup.domain.com.

realmailhost IN A IP.of.first.server
realmailhost IN A IP.of.second.server   ; load sharing via DNS round
robin
realbackup   IN A IP.of.backup.server

--
Laurent.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


More information about the bind-users mailing list