[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <536D7B08.8030403@mit.edu>
Date: Fri, 09 May 2014 18:04:08 -0700
From: Andy Lutomirski <luto@...capital.net>
To: musl@...ts.openwall.com
Subject: Re: Resolver overhaul concepts
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
