(usagi-users 03696) Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?

Hajimu UMEMOTO <[email protected]> Tue, 22 Aug 2006 23:35:40 +0900
Newsgroups gmane.linux.ipv6.usagi.users,gmane.network.ipv6.general
Organization Internet Mutual Aid Society, YOKOHAMA
Message-ID <ygey7tgltxf.wl%[email protected]>
Hi,

>>>>> On Tue, 22 Aug 2006 14:00:31 +0200
>>>>> Peter Bieringer <[email protected]> said:

pb> after some discussions with people from Red Hat I'm still not able to
pb> convince them that the behavior of getaddrinfo in glibc is buggy, if
pb> search domains in /etc/resolv.conf are specified.

pb> Currently, it can return IPv6 and IPv4 addresses of different hosts,
pb> depending what happen during AAAA lookups while appending a search
pb> domain. If successful, application gets back e.g.

pb>  AAAA fec0::1 (www.redhat.com.intranet.domain.example)
pb>  A 66.187.224.150 (www.redhat.com)

pb> Not good, if application prefers IPv6...it connects unexpected to the
pb> wrong host.


pb> Me was told inbetween (and a short look into the source code shows like
pb> that), that getaddrinfo uses DNS lookups more abstract and it can't be
pb> fixed in an easy manner.

pb> Last note I get was I should provide more information or a whitepaper,
pb> that current behavior is more a bug than a feature...and support/request
pb> of the community is required.

pb> Therefore my next (last) try is to inform the IPv6 community about this
pb> issue. Please read details below and perhaps vote for

pb> ( ) bug, should be fixed in
pb> 	[ ] newer releases
pb> 	[ ] current release
pb> 	[ ] older releases, too
pb> ( ) feature, no need to fix it
pb> ( ) ...

pb> Feel free to add yourself to bugzilla entries shown below.

pb> BTW: would be great if one can run tests on other libc implementation
pb> like dietlibc or ulibc (or even Microsoft Windows) and report, whether
pb> one acts like the same or different. I provide a special DNS zone for
pb> that, see below.

The BSDs getaddrinfo(3) which was derived from KAME doesn't have this
problem.  This problem was fixed in times past.

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[email protected]  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/