public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tore at fud dot no" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-12377-131-KFOMUkBMTO@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-12377-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=12377 --- Comment #18 from Tore Anderson <tore at fud dot no> 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.
next prev parent reply other threads:[~2012-07-31 13:59 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-01-08 20:57 [Bug libc/12377] New: " tore at fud dot no 2011-02-11 15:54 ` [Bug libc/12377] " tore at fud dot no 2011-07-06 20:30 ` rick.jones2 at hp dot com 2011-07-07 9:20 ` tore at fud dot no 2011-07-07 17:25 ` rick.jones2 at hp dot com 2011-07-07 19:37 ` rick.jones2 at hp dot com 2011-07-08 15:17 ` tore at fud dot no 2011-07-08 16:48 ` rick.jones2 at hp dot com 2011-07-09 11:29 ` tore at fud dot no 2011-07-16 5:37 ` nick.jones@network-box.com 2012-02-19 4:23 ` allan at archlinux dot org 2012-02-21 2:06 ` [Bug network/12377] " jsm28 at gcc dot gnu.org 2012-07-27 13:53 ` psimerda at redhat dot com 2012-07-27 14:01 ` psimerda at redhat dot com 2012-07-27 14:07 ` psimerda at redhat dot com 2012-07-27 14:11 ` psimerda at redhat dot com 2012-07-29 8:30 ` psimerda at redhat dot com 2012-07-29 10:41 ` psimerda at redhat dot com 2012-07-31 12:19 ` tore at fud dot no 2012-07-31 13:17 ` psimerda at redhat dot com 2012-07-31 13:34 ` psimerda at redhat dot com 2012-07-31 13:59 ` tore at fud dot no [this message] 2012-07-31 15:01 ` psimerda at redhat dot com 2012-07-31 15:51 ` psimerda at redhat dot com 2012-07-31 18:34 ` tore at fud dot no 2012-07-31 19:00 ` tore at fud dot no 2012-07-31 22:22 ` psimerda at redhat dot com 2012-08-01 9:22 ` tore at fud dot no 2012-08-01 23:16 ` orion at cora dot nwra.com 2012-09-22 15:44 ` psimerda at redhat dot com 2012-11-20 23:16 ` [Bug network/12377] AI_ADDRCONFIG option breaks getaddrinfo() resolution for node-local names and addresses (localhost) psimerda at redhat dot com 2012-11-20 23:18 ` [Bug network/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes psimerda at redhat dot com 2012-12-06 7:04 ` gaofeng at cn dot fujitsu.com 2012-12-18 14:33 ` psimerda at redhat dot com 2012-12-18 14:42 ` [Bug network/12377] getaddrinfo() with AI_ADDRCONFIG won't suppress AAAA queries when only IPv6 loopback and link-local addresses are present psimerda at redhat dot com 2013-08-29 12:45 ` [Bug network/12377] getaddrinfo() with AI_ADDRCONFIG won't suppress AAAA DNS " psimerda at redhat dot com 2014-02-16 18:23 ` jackie.rosen at hushmail dot com 2014-05-28 19:46 ` schwab at sourceware dot org 2014-05-28 19:47 ` schwab at sourceware dot org 2014-06-27 12:32 ` fweimer at redhat dot com 2023-09-20 15:12 ` chrysn at fsfe dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-12377-131-KFOMUkBMTO@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).