[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?



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