[Bug 1057526] Re: getaddrinfo returns PTR name in ai_canonname when using DNS

Thu Oct 17 15:39:57 UTC 2013

Launchpad has imported 6 comments from the remote bug at
http://sourceware.org/bugzilla/show_bug.cgi?id=15218.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2013-03-01T06:19:38+00:00 Greg Hudson wrote:

Created attachment 6909
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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1057526/comments/6

------------------------------------------------------------------------
On 2013-03-01T19:55:54+00:00 Bugdal wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1057526/comments/7

------------------------------------------------------------------------
On 2013-03-02T06:29:42+00:00 Greg Hudson wrote:

Created attachment 6912
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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1057526/comments/8

------------------------------------------------------------------------
On 2013-03-02T06:50:40+00:00 Greg Hudson wrote:

Created attachment 6913
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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1057526/comments/9

------------------------------------------------------------------------
On 2013-03-02T07:11:43+00:00 Greg Hudson wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1057526/comments/10

------------------------------------------------------------------------
On 2013-10-17T14:36:39+00:00 Andreas Schwab wrote:

Fixed by b957ced.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1057526/comments/12

** Changed in: eglibc
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/1057526

Title:
  getaddrinfo returns PTR name in ai_canonname when using DNS

Status in Embedded GLIBC:
  Fix Released
Status in “eglibc” package in Ubuntu:
  Incomplete
Status in “eglibc” source package in Precise:
  Incomplete
Status in “eglibc” package in Debian:
  New
Status in “eglibc” package in Fedora:
  Unknown

Bug description:
  Got pinged about this, not fixed in 12.04 yet. From the Redhat bug:

  "We have verified that getaddrinfo() does reverse address calls to DNS
  when AI_CANONNAME is passed in hints.ai_flags and returns the PTR name
  of the forward resolved ip address as Canonical name.

  The canonical name is arguably not what is returned by the PTR record
  for various reasons. Aside the fact that PTR record are often not
  under control of the the same people that control the A name, A names
  can also be roundrobin names and return multiple addresses. Picking
  one and returnings its PTR as canonical name seem highly questionable.

  A CNAME -> A name resolution is welcome as the A name is arguably the
  Canonical name of a CNAME. But getaddrinfo shouldn't do PTR requests
  to the DNS.

  We found this when testing ssh+GSSAPI auth on laptops that can properly set the A record for their name usin dynamic DNS updates but cannot change the PTR record of whatever network they are currently travelling in.
  This breaks kerberos which needs the canonical (A record) name to construct the principal name used to request a ticket when rdns = false is set in krb5.conf and GSSAPITrustDNS is set to no in ssh (the default)."

To manage notifications about this bug go to:
https://bugs.launchpad.net/eglibc/+bug/1057526/+subscriptions