From owner-svn-src-all@FreeBSD.ORG Fri Aug 3 08:18:01 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 91C911065677 for ; Fri, 3 Aug 2012 08:18:01 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 000838FC16 for ; Fri, 3 Aug 2012 08:18:00 +0000 (UTC) Received: by lbbgm13 with SMTP id gm13so1399828lbb.13 for ; Fri, 03 Aug 2012 01:17:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=efMmlVVUNBnAjfEp9NXPaTyffyALoSDHT18T2BR6/30=; b=Dl2V69DfHIRRJ0EvM/gr8/1c+UI4aKRKU0XLMp01s4a7XCq/lTmTROBgNkKKYULjjI d569FuYrtQBxlydSRtrVwk5T8h3lqK8dQOby/J7d/LS4wa92dlnxSRw8BZ0kqwIAAc0c W4nsZT7gcfReFsFVB+DuTgQ+JmUj4RvMo8t+Y8ipd6/Lo2+ZWxHscJjDAU8vzHUVPKmR c8ONi9f+jyV8AMVHSry/bsBSxMvXVxddoidbPBx6g7nyGjpwpcycu3O+GiTTc6VJYGJN 7MgVrlsgoZzDEeEBLrui5l4VSQ0F9gcC1VI0U8q5LbifVyeTX0Q8LTvMSInTYAxYT+aY DShA== Received: by 10.152.124.180 with SMTP id mj20mr810425lab.43.1343981878912; Fri, 03 Aug 2012 01:17:58 -0700 (PDT) Received: from zont-osx.local (ppp95-165-156-247.pppoe.spdop.ru. [95.165.156.247]) by mx.google.com with ESMTPS id lv13sm8083097lab.8.2012.08.03.01.17.57 (version=SSLv3 cipher=OTHER); Fri, 03 Aug 2012 01:17:58 -0700 (PDT) Message-ID: <501B8934.90908@zonov.org> Date: Fri, 03 Aug 2012 12:17:56 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Maksim Yevmenkin References: <201207191536.q6JFabOR094467@svn.freebsd.org> <20120803.055554.1380323232583218022.hrs@allbsd.org> <501AF66A.8020804@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnD6X4EHpvEqfJZetFp1tQqXGg7U2MGWFfY3D7W0i+E/i5oQfN3sKs/qHWJBakQCaAlMO10 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-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: Fri, 03 Aug 2012 08:18:01 -0000 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