NetBSD Problem Report #42405

From www@NetBSD.org  Thu Dec  3 19:42:13 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id ECDEF63C4CB
	for <gnats-bugs@gnats.netbsd.org>; Thu,  3 Dec 2009 19:42:12 +0000 (UTC)
Message-Id: <20091203194212.BD0C563B844@www.NetBSD.org>
Date: Thu,  3 Dec 2009 19:42:12 +0000 (UTC)
From: cswiger@mac.com
Reply-To: cswiger@mac.com
To: gnats-bugs@NetBSD.org
Subject: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups
X-Send-Pr-Version: www-1.0

>Number:         42405
>Category:       lib
>Synopsis:       libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 03 19:45:00 +0000 2009
>Last-Modified:  Fri Dec 04 21:50:02 +0000 2009
>Originator:     Chuck Swiger
>Release:        5.0
>Organization:
PKIX
>Environment:
N/A
>Description:
From discussion on netbsd-users mailing list:

Trying to perform A lookups before you try AAAA lookups turns out to resolve almost all the problems users were experiencing with sites which do not support IPv6 well, and so this became the default behavior on FreeBSD.

See _dns_getaddrinfo() in http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/getaddrinfo.c?rev=1.91 ; this change was made back in 2005.
>How-To-Repeat:
Use firefox to browse the web and go past popular sites which make use of ad-serving domains which do not handle IPv6 requests very well, and note delays in page rendering resulting from failing/dropped AAAA lookups.
>Fix:
Starting from http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/net/getaddrinfo.c?rev=1.95

--- getaddrinfo.c~	2009-12-02 12:56:20.000000000 -0800
+++ getaddrinfo.c	2009-12-02 12:57:15.000000000 -0800
@@ -1321,16 +1321,16 @@

	switch (pai->ai_family) {
	case AF_UNSPEC:
-		/* prefer IPv6 */
+		/* prefer IPv4 */
		q.name = name;
		q.qclass = C_IN;
-		q.qtype = T_AAAA;
+		q.qtype = T_A;
		q.answer = buf->buf;
		q.anslen = sizeof(buf->buf);
		q.next = &q2;
		q2.name = name;
		q2.qclass = C_IN;
-		q2.qtype = T_A;
+		q2.qtype = T_AAAA;
		q2.answer = buf2->buf;
		q2.anslen = sizeof(buf2->buf);
		break;

>Audit-Trail:
From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups
 before T_AAAA lookups
Date: Thu, 3 Dec 2009 17:39:40 -0500

 On Thu,  3 Dec 2009 19:45:00 +0000 (UTC)
 cswiger@mac.com wrote:

 > Trying to perform A lookups before you try AAAA lookups turns out to resolve almost all the problems users were experiencing with sites which do not support IPv6 well, and so this became the default behavior on FreeBSD.

 I've never had trouble with the default behaviour here, but most ad
 servers are blocked at the proxy level and the v6 addresses are local
 with low latency.

 That said, if others agree that the default should be to resolve A
 records first, it would be nice to have the behaviour configurable via
 an environment variable or a sysctl knob (if doing the configuration
 check at every request is too prohibitive, it at least could be done
 once at libc initialization time by each process, or once in a while,
 etc)...

 Also I suspect tech-net@netbsd.org would be a better place to continue
 this thread than netbsd-users@netbsd.org if consensus isn't yet reached.

 Thanks,
 -- 
 Matt

From: Matthias Scheler <tron@zhadum.org.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups
Date: Thu, 3 Dec 2009 22:58:58 +0000

 On 3 Dec 2009, at 19:45, cswiger@mac.com wrote:
 >> How-To-Repeat:
 > Use firefox to browse the web and go past popular sites which make use =
 of ad-serving domains which do not handle IPv6 requests very well, and =
 note delays in page rendering resulting from failing/dropped AAAA =
 lookups.

 Well, I consider breaking ad-serving domains a plus.

 >> Fix:
 > Starting from =
 http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/net/getaddrinf=
 o.c?rev=3D1.95

 The behaviour should not be hard-coded, it should be configurable.

 	Kind regards

 --=20
 Matthias Scheler                           http://zhadum.org.uk/


From: "Jonathan A. Kollasch" <jakllsch@kollasch.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups
 before T_AAAA lookups
Date: Fri, 4 Dec 2009 00:17:49 +0000

 Our getaddrinfo() needs RFC 3484 support.  FreeBSD has some of this via KAME.

 I strongly object to having getaddrinfo() unilaterally decide to return A
 records before AAAA.

From: Tonnerre Lombard <tonnerre@netbsd.ch>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups
 before T_AAAA lookups
Date: Fri, 4 Dec 2009 10:16:09 +0100

 --+tDoj9+U2XbkXuwv
 Content-Type: text/plain; charset=utf-8
 Content-Disposition: inline

 Salut,

 I think there's a variety of reasons not to change the default here.
 Firstly, most people expect the system to behave like this, i.e.
 resolving IPv6 first and then falling back to IPv4.

 There's also the perception. Most systems provide dual-stack
 functionality; if we choose to go for IPv4 first, the perception
 that nobody uses IPv6 arises.

 Which causes another factor to appear, which is cost. Many large
 IPv4 carriers who are very reluctant about peering do freely peer
 IPv6, either in order to push it or because they aren't very
 large in the IPv6 world. This leads to the fact (it's not fiction)
 that IPv6 traffic is generally a lot cheaper while most IPv4
 traffic, especially for smaller companies, is paid for.

 More than that, if people use IPv6 they can of course profit from
 its nice features (which go way beyond longer addresses).

 Additionally, despite all claims of the contrary, IPv6 _is_ the
 future. This goes so far even that all Tier1 carriers offer IPv6
 connectivity, and at least in Europe it's being adopted all over
 the place. (A big factor being that you no longer have to worry
 about RFC1918 networks for setting up your MPLS backbone.) If
 we reintroduce an IPv4-default because of two or three broken
 DNS servers, that seems like going backwards in time to me. If
 Flea decides to go backwards in time, it's their choice, but I'd
 vote not to.

 It's also not really a problem because in my experience[1] the
 vast majority of DNS servers[2] actually does respond in a way
 to an AAAA query, even if sometimes the reply is a SERVFAIL.

 Under these circumstances I am strongly opposed to reestablishing
 an IPv4-default on the basis that some broken name servers of
 some web site spammers have trouble answering correctly to AAAA
 queries. If we avoid the problem, their bug remains unfixed (be
 it good or bad).

 				Tonnerre

 [1]: I've been using IPv6 in production environments for roughly
      8 years now, and my current employer equips all customers
      with IPv6 addresses and connectivity like it's a matter of
      course.
 [2]: I did encounter a name server once which was very badly
      implemented. Not only did it spawn a new thread for every
      request it received, it also used a NULL-initialized function
      pointer to determine the appropriate lookup function for a
      type of request. Then there was a large switch statement with
      no default section. So, when I sent an AAAA request to the
      DNS server, it collapsed in its entirety.
      Such things exist, but are no reason to refrain from asking
      for AAAA records.

 --+tDoj9+U2XbkXuwv
 Content-Type: application/pgp-signature
 Content-Disposition: inline

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)

 iQIcBAEBAgAGBQJLGNNPAAoJEDO5FOg4ijzZ7egQALrCjC/iRCLxPBTnhEDTLzCD
 36mt36mvRnn1tb4mLojTxErtlmpxdHGgh7v57aDGPFO58IlRk0WjlZH2bl2TSicr
 KMAaIP8LAdqbwLv6MeRQt8nOOGbJO82XAMY1pwfYYnI0mRuZgiq+pqYgrbw0pnlO
 cCK74jggXSHIZIovog9eBwYTTBt2miT/M20boHeheoQh99FJ2FRX1ScwZDcLcxkp
 NIPehFOp61iRrx6wsKYrPEH+qk2/fZE3XciwoQMiHMeKQymkULD4QlLvuChLzsgl
 0X/1o7MWBiIY/QSUKon+h364kuHb6zl6rnHWBHbM70FpU9cqEMkZ5+UOj/8pjodr
 j+7Wh4Rnzl5fJo4MUjVkFoMu9Q+Ao0lMuOvLoz5gs1tdUef4hT2wrBXVbTWQ0Ovn
 SKopi8T3odsiXcSl6QHWBOngS0h2TUJVpT7IljtxAPQEtQABPPIRTDawjN01CIFv
 go8fGPW3jvuX3s2pqi80kJ9N62X/7/JBNhGSlk2zMtY50DyFyjNV1wnzaZFUkAOE
 YpA2kYPI9Hz365Lr8ek4I9EFABaxxF/Id4GBsZry65Wyqaf7xA5xPLkC3u8faJx6
 YckY3CRKfoxN6OxJo3I5m1xgEBu5uw3+bbKQsuBEk6+GnIVFgt31kQwm73wO0es2
 iXfKPpE1vv2fKu+IymsX
 =IMtn
 -----END PGP SIGNATURE-----

 --+tDoj9+U2XbkXuwv--

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups
Date: Fri, 4 Dec 2009 15:13:28 +0100

 On Thu, Dec 03, 2009 at 11:00:15PM +0000, Matthias Scheler wrote:
 >  The behaviour should not be hard-coded, it should be configurable.

 I agree.
 The behaviour might have been a good idea in 2005, but now we either should
 stick with our current behaviour or make it /etc/resolv.conf configurable.

 Martin

From: "Greg A. Woods" <woods@planix.ca>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: lib-bug-people@netbsd.org,
	NetBSD GNATS Administrator <gnats-admin@NetBSD.org>,
	cswiger@mac.com
Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups
Date: Fri, 04 Dec 2009 16:47:39 -0500

 --pgp-sign-Multipart_Fri_Dec__4_16:47:39_2009-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable

 At Fri,  4 Dec 2009 14:15:05 +0000 (UTC), Martin Husemann <martin@duskware.=
 de> wrote:
 Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups befo=
 re T_AAAA lookups
 >=20
 > The following reply was made to PR lib/42405; it has been noted by GNATS.
 >=20
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc:=20
 > Subject: Re: lib/42405: libc: getaddrinfo() should perform T_A lookups be=
 fore T_AAAA lookups
 > Date: Fri, 4 Dec 2009 15:13:28 +0100
 >=20
 >  On Thu, Dec 03, 2009 at 11:00:15PM +0000, Matthias Scheler wrote:
 >  >  The behaviour should not be hard-coded, it should be configurable.
 > =20
 >  I agree.
 >  The behaviour might have been a good idea in 2005, but now we either sho=
 uld
 >  stick with our current behaviour or make it /etc/resolv.conf configurabl=
 e.

 FYI, /etc/resolv.conf already includes an option which can be enabled to
 encourage IPv6 DNS lookups ("options inet6" which turns on RES_USE_INET6)

 Also, if !defined(INET6) then it should _NEVER_ "prefer" IPv6 lookups.
 Half the rest of getaddrinfo.c respects INET6, so I don't know why it
 didn't go all the way.

 I think this change fixes the second complaint:

 Index: getaddrinfo.c
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvs/master/m-NetBSD/main/src/lib/libc/net/getaddrinfo.c,v
 retrieving revision 1.87.2.1
 diff -u -u -r1.87.2.1 getaddrinfo.c
 --- getaddrinfo.c	31 Jan 2009 21:43:33 -0000	1.87.2.1
 +++ getaddrinfo.c	4 Dec 2009 21:43:11 -0000
 @@ -1293,6 +1293,7 @@
 =20
  	switch (pai->ai_family) {
  	case AF_UNSPEC:
 +#ifdef INET6
  		/* prefer IPv6 */
  		q.name =3D name;
  		q.qclass =3D C_IN;
 @@ -1306,6 +1307,9 @@
  		q2.answer =3D buf2->buf;
  		q2.anslen =3D sizeof(buf2->buf);
  		break;
 +#else
 +		/* FALLTHROUGH */
 +#endif
  	case AF_INET:
  		q.name =3D name;
  		q.qclass =3D C_IN;
 @@ -1346,6 +1350,7 @@
  			cur =3D cur->ai_next;
  	}
  	if (q.next) {
 +		/* xxx this looks bogus -- it could/should de-reference q.next to find q=
 2! */
  		ai =3D getanswer(buf2, q2.n, q2.name, q2.qtype, pai);
  		if (ai)
  			cur->ai_next =3D ai;


 --=20
 						Greg A. Woods
 						Planix, Inc.

 <woods@planix.com>       +1 416 218 0099        http://www.planix.com/

 --pgp-sign-Multipart_Fri_Dec__4_16:47:39_2009-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)

 iD8DBQBLGYN7Zn1xt3i/9H8RAr+/AJ0TQagqkRU4pk8ZQf6tSI1irR2UIQCgtCMy
 u9sOToJysQBmA4Zb+NFaYpw=
 =zpit
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Fri_Dec__4_16:47:39_2009-1--

Home	PR Database Search