[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140510023653.GN26358@brightrain.aerifal.cx>
Date: Fri, 9 May 2014 22:36:53 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: Resolver overhaul concepts
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
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.
