This is the mail archive of the glibc-bugs@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/304] New: AI_CANONNAME in getaddrinfo(): name is an address; result sorting


According to

  <http://www.opengroup.org/onlinepubs/009695399/functions/getaddrinfo.html>,

regarding AI_CANONNAME

  "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."

  "if the canonical name is not available, then ai_canonname shall
   refer to the nodename argument or a string with the same contents."

The current glibc version of getaddrinfo() attempts to fill
ai_canonname even when the name argument turned out to be an
IP address.  The caller might count on the fact that no DNS server
is ever contacted on his behalf when he provides a numerical address
(for privacy or security reasons).  This is fixed by the attached
patch.

Also

  "the ai_canonname field of the first returned addrinfo structure"

Since the glibc implementation of getaddrinfo() performs sorting of
these structures according to RFC 3484, which one of them is the
first is only known after sorting.  Therefore, the appropriate
ai_canonname field can only be filled after the sort is done.  The
implementation also has the problem that it attemptsto fill the
field for many structures when more than one service is found (first
value of at2, _all_ values of st2 in the nested for loops of
gaih_inet()).  The attached patch also attempts to solve this problem.
We have to be careful with memory in the solution because

  "The freeaddrinfo() function shall support the freeing of
   arbitrary sublists of an addrinfo list originally returned
   by getaddrinfo()"

        ********

There is another issue with AI_CANONNAME that is _not_ addressed
by the attached patch.

  "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)."

  "the terms ``canonical name'' and ``alias''"

  "Domain Name System implementations are expected to interpret
   them as they are used in RFC 1034."

>From RFC 1034:

  "CNAME identifies the canonical name of an alias"

  "CNAME chains should be followed"

  "A name error indicating that the name does not exist.  This
   may include CNAME RRs that indicate that the original query
   name was an alias for a name which does not exist."

This implies that, in the DNS case, ai_canonname should contain
a copy of the "owner" of the found A or AAAA (or A6) resource
record(s) that provided the address(es) that were found, possibly
after having followed a CNAME chain.

The current implementation systematically uses __gethostbyaddr_r(),
which translates into a PTR query in the DNS case, instead of somehow
using the result of the AAAA and A queries that were already performed
(since we must only fill ai_canonname if the name argument is not
null and is an actual name, not an address).  There are problems with
this.  There might not even be a PTR RR even if there is one or more
AAAA or A RR(s).  If there is a PTR RR, it may be on another DNS server
than the AAAA or A one and the caller might not want or expect that
this other server be contacted on his behalf (for privacy or security
reasons).

I don't know how to fix this behavior because I am not familiar with
the implementation of the lookup functions on which getaddrinfo() is
based.

        ********

The proposed patch follows.  I wrote it and I am putting it in the
public domain.  It is relative to cvs version 1.63 of the file.

-- 
           Summary: AI_CANONNAME in getaddrinfo(): name is an address;
                    result sorting
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: a dot guru at sympatico dot ca
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: n/a
  GCC host triplet: n/a
GCC target triplet: n/a


http://sources.redhat.com/bugzilla/show_bug.cgi?id=304

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]