On Fri, Apr 25, 2014 at 03:58:44PM -0700, Andrew Lutomirski wrote: > > https://sourceware.org/ml/libc-alpha/2012-12/msg00416.html > > I've never understood why something like nscd is even worth trying to > support. There's a simple, well specified protocol that program can > use to talk to a DNS resolver. It's called DNS. Why try to shoehorn > it into something else when all you're likely to do is come up with a > poor imitation of what you get by sending DNS queries over DNS to a > local resolver? Well, nscd does a lot more than just DNS. > I'm sure it would be possible to improve/rewrite nscd, but at > best you'll match the quality of something like unbound. And you'll > never be compatible with all the third-party resolver clients out > there. Third-party resolver clients are a valid concern (lwres? app-specific resolvers?). It is interesting that historically, /etc/resolv.conf was the configuration for just the stub resolver built into the C library, but now it has become the configuration for third-party resolvers as well. >From the man page lwres(3): The lwresd library implements multiple name service APIs. The standard gethostbyname(), gethostbyaddr(), gethostbyname_r(), gethostbyaddr_r(), getaddrinfo(), getipnodebyname(), and getipnodebyaddr() functions are all supported. To allow the lwres library to coexist with system libraries that define functions of the same name, the library defines these functions with names prefixed by lwres_. To define the standard names, applications must include the header file <lwres/netdb.h> which contains macro definitions mapping the standard function names into lwres_ prefixed ones. Operating system vendors who integrate the lwres library into their base distributions should rename the functions in the library proper so that the renaming macros are not needed. That last sentence is intriguing to me. Does that mean we could replace/override the dumb stub resolver in glibc with lwres/lwresd system-wide to solve the DNS failover problem? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
