> The thread you referenced is all silly; it's a rant about an > implementation detail (NSS) of glibc that does not even apply to > uClibc. If you want to lookup hostnames, you use getaddrinfo.
Whether or not NSS is a glibc implementation detail, getaddrinfo() was designed to accommodate NSS, and because of that, it is a horrible API to perform DNS, with focus on details totally irrelevant to DNS and no way to access and tune important DNS engine knobs. The most obvious flaw is that it is a blocking, synchronous call that performs network operations with no way of specifying a timeout. It's only the first one. > Consider a system behind a restrictive firewall with no access to DNS > except possibly for a local intranet, and minimal outgoing access at > all. A resolver module that caches results locally and routes unknown > requests over a special protocol is perfectly reasonable. Yes, but DNS proxying should be done by the *resolver program*, not by the *client library*. Special-purpose resolvers exist ; no system architecture needs proxying at the client library level. And in any case, no system architecture can be justification for bad API design. -- Laurent _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
