[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(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?
- To: usagi-users@xxxxxxxxxxxxxx, "users@xxxxxxxx" <users@xxxxxxxx>
- Subject: (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?
- From: Peter Bieringer <pb@xxxxxxxxxxxx>
- Date: Tue, 22 Aug 2006 14:00:31 +0200
- Reply-to: usagi-users@xxxxxxxxxxxxxx
- User-agent: Thunderbird 1.5.0.5 (X11/20060808)
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 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.
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) AAAA www.redhat.com.
ususally no result, because Red Had doesn't provide a AAAA record, so
next query would be made:
v6-2) AAAA www.redhat.com.intranet.domain.example.
in case of no result, next query would be made:
v6-3) AAAA 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 AAAA entry
for catch-all or at least for www.redhat.com.intranet.domain.example
------------------------
First, IPv6 lookups were done:
v6-1) AAAA www.redhat.com.
ususally no result, because Red Had doesn't provide a AAAA record, so
next query would be made:
v6-2) AAAA 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
AAAA 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_aaaa = lookup(AAAA,$host.$suffix)
if ($#result_aaaa > 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_aaaa))
But at least I would expect following:
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
@result_aaaa = lookup(AAAA,$host.$suffix)
@result_a = lookup(A, $host.$suffix)
if ($#result_aaaa > 0 || $#defined result_a > 0) {
break;
};
}
return (sortresults(@result_a, @result_aaaa))
--
Dr. Peter Bieringer http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D mailto:pb@xxxxxxxxxxxx
Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/
OpenBC http://www.openbc.com/hp/Peter_Bieringer/
Personal invitation to OpenBC http://www.openbc.com/go/invita/3889