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 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.