Home > linux, software > gethostbyname3 & gethostbyname4

gethostbyname3 & gethostbyname4

April 22nd, 2010 Leave a comment Go to comments

I was queried recently about the semi-mysterious and undocumented gethostbyname3_r() and gethostbyname4_r() functions within glibc, and noticed that there’s little googleable available on the topic.

A quick summary: These functions are getaddrinfo() backends – they are not available as public functions for users (though you can do similar tricks as nscd does if you really want to get at them) and they are further extensions of the gethostbyname2_r() function. If you want to use their functionality, just use appropriate getaddrinfo() incanations.
The functions are provided by the appropriate NSS backends and not all backends might provide them.

gethostbyname3_r() also retrieves TTL and canonical hostname (another hidden interface getcanonname_r() also does that) information for the host in single step.

gethostbyname4_r() is much more interesting. First, it does not return hostents but a more extended gaih_addrtuple format (see <nss.h>) that is more akin to struct addrinfo. Even more importantly, the lookup is not limited to a particular address family but returns information for all available AFs.

This means that AF_UNSPEC lookup does not need to call gethostbyname3_r() for AF_INET and then AF_INET6, but the gethostbyname4_r() NSS backend can do the lookup for both at once – in case of /etc/hosts the file is scanned once while in case of DNS both DNS requests are dispatched in parallel instead of in sequence. (…which can lead to infamous strange problems with some cheap DSL routers that will just ignore one of the queries and all queries will start to hang – this is why Debian has (had?) disabled gethostbyname4_r().)

In case you need to use the functions for some reason, glibc:nscd/ai_cache.c is simpler usage example than getaddrinfo() source.

Categories: linux, software Tags: , ,
  1. Bruce Bushby
    October 14th, 2010 at 11:23 | #1

    I was wondering if Suse and RHEL both have the same “nscd” bug whereby “nscd” does not cache the TTL of the “CNAME”, instead it caches the TTL of the “A” record the CNAME is pointing to.

    We recently lost one of our dns servers which caused a lot of pain with systems slowing down to a crawl. Given that a single ( ssh ‘date’ ) command will generate 14 dns requests, multiply that by the 5sec timeout (first dns server in resolv.conf bad) and a ssh connection can take 50seconds…..so We thought we would use “nscd” to only cache host information.

    Our servers have their FQDN in the dns….and then various CNAMES which are descriptive in their relation to services. Our servers FQDN “A” record has a TTL of 5hours, but our CNAMES have a TTL of 1min, this allows us to fail over to “DR” by simply changing the dns…..this is where we find the bug.

    If I restart “nscd” (empty cache) and do a single lookup of a CNAME, I find the “epoch” associated with the CNAME is actually the epoch of the A record the CNAME points to.

    From what I can tell, this affects RHEL 5.3 (glibc-2.5-34) and Fedora 12(glibc-2.12-3). I did download “glibc-2.5-20061008T1257″ and looked into “aicache.c” … but my C is too weak.

    I’m happy to do the compiling and testing…if someone wants to have a go fixing the bugs.


  1. No trackbacks yet.

9 × = thirty six