Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Aug 2012 09:32:15 -0700
From:      Maksim Yevmenkin <emax@freebsd.org>
To:        Andrey Zonov <andrey@zonov.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Doug Barton <dougb@freebsd.org>, src-committers@freebsd.org, Hiroki Sato <hrs@freebsd.org>
Subject:   Re: svn commit: r238622 - head/etc/rc.d
Message-ID:  <CAFPOs6rRq8b3HzFuUwCcJtx0KvM=T0yxSeN7csDf6P4gNajdrw@mail.gmail.com>
In-Reply-To: <501B8934.90908@zonov.org>
References:  <201207191536.q6JFabOR094467@svn.freebsd.org> <20120803.055554.1380323232583218022.hrs@allbsd.org> <CAFPOs6rHmMPca7Xzhng82b17RPZObCCP64x%2BHPEBvf7%2BwK3pnQ@mail.gmail.com> <501AF66A.8020804@FreeBSD.org> <CAFPOs6pM8qrR72kOtZzO90wYembNrtzw7=ig-NSfudJZA7bp6Q@mail.gmail.com> <501B8934.90908@zonov.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 3, 2012 at 1:17 AM, Andrey Zonov <andrey@zonov.org> wrote:
> 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?

no, but it would not matter. please see my commit to libc, i.e.

http://svnweb.FreeBSD.org/base?view=revision&revision=238599

before that, results were still sorted according to the rule 9. the
only "hidden" sorting that remains in libc is that if name resolution
contains both AAAA and A records, AAAA records are put before A
records, and, thus, get preferred. however, records order with in a
particular group (AAAA or A) should be unchanged. application has
control over this by giving desired family to getaddrinfo(). it is
reasonable, imo, to return AAAA records when application uses
AF_UNSPEC.

>>> 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.

yes, it does :) but it does not have to be :) yes, sometimes
application has to change, but it ok, imo.

> PS: It would be very useful to have a chance to turn off rule #9 in FreeBSD.

well, may be. my commits to libc and ip6addrctl rc script address our
particular problem and, hopefully, do not break things and/or
introduce unwanted/unexpected behavior

thanks
max



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6rRq8b3HzFuUwCcJtx0KvM=T0yxSeN7csDf6P4gNajdrw>