Re: Re: Resolver overhaul concepts

[Rich Felker <dalias@libc.org>]

On Fri, May 09, 2014 at 06:04:08PM -0700, Andy Lutomirski wrote:
> > The policy for supporting something like nss has always been that musl
> > implements a perfectly reasonable public protocol for providing any
> > back-end you want: the DNS protocol. You can run a local daemon
> > speaking DNS and serving names from any backend you like, and this is
> > the correct way to achieve it (rather than linking random buggy,
> > likely-not-namespace-clean libraries into the application's address
> > space). In order to make this the most useful, though, musl should
> > support nameservers on non-default ports (is there a standard syntax
> > for this, or can we support one without breaking anything?), and it
> > would also be nice to be able to override resolv.conf on a per-process
> > basis (e.g. via the environment).
> 
> How about 'nameserver /path/to/unix/socket'?  If glibc supported that,
> too, it might solve a lot of problems involving systemwide resolvers and
> containers.
> 
> This might have to be 'unixsocknameserver /path/to/unix/socket' or
> something for better interoperability.

I don't see any convincing reason to support this. It greatly
complicates the lookup code (having to have 2+ sockets instead of just
one, having to support different address/protocol families, ...) and
doesn't let you do anything you can't already do with AF_INET[6] and
udp. There's also no precedent, which rather defeats the principle of
not inventing new mechanisms for something where there's already a
fully-general option available.

Rich