From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3170 invoked by alias); 31 Jul 2012 13:59:28 -0000 Received: (qmail 3158 invoked by uid 22791); 31 Jul 2012 13:59:27 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Jul 2012 13:59:13 +0000 From: "tore at fud dot no" To: glibc-bugs@sources.redhat.com Subject: [Bug network/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes Date: Tue, 31 Jul 2012 13:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: network X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tore at fud dot no X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00268.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12377 --- Comment #18 from Tore Anderson 2012-07-31 13:59:09 UTC --- (In reply to comment #16) > > If so, I disagree. > > Disagree with what exactly? With the entire statement. To break it down a bit: > This option is probably meant to guess whether we can sendto() data to this > address I disagree, I believe the purpose of AI_ADDRCONFIG was primarily to suppress IN A and IN AAAA DNS lookups in the case when they are likely to be not useful. Quoting from RFC 2553: - The AI_ADDRCONFIG flag specifies that a query for AAAA records should occur only if the node has at least one IPv6 source address configured and a query for A records should occur only if the node has at least one IPv4 source address configured. > (for connect() it is not necessary as connect() immediately returns > failure for nonroutable addresses) I disagree again. One of the applications that will benefit the most from AI_ADDRCONFIG is a web browser, which can use it to avoid generating IN AAAA DNS queries when looking up hostnames, when running on an IPv4-only machine. (Or avoid IN A lookups when running on an IPv6-only machine.) As you probably are well aware, a web browser will be a heavy user of connect(), while rarely if ever use sendto(). > But I can't think of *any* reason to use this hack Disagree, as above, a web browser has a very good reason to use AI_ADDRCONFIG. > when it's so easy to ask the system if the address is actually routable. Again, disagreed. AI_ADDRCONFIG is useful when looking up names to IP addresses. using DNS. Before knowing the IP address, it is impossible to ask the system whether or not it is usable. > The way I see it, the primary reason for using AI_ADDRCONFIG > is to avoid making lookups from which any results cannot be used. > > And it fails terribly, giving both false positives and false negatives > and even breaking literal IP addresses. As far as I can tell, AI_ADDRCONFIG works perfectly for (forward) DNS lookups, which I belive is what it's primarily meant to do. If I remove all IPv6 addresses except ::1 and look up a name, no IN AAAA queries are sent. Or if I remove all IPv4 addresses except 127.0.0.1, no IN A queries are sent. RFC 3493 changed the definition of getaddrinfo() from the original DNS-only definition in RFC 2553 to a more general one that resembles the one that is included in glibc. However, the example described still revolves around forward DNS IN A/AAAA lookups so I'm not quite sure if the change was a sensible one. There was certainly not much operational experience with it at that point in time. > > words, if there is no IPv4 connectivity, avoid making "IN A" lookups. > > This is exactly what AI_ADDRCONFIG doesn't do. On my system, it does exactly this on my system. I don't see any IN A queries sent to the DNS server when I only have 127.0.0.1 configured on my system, only IN AAAA. > It breaks various non-DNS cases. With that I agree completely. I don't see any good reason to apply AI_ADDRCONFIG logic in other cases than when using DNS. For what it's worth, I believe that Mac OS X still implements getaddrinfo() only when doing forward DNS IN A/AAAA lookups (in other words the original RFC 2553 specification). I can try to get that confirmed if you're interested. > *None* of my objections was DNS-related. All were about either literal > addresses, /etc/hosts names or possible link-local NSS plugins. Ok - I think we're kind of in agreement, then - perhaps talking about two different use cases, really. I see AI_ADDRCONFIG as only useful for DNS ("forward" DNS, i.e. IN A/IN AAAA). However, in that case, it is also *very* useful. However, for it to be useful in the IPv4-only host case (which is presently the most important one, given the amount of defective resolvers embedded in IPv4-only home gateways that choke on IN AAAA queries), you'll also need to disregard the automatically configured link-local IPv6 addresses on the host when deciding whether or not to suppress the IN AAAA query or not, otherwise you'll pretty much never do it. > That said, if bug 14413 was resolved, you could do this sort of black magic > entirely in nss-dns.so. Without it, it's really hard to implement a > working implementation of AI_ADDRCONFIG. > > Maybe you could just specialcase DNS, it's a hack but certainly not worse > than what we're doing now. A hack, perhaps...or simply a return to the good old original RFC 2553 specification. ;-) Tore -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.