(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]>
| 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/