From owner-svn-src-head@FreeBSD.ORG Fri Aug 3 16:32:16 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA5EC106564A; Fri, 3 Aug 2012 16:32:16 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 386F38FC08; Fri, 3 Aug 2012 16:32:16 +0000 (UTC) Received: by qabg1 with SMTP id g1so4893074qab.13 for ; Fri, 03 Aug 2012 09:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YpugCGgsnxigWQJZBt5fxmIXxd1EBztWx16mWB71KlA=; b=ck9qOsuGlD60gdDvTbMrkMcpVSpGwK/QjM2gcc2mfHIVAx7d2xVqLxQcq2B02tzk0y Zxa/PPWdftnodXABGfKF2s5yg5J3g6xv9SiTQ8DgeH931MsvmSgrVYbxmIDS5tLQnLrj uDcSPK/PgDgRcu/o0VQOV9ANclugqKOVXlfCd0UfnWMfOJXNXFP8DOpOjRaB8b+HW8VP v95B5wf8eaNOFmxtKZWQ6d4G5aVcYSyEwLaJYFtrDrZzc6QTsgcFH7NqMg5UsJj/a8Q4 L6m7BNPQEN6rbRZ0cFcQRn9NuwVa7GYoMcdEZ2+OWI/ESQCZdOEluh9Kaa3JRNq/ERdp vBAg== MIME-Version: 1.0 Received: by 10.224.39.204 with SMTP id h12mr3698952qae.52.1344011535632; Fri, 03 Aug 2012 09:32:15 -0700 (PDT) Sender: maksim.yevmenkin@gmail.com Received: by 10.224.216.72 with HTTP; Fri, 3 Aug 2012 09:32:15 -0700 (PDT) In-Reply-To: <501B8934.90908@zonov.org> References: <201207191536.q6JFabOR094467@svn.freebsd.org> <20120803.055554.1380323232583218022.hrs@allbsd.org> <501AF66A.8020804@FreeBSD.org> <501B8934.90908@zonov.org> Date: Fri, 3 Aug 2012 09:32:15 -0700 X-Google-Sender-Auth: xcLFXZ91YgxTAO8BrzR22YCd-o8 Message-ID: From: Maksim Yevmenkin To: Andrey Zonov Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Doug Barton , src-committers@freebsd.org, Hiroki Sato Subject: Re: svn commit: r238622 - head/etc/rc.d X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:32:17 -0000 On Fri, Aug 3, 2012 at 1:17 AM, Andrey Zonov 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