svn commit: r238622 - head/etc/rc.d

Andrey Zonov andrey at zonov.org
Fri Aug 3 08:18:01 UTC 2012


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


More information about the svn-src-all mailing list