From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21734 invoked by alias); 12 Nov 2018 11:21:02 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 21715 invoked by uid 89); 12 Nov 2018 11:21:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=phillip, accurate, networks, hellewell X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Nov 2018 11:20:59 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7C8EAC050DF3; Mon, 12 Nov 2018 11:20:58 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.36.118.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D075D1974D; Mon, 12 Nov 2018 11:20:57 +0000 (UTC) From: Florian Weimer To: Phillip Hellewell Cc: libc-help@sourceware.org Subject: Re: RFC 6724 References: Date: Mon, 12 Nov 2018 11:21:00 -0000 In-Reply-To: (Phillip Hellewell's message of "Sun, 11 Nov 2018 13:45:11 -0700") Message-ID: <87lg5yr17v.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00007.txt.bz2 * Phillip Hellewell: > Assuming the comments in gai.conf are accurate, glibc still use > obsolete RFC 3484 for address selection. > > RFC 6724 came out in 2012, so why does glibc still use RFC 3484 rules? > > The changes since RFC 3484 can be seen here: > https://tools.ietf.org/html/rfc6724#appendix-B RFC 3484 has always been rather problematic (particularly Rule 9, which we do not implement). I seriously doubt that there is any benefit from address sorting. It's a layering violation, and it makes renumbering harder because you now need to consider the impact on address sorting. Its core assumptions are also quite wrong on many networks (e.g., private addresses often have less georeplication than public Internet service, so public addresses are closer by). In any case, I think address sorting should be performed by the caching DNS resolver, not the stub resolver. The caching resolver can obtain more topology information. For individual, short-lived application processes, this is very hard. On the stub resolver side, the only thing that remains is the A/AAAA sorting policy because the caching DNS resolver does not determine that. Do you have a setup that actually relies on address sorting? Do you have any examples where DNS provides a set of addresses for a single name with different labels/precedence, so that sorting the addresses actually has an effect? Currently, we have a lot of code which is questionable at best when it makes a difference, but it's mostly unused. I would like to remove it, rather than keep maintaining it. Thanks, Florian