From owner-svn-src-all@FreeBSD.ORG Sun Aug 5 10:26:29 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 410F7106566B; Sun, 5 Aug 2012 10:26:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id C2ED08FC12; Sun, 5 Aug 2012 10:26:28 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 230E6358C5F; Sun, 5 Aug 2012 12:26:28 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id F343A2847B; Sun, 5 Aug 2012 12:26:27 +0200 (CEST) Date: Sun, 5 Aug 2012 12:26:27 +0200 From: Jilles Tjoelker To: Hiroki Sato Message-ID: <20120805102627.GD99630@stack.nl> References: <501AF66A.8020804@FreeBSD.org> <20120803.124305.1981901625663633450.hrs@allbsd.org> <20120803.131746.1643150967050340012.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120803.131746.1643150967050340012.hrs@allbsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, dougb@FreeBSD.org, emax@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r238622 - head/etc/rc.d X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 10:26:29 -0000 On Fri, Aug 03, 2012 at 01:17:46PM +0900, Hiroki Sato wrote: > Hiroki Sato wrote > in <20120803.124305.1981901625663633450.hrs@allbsd.org>: > hr> Maksim Yevmenkin wrote > hr> in : > hr> em> of course :) we have ipv4 systems in production that make use of > hr> em> getaddrinfo(3) api. when a particular dns name is resolved, and, > hr> em> multiple A records are returned, the results get sorted according to > hr> em> the "default" address selection policy. rfc3484 has a set of rules > hr> em> according to which results should be sorted. all of the rules do not > hr> em> apply in our case, except one - the rule #9. the idea is that ipv4 > hr> em> addresses are "converted" to ipv6 addresses and then longest prefix > hr> em> match sorting is applied. in other words, if your system ip address > hr> em> happens to share high bits with the ip address from the A record, the > hr> em> IP address from the A record will always be preferred. of course, > hr> em> longest prefix match is performed without any extra information such > hr> em> as netmask and/or cidr. it really is just matching high bits of the > hr> em> address. > hr> em> so, what we found out, is that some systems tend to favor a particular > hr> em> ip address (from a bunch of ip addresses returned by name resolution) > hr> em> because 4 high bits were the same. basically, round-robin dns was > hr> em> completely shot. > hr> Is that issue solved by applying the attached patch and setting > hr> net.inet6.ip6.longestmatch_mapped=0? > hr> I do not think it is a good idea to use the empty rule to solve it > hr> because if the system has to support IPv6 as well the empty rule has > hr> negative effect. Adding flag to the IPv4 address line in the policy > hr> or adding a sysctl sounds a reasonable solution to me. > Gr, I got a wrong idea about the issue. What you want is to disable > longest match in the dest addr selection. It needs a change in > comp_dst() in getaddrinfo.c. In glibc, getaddrinfo() was changed to ignore common IPv4 address prefixes outside the netmask. This avoids breaking DNS round robin but still prefers truly local services. -- Jilles Tjoelker