[clug] Single MX, multiple A records

Daniel Pittman daniel at rimspace.net
Fri Aug 1 03:48:28 GMT 2008

Michael James <michael at james.st> writes:

> What is the standard behaviour when a DNS name returns multiple A
> records?

There really isn't a specified standard.

> Should the client host:
> 1) Pick one deterministically, give up if it doesn't work?
> 2) Pick one at random, give up if it doesn't work?
> 3) Work through the list deterministically till one works?
> 4) Work through the list randomly till one works?
> 5) Use them all?

Yes.  (Except number 5, which I initially misunderstood.)

> The intent was to create a pool of servers for reliability.

Typically, yes.

> But (assuming there is a dud server on the list)
> 1) Gives patchy, location-dependant, service dropouts.
> 2) Gives random errors, (not as bad but still bad)

Worse, to my way of thinking, because it makes it harder to identify why
some-but-not-all client machines are failing, and may confuse the
question of DNS pointing to a dead server for the poor admin debugging it.

> 3) Gives reliability through redundancy
> 4) Gives reliability through redundancy
> 5) When it makes sense gives reliability through redundancy

These are the most common behaviours, and so results, for client
software that cares enough to think about this issue.

For the client software that doesn't, either 1 or 2, but most commonly 
1 (try the first, then fail) is the result.

> I'm interested in 2 contexts,
> My ISP gives a single MX for his mailhost.
> Then that resolves to 2 IP addresses.
> Depending on the table above I will get:


> 5) Duplicates. (doesn't make sense)

Oh.  No, you are right: it never, ever makes sense to communicate with
all the addresses returned.  I misunderstood what you meant by "use them

> I think a better DNS setup is to have multiple MXs, then the specified
> behaviour for a mail sender is to work up the list till one accepts
> (or rejects) the mail.

Your theory here does not reflect the option for listing multiple MX
hosts at the same priority level, in which case you face exactly the
same situation save in a protocol specific context.

(SMTP does handle than sensibly, by spec, though.)

> Am I right, thanks for your thoughts?

DNS Round Robin performance or redundancy works, but not as well as more
modern solutions that provide multiple systems behind a single IP, and
so have (sensibly) fallen out of vogue.

They still work as they did, though, and for a store-and-forward
protocol like SMTP where there is *no* chance of mail loss due to
connection failure, it isn't an unreasonable choice.


More information about the linux mailing list