Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups

[Tonnerre Lombard <tonnerre%netbsd.ch@localhost>]

The following reply was made to PR lib/42405; it has been noted by GNATS.

From: Tonnerre Lombard <tonnerre%netbsd.ch@localhost>
To: gnats-bugs%NetBSD.org@localhost
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--