From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5103 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general Subject: Re: Resolver overhaul concepts Date: Fri, 09 May 2014 18:04:08 -0700 Message-ID: <536D7B08.8030403@mit.edu> References: <20140504124238.GA24010@brightrain.aerifal.cx> <536665C5.7060302@skarnet.org> <20140504162437.GA27258@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1399683873 12248 80.91.229.3 (10 May 2014 01:04:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 May 2014 01:04:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5108-gllmg-musl=m.gmane.org@lists.openwall.com Sat May 10 03:04:26 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WiviE-0000tl-Ac for gllmg-musl@plane.gmane.org; Sat, 10 May 2014 03:04:26 +0200 Original-Received: (qmail 1758 invoked by uid 550); 10 May 2014 01:04:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1743 invoked from network); 10 May 2014 01:04:24 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qYLCwfbd+wAfegMha5p2SnONiFjd5HJgmdBQiv742H4=; b=IoXjCETn2gW5MpUV8h8eiJpyLCFR9cdPHMJ5ialQeSf1t5l1zQXOM93DHaL6Pya1gh 7WdyQ6BpPuPKVil7ocsQqtGDgUlmu8O7qV6HPSwgTB8wn3jG90R/QvfBuo0gqAZk8iJc d+FZBcE2LxxesxnMcFjralrV/+iV0BQUAdP8uqn57ItVJaa7YKLiULpyfY6hAFHYJI5P JtYW/jnE38FiT75I0IZmJMl7c+nf94ZrqsPCi8RZhDwuEmUy20fNUcjcJBTkYKnShY6H Kh7qh9ASFww7KbNAPcmC55KAk+943jrJi31X5IXr+BDClJQTshnz+aASEcPLRodrjRyW UAEw== X-Gm-Message-State: ALoCoQn8byr/HWmQkcjUv1/cf4OSgOS2gCR4xKyavgMQBxaHTV2QUX3zHwcS9mUwSGdW5TRUjaDh X-Received: by 10.67.22.33 with SMTP id hp1mr7066889pad.134.1399683850864; Fri, 09 May 2014 18:04:10 -0700 (PDT) X-Google-Original-From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <20140504162437.GA27258@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:5103 Archived-At: 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