(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 <pb@xxxxxxxxxxxx>]

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