On 8/3/12 2:22 AM, Maksim Yevmenkin wrote:
i just wanted to make sure that there is a way to absolutely make sure
that there is no default address selection policy installed. the wide
know rule 9 of rfc 3484 is really messing things up for dns-style load
balancing. even when ipv6 is not used.
Did you try an empty config file?
Maksim, can you say more about this? Or point me to a reference that has
the discussion?
of course :) we have ipv4 systems in production that make use of
getaddrinfo(3) api. when a particular dns name is resolved, and,
multiple A records are returned, the results get sorted according to
the "default" address selection policy. rfc3484 has a set of rules
according to which results should be sorted. all of the rules do not
apply in our case, except one - the rule #9. the idea is that ipv4
addresses are "converted" to ipv6 addresses and then longest prefix
match sorting is applied. in other words, if your system ip address
happens to share high bits with the ip address from the A record, the
IP address from the A record will always be preferred. of course,
longest prefix match is performed without any extra information such
as netmask and/or cidr. it really is just matching high bits of the
address.
so, what we found out, is that some systems tend to favor a particular
ip address (from a bunch of ip addresses returned by name resolution)
because 4 high bits were the same. basically, round-robin dns was
completely shot.
RFC3484 completely breaks round-robin DNS. It's clearly that rule #9
should not apply if resolved name has only A records. That problem was
discussed many times at ietf.org, but authors don't want to understand
people. For example, for us the problem will be huge when Windows users
will update their systems.
PS: It would be very useful to have a chance to turn off rule #9 in FreeBSD.
--
Andrey Zonov
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
