Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
Hi again, thank you for responses, current votes are about some: bug one : standard missing because it's still hard to convince people, I've done now a research of different operating systems. Tested: FreeBSD 6.1 Linux (using glibc) Fedora Core 5 Microsoft Windows XP SP2 Sun Solaris 10 U2 FreeBSD 6.1 is working like expected! Windows XP SP2 make unexpected queries, but did not use the result from them Solaris 10 is acting like Linux (this is interesting...) I've published the details on a dedicated page: http://www.bieringer.de/linux/IPv6/getaddrinfo/index.html Feel free to contribute results of other operating systems, scope of interest would be e.g. AIX and systems using other libcs than glibc (dietlibc, ...). Thank you very much, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED] Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ - The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
> On Tue, 22 Aug 2006 14:00:31 +0200, > Peter Bieringer <[EMAIL PROTECTED]> said: > Currently, it can return IPv6 and IPv4 addresses of different hosts, > depending what happen during lookups while appending a search > domain. If successful, application gets back e.g. > 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. [EMAIL PROTECTED] - The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
On Tue August 22 2006 08:00, Peter Bieringer wrote: > Hi, > > after some discussions with people from Red Hat I'm still not able to > convince them that the behavior of getaddrinfo in glibc is buggy, if > search domains in /etc/resolv.conf are specified. > > Currently, it can return IPv6 and IPv4 addresses of different hosts, > depending what happen during lookups while appending a search > domain. If successful, application gets back e.g. > > 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. > > > Me was told inbetween (and a short look into the source code shows like > that), that getaddrinfo uses DNS lookups more abstract and it can't be > fixed in an easy manner. > > Last note I get was I should provide more information or a whitepaper, > that current behavior is more a bug than a feature...and support/request > of the community is required. > > Therefore my next (last) try is to inform the IPv6 community about this > issue. Please read details below and perhaps vote for > > ( ) bug, should be fixed in > [ ] newer releases > [ ] current release > [ ] older releases, too > ( ) feature, no need to fix it > ( ) ... > > Feel free to add yourself to bugzilla entries shown below. > I would file this under "Bug, should be fixed in all releases". This is a potential security issue. If the name exists, but the requested RR doesn't, the server should return NO_ERROR (it does) which should be considered a successful answer and futher queries for RR type should stop. -vlad - The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
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 lookups while appending a search pb> domain. If successful, application gets back e.g. pb> 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] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ - The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
Re: (usagi-users 03693) glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
Peter Bieringer wrote: Hi, after some discussions with people from Red Hat I'm still not able to convince them that the behavior of getaddrinfo in glibc is buggy, if search domains in /etc/resolv.conf are specified. Currently, it can return IPv6 and IPv4 addresses of different hosts, depending what happen during lookups while appending a search domain. If successful, application gets back e.g. 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. Me was told inbetween (and a short look into the source code shows like that), that getaddrinfo uses DNS lookups more abstract and it can't be fixed in an easy manner. Last note I get was I should provide more information or a whitepaper, that current behavior is more a bug than a feature...and support/request of the community is required. Therefore my next (last) try is to inform the IPv6 community about this issue. Please read details below and perhaps vote for ( ) bug, should be fixed in [ ] newer releases [ ] current release [ ] older releases, too ( ) feature, no need to fix it ( ) ... I agree that this behaviour is bad. So I might vote for bug, fix in current. There are possible security problems with this. It might be interesting to look at bottom of p9 in RFC 1536, it doesn't say much though. My thinking is that you should follow search path until you find an DNS entry (not NXDOMAIN). If you find a match then you should stop, even if there are no addresses. E.g. if getaddrinfo() is called with "www", and there is a match in the beginning of my search path, e.g. www.domain.example that has only e.g. a TXT RR, then I don't think it should continue. Even if getaddrinfo internally first looks for going through the search path if needed, and then repeats the process for A, you would then get the same results. E.g. when you look for for www.redhat.com, you would find that www.redhat.com exists and stop. Even if no records. That is, the internal lookup must distinguish between NXDOMAIN and no records of the requested type. I haven't looked at the code, but don't understand why this is hard to implement... Stig - The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?
Hi,
after some discussions with people from Red Hat I'm still not able to
convince them that the behavior of getaddrinfo in glibc is buggy, if
search domains in /etc/resolv.conf are specified.
Currently, it can return IPv6 and IPv4 addresses of different hosts,
depending what happen during lookups while appending a search
domain. If successful, application gets back e.g.
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.
Me was told inbetween (and a short look into the source code shows like
that), that getaddrinfo uses DNS lookups more abstract and it can't be
fixed in an easy manner.
Last note I get was I should provide more information or a whitepaper,
that current behavior is more a bug than a feature...and support/request
of the community is required.
Therefore my next (last) try is to inform the IPv6 community about this
issue. Please read details below and perhaps vote for
( ) bug, should be fixed in
[ ] newer releases
[ ] current release
[ ] older releases, too
( ) feature, no need to fix it
( ) ...
Feel free to add yourself to bugzilla entries shown below.
BTW: would be great if one can run tests on other libc implementation
like dietlibc or ulibc (or even Microsoft Windows) and report, whether
one acts like the same or different. I provide a special DNS zone for
that, see below.
Thank you very much.
Hopefully, I won't stay alone with my opinion...
Regards,
Peter
*** the details
Related bugzilla entries:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199680
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181061
Red Hat support request: 968402
Hints for local testing using DNS zone data from "getaddrinfo.bieringer.de":
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181061#c4
Happen in glibc versions up to 2.4 (tested on Fedora Core)
Assume: /etc/resolv.conf contains
search intranet.domain.example domain.example
In "short", following happen to an application using getaddrinfo and try
to connect to "www.redhat.com":
A) IPv4-only setup:
---
Following queries were made:
v4-1) A www.redhat.com.
results usually in 66.187.224.150
in case of no result, next query would be made:
v4-2) A www.redhat.com.intranet.domain.example.
in case of no result, next query would be made:
v4-3) A www.redhat.com.domain.example.
no result: client gets no IPv4 address, can't connect
Usual result: client gets A 66.187.224.150 (www.redhat.com)
B) Mixed IPv4/IPv6 setup
First, IPv6 lookups were done:
v6-1) www.redhat.com.
ususally no result, because Red Had doesn't provide a record, so
next query would be made:
v6-2) www.redhat.com.intranet.domain.example.
in case of no result, next query would be made:
v6-3) www.redhat.com.domain.example.
no result: client gets no IPv6 address for now
Now independend IPv4 lookups were done:
v4-1) A www.redhat.com.
results usually in 66.187.224.150
Usual result: client gets A 66.187.224.150 (www.redhat.com)
C) Mixed IPv4/IPv6 setup, intranet.domain.example contains a entry
for catch-all or at least for www.redhat.com.intranet.domain.example
First, IPv6 lookups were done:
v6-1) www.redhat.com.
ususally no result, because Red Had doesn't provide a record, so
next query would be made:
v6-2) www.redhat.com.intranet.domain.example.
results (unexpected) in e.g. fec0::1
Now independend IPv4 lookups were done:
v4-1) A www.redhat.com.
results in 66.187.224.150
Usual result: client gets
fec0::1 (www.redhat.com.intranet.domain.example)
A 66.187.224.150 (www.redhat.com)
In abstract programmers view, following currently happen:
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
@result_ = lookup(,$host.$suffix)
if ($#result_ > 0) {
break;
};
};
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
@result_a = lookup(A, $host.$suffix)
if ($#result_a > 0) {
break;
};
};
return (sortresults(@result_a, @result_))
But at least I would expect following:
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
@result_ = lookup(,$host.$suffix)
@result_a = lookup(A, $host.$suffix)
if ($#result_ > 0 || $#defined result_a > 0) {
break;
};
}
return (sortresults(@result_a, @result_))
--
Dr. Peter Bieringer http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED]
Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/
OpenBChttp://www.openbc.com/hp/Peter_Bieringer/
Personal invitation to OpenBC http://www.openbc.com/go/invita/3889
-
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscri
