From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5055 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.linux.lib.musl.general Subject: Re: Resolver overhaul concepts Date: Sun, 04 May 2014 17:07:33 +0100 Message-ID: <536665C5.7060302@skarnet.org> References: <20140504124238.GA24010@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1399219664 29740 80.91.229.3 (4 May 2014 16:07:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2014 16:07:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5059-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 04 18:07:39 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 1Wgyx0-0003td-J1 for gllmg-musl@plane.gmane.org; Sun, 04 May 2014 18:07:38 +0200 Original-Received: (qmail 13395 invoked by uid 550); 4 May 2014 16:07:37 -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 13384 invoked from network); 4 May 2014 16:07:37 -0000 X-SourceIP: 80.111.163.198 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <20140504124238.GA24010@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:5055 Archived-At: I believe the very first thing to address is what exactly you call a resolver. 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. 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 policy is hardcoded as "/etc/hosts, then DNS, and nothing else", which is a very sensible default, but probably shouldn't be the only alternative - or if it is, it should be made abundantly clear. > The concepts of the new DNS query backend are not really solid yet. > One idea is that it should support the "search"/"domain" functionality > of resolv.conf to allow querying multiple seach suffixes in parallel > and returning as soon as there's a (possibly zero-length) initial run > of negative results followed immediately by a positive result. The > cleanest way to implement this kind of thing may be using a callback > function for writing each packet and for reading the responses; > otherwise, storing all the queries and responses as full DNS packets > would take an unwantedly-large amount of space. This is the approach I used in s6-dns (src/libs6dns/s6dns_resolveq.c) and it has worked fine for me so far. I don't think the amount of space is a concern here: the typical search line is very short - 3 to 4 suffixes at most. You will have to store the queries anyway to check the responses against them. Another question that comes to mind is the timeout and retry policy. This is network, it's going to suck; this is DNS, it's going to suck even more. getaddrinfo() doesn't allow the user to specify a timeout (yay for unboundedly synchronous network-facing interfaces), so it's up to musl to decide what to do: do you resend a query after a soft timeout ? do you have a hard timeout after which you report failure ? or do you block indefinitely ? Doing network communications the right way (especially with an old and ugly protocol) is complex. It should be way outside the scope of a libc. glibc people have it easy: the DNS part of NSS directly ties into libresolv, so they have a full-fledged resolver to use. I say we should do the same and tie musl to libs6dns. :P -- Laurent, forhttp://skarnet.org/software/s6-dns/getaddrinfo.html