[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(usagi-users 03701) Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
- To: Peter Bieringer <pb@xxxxxxxxxxxx>
- Subject: (usagi-users 03701) Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
- From: JINMEI Tatuya / 神明達哉 <jinmei@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 24 Aug 2006 17:23:50 +0900
- Cc: usagi-users@xxxxxxxxxxxxxx, "users@xxxxxxxx" <users@xxxxxxxx>
- In-reply-to: <44EAF1DF.6090400@bieringer.de>
- Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
- References: <44EAF1DF.6090400@bieringer.de>
- Reply-to: usagi-users@xxxxxxxxxxxxxx
- User-agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
>>>>> On Tue, 22 Aug 2006 14:00:31 +0200,
>>>>> Peter Bieringer <pb@xxxxxxxxxxxx> said:
> Currently, it can return IPv6 and IPv4 addresses of different hosts,
> depending what happen during AAAA lookups while appending a search
> domain. If successful, application gets back e.g.
> AAAA fec0::1 (www.redhat.com.intranet.domain.example)
> A 66.187.224.150 (www.redhat.com)
> Not good, if application prefers IPv6...it connects unexpected to the
> wrong host.
I agree that this behavior is not good, but I'm not sure if I would
call it a bug. To me, a bug is something that makes the program crash
or a behavior that is against the program/protocol/API specification.
In this case, since the getaddrinfo() specification (per RFC3493)
doesn't say anything about this level of 'consistency', I'm afraid we
cannot call the behavior a bug in the sense of specification
violation. (And I would actually not expect the getaddrinfo() spec to
have this level of detail; the internal resolver behavior is a
black-box for getaddrinfo()).
So my vote is that this is
a suboptimal feature, which is better to be changed.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@xxxxxxxxxxxxxxxxxxxxx