Created attachment 6909 [details] Test program demonstrating getaddrinfo issue With today's master, getaddrinfo with AI_CANONNAME yields the right ai_canonname (the result of CNAME resolution but not PTR lookup) if no other hint fields are given. However, if hint.ai_family is set to INET6, it appears to do a PTR lookup. The attached test program demonstrates the problem (the first and third output lines in particular): $ ./a.out ptr-mismatch.kerberos.org AI_CANONNAME alone: www.kerberos.org AI_ADDRCONFIG also: www.kerberos.org ai_family AF_INET : KERBEROS-ORG.MIT.EDU ai_family AF_INET6: Name or service not known
To clarify what's wrong: it was a common historic misunderstanding that "canonical" name meant reverse DNS lookups. This was a cause of bad lookup performance in applications that were using AI_CANNONNAME correctly and not respecting it to perform PTR lookups. For a reference on why the PTR lookup is incorrect, see the following paragraphs in POSIX: From DESCRIPTION of getaddrinfo: "If the AI_CANONNAME flag is specified and the nodename argument is not null, the function shall attempt to determine the canonical name corresponding to nodename (for example, if nodename is an alias or shorthand notation for a complete name). Note: Since different implementations use different conceptual models, the terms ``canonical name'' and ``alias'' cannot be precisely defined for the general case. However, Domain Name System implementations are expected to interpret them as they are used in RFC 1034. A numeric host address string is not a ``name'', and thus does not have a ``canonical name'' form; no address to host name translation is performed. See below for handling of the case where a canonical name cannot be obtained." And from APPLICATION USAGE: "The term ``canonical name'' is misleading; it is taken from the Domain Name System (RFC 2181). It should be noted that the canonical name is a result of alias processing, and not necessarily a unique attribute of a host, address, or set of addresses. See RFC 2181 for more discussion of this in the Domain Name System context." Source: http://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html
Created attachment 6912 [details] Candidate fix I stepped through the code and found that: * In the good case (hint.ai_family == 0), line 569 of gaih_inet does not trigger and we continue on to the loop at line 832, using gethostbyname4_r functions. When the DNS function succeeds, we set canon from the result at line 892. This value of canon is later used for ai_canonname. * In the bad case (hint.ai_family == AF_INET), line 569 of gaih_inet triggers and we use __gethostbyname2_r for the lookup. This branch of the code does not set canon, so later on at line 1119, canon is still NULL. The conditional there kicks in and sets canon using __gethostbyaddr_r on the first address. I think the code which uses __gethostbyname2_r ought to be able to set canon using th.h_name. If I use the attached patch, my test program gives the correct answer with hint.ai_family == AF_INET.
Created attachment 6913 [details] Candidate fix 2 This updated patch is more consistent with how other branches of the function set canon. I believe h->h_name should still be valid by the time canon is used at the end of the function, because it lives in tmpbuf just like it does in the gethostbyname4_r case.
Another approach can be found at: http://pkgs.fedoraproject.org/cgit/glibc.git/plain/glibc-fedora-gai-canonical.patch which completely avoids the gethostbyname2_r path if AI_CANONNAME is requested, and also rips out the code to use gethostbyaddr_r for canonname. Although that change is much more invasive than my candidate fix, it has received more testing.
Fixed by b957ced.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
*** Bug 17215 has been marked as a duplicate of this bug. ***