Re: Resolver overhaul concepts

[Andy Lutomirski <luto@amacapital.net>]

On 05/04/2014 09:24 AM, Rich Felker wrote:
> On Sun, May 04, 2014 at 05:07:33PM +0100, Laurent Bercot wrote:
>>
>>  I believe the very first thing to address is what exactly you call
>> a resolver.
> 
> There are some legacy dn_*/res_* interfaces in demand which are
> presently supported only poorly or not at all. Part of the side goal
> of the resolver overhaul is to provide them cleanly without code
> duplication. But for the most part, "resolver" means "getaddrinfo"
> since it is the only standard, non-deprecated interface to name
> resolution.
> 
>>  getaddrinfo() is a horrible interface, and one of the reasons why
>> is that it is loosely designed. Not much is standardized, and it's up
>> to you to decide exactly what to do with it; it's important to be
>> clear about what is implemented, and to document it, because not all
>> applications have the same expectations, and it's very easy to get
>> confused when the resolution path is unexpected.
> 
> It's standardized by POSIX, and the POSIX text is sufficient to tell
> you how to use it for all portable usages. Most of the confusion/mess
> comes from non-conforming implemnentations, particularly in the area
> of returning wrong error codes.
> 
>>  glibc's getaddrinfo() is the entry point to the NSS layer, which
>> can basically implement *any* kind of "name resolution". AFAICT,
>> it's not a goal of musl to reimplement the whole NSS spaghetti
>> monster, but some applications will depend on /etc/nsswitch.conf
>> or something similar; even without supporting /etc/nsswitch.conf,
>> it would be nice to provide a mechanism to selectively enable/disable
>> at least /etc/hosts lookup and DNS lookup. The current resolution
> 
> 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.

--Andy