Bug 199680

See here for FC5, getnameinfo resolves addresses in not expecting order, not a
postfix problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181061

Affected glibc version here: glibc-2.3.4-2.19

See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190495#c29

The behaviour wrt to the search path hasn't changed.  Ever, I think.  I see
nothing wrong.  If the resolv.conf file is so dangerously written it's not up to
the implementation to protect the user.

getaddrinfo returns addresses according to the sorting criteria.  It's up to the
application to use the values correctly.

If you ever had a point (which isn't at all obvious from all that nonsense in
the earlier comments) and it is not based on your opinion (like, how the search
path should be handled) make it.

Sure you read my comment
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190495#c29, it need some
time by me to detect from the seen DNS queries in wrong order, what really
causes the problem. It's the lookup mechanism itself. Like mentionend in the
other bugzilla entry, current version works like:

for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
 $result_aaaa = lookup(AAAA,$host.$suffix)
 if (defined $result_aaaa) {
   break;
 };
};
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
 $result_a = lookup(A, $host.$suffix)
 if ($defined result_a) {
   break;
 };
};
sortresults($result_a, $result_aaaa)


/etc/resolv.conf files usually contain for internal hosts like:

domain intranet.domain.example
search intranet.domain.example domain.example

So in IPv4/IPv6 enabled environments if ever client prefers IPv6 connect, it
takes the first AAAA result from getaddrinfo.

Current behavior leads during getaddrinfo to lookups:
AAAA www.redhat.com.intranet.domain.example.
AAAA www.redhat.com.domain.example.
AAAA www.redhat.com.
A www.redhat.com.

If DNS administrator administrate at least intranet.domain.example and add a
dedicated entry for "www.redhat.com.intranet.domain.example." or a catch-all,
and client IPv6-enabled, administrator can control to deliver a wrong IPv6
address to clients.

If implementation is like

for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
 $result_aaaa = lookup(AAAA,$host.$suffix)
 $result_a = lookup(A, $host.$suffix)
 if (defined $result_aaaa || $defined result_a) {
   break;
 };
}
sortresults($result_a, $result_aaaa)

such can only happen, if www.redhat.com neither provides an A nor an AAAA record
at all, which results in the same behavior of current IPv4-only environments.

Should I open a new bug to track this issue with a better topic like
"getaddrinfo can return addresses of different hosts in case of IPv4 and IPv6
and search prefices are used"?

Since IPv6 implementation was added to glibc, it's definitly a behavior change.

BTW: your comment "It's up to the application to use the values correctly" is
easy written, but how should application know, that the IPv6 address returned by
getaddrinfo is from a different hostname lookup than the IPv4 one.

Clarify summary to the real issue.

See also comment from Jeroen Massar in
https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c9, which mention, that
current implementation is not according RFC.

BTW: is this bug locked? I can't reopen it, but I thought I am the owner...

Grmm, can one fix bugzilla also to rewrite URLs proper after submission...here
the correct one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181061#c9

See also discussions 
users:
http://www.mail-archive.com/users@ipv6.org/msg02355.html ff
usagi-users:
http://www.linux-ipv6.org/ml/usagi-users/msg03690.html ff

All of the replies tell me, that is is a bug and also interesting, that in *BSD
it was already fixed some time ago.

Just note how on an IPv6 enabled Microsoft Windows XP SP2 works:

scenario:
additional search domains: 2.getaddrinfo.bieringer.de  3.getaddrinfo.bieringer.de

telnet www.redhat.com 80

triggers following lookups:

AAAA? www.redhat.com. (32)
AAAA? www.redhat.com.2.getaddrinfo.bieringer.de. (59)
 results in  www.redhat.com.2.getaddrinfo.bieringer.de. AAAA fec0::2 (148)
A? www.redhat.com. (32)
 results in www.redhat.com. A 209.132.177.50 (150)
 
While also XP starts not needed query for AAAA
www.redhat.com.2.getaddrinfo.bieringer.de. it is smart enough to give "A
209.132.177.50" a precedence and connects to 209.132.177.50 port 80.

There must be a "smart" mechanism, because it does normally also prefer IPv6
instead of IPv4 which can be easily tested executing "telnet www.bieringer.de 80".

Linux with current glibc would connect to fec0::2 port 80

So now Linux would have a different behavior than *BSD and Microsoft Windows XP.

* From solaris man pages

SunOS 5.10          Last change: 16 Mar 2004  
Sockets Library Functions                    getaddrinfo(3SOCKET)

     AAAA  records  and  A records, and getaddrinfo() returns the
     combined results of both queries. Any IPv4  addresses  found
     are returned as IPv4-mapped IPv6 addresses.
     ...
    AF_INET6 addresses returned by the fourth argument of getad-
     drinfo() are ordered according to the algorithm described in
     RFC 3484, Default Address Selection  for  Internet  Protocol
     version  6 (IPv6). The addresses are ordered using a list of
     pair-wise comparison rules which are applied in order. If  a
     rule determines that one address is better than another, the
     remaining rules are irrelevant to the  comparison  of  those
     two  addresses. If two addresses are equivalent according to
     one rule, the remaining rules  act  as  a  tie-breaker.  The
     address  ordering  list of pair-wise comparison rules follow

Additional notes : http://www.bieringer.de/linux/IPv6/getaddrinfo/index.html