> If DNS RFCs say a server MUST do round-robin serving of equal (MX) RRs,
> then any that don't are, by definition broken, and since the *best* fix
> for this is to fix the DNS server, then that's definitely the approach
> I'd take..
*IF* you can -- but you can't.
[[ I doubt very much that it *does* say must ... ]]
> Well, first of all "round-robin" DNS is far from random
As percieved by exim, it is.
> it may appear random to the average entity doing repetitive queries,
... at intervals ...
> but it most certianly doesn't appear as "random" to the hosts being hit by
> the service requests resulting from such queries.
I disagree.
> I think.
I don't.
> I'd re-read the DNS RFCs to be sure, but my interpretation of "round-robin"
> is more in line with a circular queue, not a random sprinkler.
I'd assume the RFC follows BIND ... :-))
> Interestingly in quick successive queries for MX records for cl.cam.ac.uk
> shows this to be true.
Yes -- I know how BIND does Round Robin ....
> Unfortunately since the DNS server always returns all of the MX RRs
> without regard to their preference value, we must rely on correct
> handling in the MTA in order to ensure their "round-robin-ness" will be
> preserved.
It is undefined, BUT if you take care, you can use it to give biased or
unbiassed load sharing ....
> Also, in the simplest case of only two equal MX RRs pointing at separate
> hosts, any randomization of the alternating first reply will sometimes
> result in the second reply being selected, which may result in one
> server getting more connections than the other, and in the worst case
> (true random selection by multiple MTAs) one server always getting all
> of the connections.
You've lost me there ...
1) The DNS has caching.
2) there are multiple NSs for zones.
3) some MTAs may do multiple lookups on a name ...
As such, the observered effect is that incomung calls will *not* alternate
between the two servers.
It will appear *random*.
Yes, in the worst case, all *will* go to one host.
Whether exim randomises or not !
> "Doing The Right Thing" for randomization is far from trivial, though
> once you've done it right you can hopefully re-use the code.
I'll let ph10 decide if it's too expensive ...
> Doing it right in this case may not be of much help -- stats at work!
"may" -- possible.
In the current world though, I think it will help.
> Even "Doing The Right Thing" for MX handling without adding randomizaton
> is not necessarily trivial. Ideally "stacks" (FIFO order) of MXs for
> each unique preference value must be constructed, then the stacks must
> be sorted by their preference value but without disturbing their
> internal ordering, then finally selection from the lowest value stack
> must begin until a connection succeeds. This is the only way I can
> think of to preserve the original DNS ordering while still allowing the
> mailer to start with the lowest preference RRs.
Err -- "Doing The Right Thing" should *NOT* "preserve the original DNS ordering"
> # yes, this is really a sequential series of real query examples!
Sure -- with repeated lookups to a single NS without intervening lookups,
this is what one expectes. This is not what exim does ...
My counter example :-)
% date;host -t mx cl.cam.ac.uk ns0.ja.net;echo and;host -t mx cl.cam.ac.uk;date
Thu Nov 21 23:34:23 GMT 1996
cl.cam.ac.uk MX 8 bescot.cl.cam.ac.uk
cl.cam.ac.uk MX 4 heaton.cl.cam.ac.uk
cl.cam.ac.uk MX 10 ppsw3.cam.ac.uk
cl.cam.ac.uk MX 10 ppsw4.cam.ac.uk
cl.cam.ac.uk MX 20 sun2.nsfnet-relay.ac.uk
cl.cam.ac.uk MX 21 sun3.nsfnet-relay.ac.uk
and
cl.cam.ac.uk MX 8 bescot.cl.cam.ac.uk
cl.cam.ac.uk MX 4 heaton.cl.cam.ac.uk
cl.cam.ac.uk MX 10 ppsw3.cam.ac.uk
cl.cam.ac.uk MX 10 ppsw4.cam.ac.uk
cl.cam.ac.uk MX 20 sun2.nsfnet-relay.ac.uk
cl.cam.ac.uk MX 21 sun3.nsfnet-relay.ac.uk
Thu Nov 21 23:34:24 GMT 1996
%
