I think it is well known that Round robin DNS load balancing is not a
guaranteed behavior.  The "severe operational problems"  from its
non-support are the fault of unreasonable reliance on insufficient
testing and insufficient analysis of the requirements of DNS resolvers.  
I think the solution here is to get better engineers who read rather
than assume.

This is not a DNS operational issue.

But as a protocol/resolver specification issue, I'd have to say that I
think sorting or randomization should be site specific.  Most of the
time, giving the closest address prefix first, followed by next closest
prefix is the right choice, as it has the best chance of localizing
traffic.  I doubt this will come up on DNSEXT, given the desire to
severely restrict changes to DNS.

                --Dean

On Wed, 12 Dec 2007, Florian Weimer wrote:

> * Tony Finch:
> 
> > Rule 9 of RFC 3484 specifies that the IP addresses (v4 and v6) returned by
> > getaddrinfo() should be sorted according to the size of their common
> > prefix with the local host's chosen source IP address. This defeats DNS
> > round robin load balancing which has led to some severe operational
> > problems. DNS round robin needs to be documented in an RFC, and RFC 3484
> > should be updated with rule 9 deleted or substantially modified for
> > compatibility with DNS round robin.
> 
> I think this belongs to the v6ops working group.  It's a technical
> mistake that RFC 3484 talks about v4 stub resolver behavior at all, and
> that should be fixed.
> 
> I'm not even convinced rule 9 makes sense for IPv6 as it is about to be
> deployed (with PI and routing generally as wild as in IPv4 land), but I
> haven't got any strong feelings about it.
> 
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/dnsop
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop

Reply via email to