Re: Socket.gethostbyname and Reverse Lookups: A Strange and Terrible Saga

From: "Gary Wright" <[e-mail]>
>
> The code you showed is a bit odd.  If getaddrinfo() returns a result  
> then
> 
>    res->ai_cnonname
> 
> should point to the hostname but only if the AI_CANONNAME flag was set
> in the call to getaddrinfo.  Try adding:
> 
>    hints.ai_flags = AI_CANONNAME
> 
> and see if you get something useful back in ai_canonname.

Right, that was what my original code was doing, here:

http://cila-search.net/~billk/debug/getaddrinfo/

It does set AI_CANONNAME.  Basically my code was derived directly
from Ruby's make_hostent_internal() in socket.c (used by Ruby's
Socket.gethostbyname.)

The code I pasted into the email, was the version modified by
the "@linux-ipv6.org" guy, who was telling me to use getnameinfo()
instead.


> It looks like Ruby 1.8 sets CANONNAME when it calls getaddrinfo so it is
> a bit puzzling as to why it isn't working on your system, perhaps a DNS
> configuration issue?

Well, over the past 3 days I have not only tried my AI_CANONNAME
code on two different debian etch systems, I've asked others on
IRC to try it as well, and I've riddled the GNU libc getaddrinfo.c
implementation with over 140 printouts to trace the execution of
getaddrinfo() ...

All evidence so far indicates that it is not just a local problem.

Note, I'm not altogether surprised it worked for you on OS X, 
because it also used to work on all my previous linux OS's I still
have available for testing... But something has apparently changed
recently.

One thing I don't know how to answer is whether the "@linux-ipv6.org"
guy is correct, and getaddrinfo() is not required to do reverse
lookups; or whether he's wrong and getaddrinfo() is now broken on
debian etch and unstable.


Regards,

Bill