RFC about 9.3.4 - first query to >=bind.3 caching server always gives sorted order for round robin set
zaphodb--bind at zaphods.net
Thu Feb 8 09:45:53 UTC 2007
On Wed, Feb 07, 2007 at 04:04:10PM +0100, Peter Koch wrote:
> to me this seems more like DNS operational or protocol question than a BIND
> specific issue. Neither the stub resolver nor any intermediaries are
> obliged to rotate the RRSet. The order is undefined and that doesn't
> imply anything.
Well for us it clearly is an operational issue, but on the other hand it
wouldn't be the first time BCP gets implemented in BIND and after that
someone writes an RFC about it.
I'm not sure if its that big a problem that there should be an RFC about it,
which is why my first though was to ask here.
I understand that with BINDs default rotating algorythm beeing cyclic the
obvious reason for the first request to give a sorted answer is that it was
the easiest and most efficient way to implement it.
> The MTA, however, has to follow the order as it arrives.
There you lost me. Why couldn't the MTA just rotate the set itself?
We're not speaking IN MX here, just plain IN A.
> Have you considered spreading the load across multiple MX RRs with equal
> preference values (keeping an eye on DNS packet size), like, e.g., AOL does?
> That is, if you have to use DNS based load distribution at all.
We are considering l3 load balancing but other than kicking dead servers out
of the round-robin set and distributing the load via plain round-robin we have
not used DNS based load balancing - i.e. we never had any weight for entries
or preferences for networks/ASns etcetera just the plain round-robin set.
I will talk to our postmasters about the multiple MX RRs way.
Finagle's Sixth Rule: Do not believe in miracles - rely on them.
More information about the bind-workers