From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8457 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Would love to see reconsideration for domain and search DNS keywords Date: Fri, 4 Sep 2015 14:04:29 -0400 Message-ID: <20150904180429.GT17773@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1441389896 2241 80.91.229.3 (4 Sep 2015 18:04:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Sep 2015 18:04:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8469-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 04 20:04:45 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZXvLv-0007JY-Vl for gllmg-musl@m.gmane.org; Fri, 04 Sep 2015 20:04:44 +0200 Original-Received: (qmail 3834 invoked by uid 550); 4 Sep 2015 18:04:42 -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 3813 invoked from network); 4 Sep 2015 18:04:41 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8457 Archived-At: On Fri, Sep 04, 2015 at 12:11:36PM -0500, Andy Shinn wrote: > I'm writing the wonderful musl project today to open discussion about the > future possibility of DNS search and domain keyword support. We've been > using musl libc (by way of Alpine Linux) for new development of > applications as containers that discover each other through DNS and other > software defined networking. > > In particular, we are starting to use applications like SkyDNS, Consul, and > Kubernetes, all of which rely on local name resolution in some way using > search paths. Many users of the Alpine Linux container image have also > expressed their desire for this feature at > https://github.com/gliderlabs/docker-alpine/issues/8. > > On the functional differences between glibc page, the domain and search > keyword "Support may be added in the future if there is demand". So please > consider this request an addition to whatever demand for the feature > already exists. > > Thank you for your time and great work on the musl libc project! I think this is a reasonable request. I'll look into it more. One property I do not want to break is deterministic results, so when a search is performed, if any step of the search ends with an error rather than a positive or negative result, the whole lookup needs to stop and report the error rather than falling back. Falling back is not safe and creates a situation where DoS can be used to control which results are returned. While it would be possible to parallelize the search while serializing the results (i.e. waiting to accept a result from the second query until the first query finished with a negative result), I think the consensus during the last round of discussion of this topic was that the complexity cost is too great and the benefit too small. Ideally, the first query should always succeed, anyway. I also have a few questions: 1. Do you need multiple search items, or just a single domain? Any setup with multiple searches necessarily has suboptimal performance because ndots is not sufficient to make the right initial choice of query. If you do need this functionality, a unioning proxy dns server may be a better option than resolv.conf domain search; it would give much better performance. 2. For your intended applications, is there a need to support ndots>1? Such configurations are generally not friendly to applications that expect to be able to resolve normal internet domain lookups, and performance for such lookups will be very bad (because the search domains first have to fail). 3. The glibc behavior is just to swap the order of search when the query string has >=ndots dots in it, but would it be acceptable never to try the search domains at all in this case? That would yield much better performance for nxdomain results and avoid unexpected positive results due to weird subdomains existing in your search domain (e.g. a wildcard for *.us.example.com would cause *.us to wrongly resolve for non-existant .us domains). Rich