From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8711 Path: news.gmane.org!not-for-mail From: Tim Hockin Newsgroups: gmane.linux.lib.musl.general Subject: Re: Would love to see reconsideration for domain and search Date: Thu, 22 Oct 2015 14:24:11 -0700 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1445549097 3356 80.91.229.3 (22 Oct 2015 21:24:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2015 21:24:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8723-gllmg-musl=m.gmane.org@lists.openwall.com Thu Oct 22 23:24:56 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 1ZpNLt-0003BL-OR for gllmg-musl@m.gmane.org; Thu, 22 Oct 2015 23:24:49 +0200 Original-Received: (qmail 32674 invoked by uid 550); 22 Oct 2015 21:24:48 -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 32639 invoked from network); 22 Oct 2015 21:24:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Gf9WysobRV/vxkpgR0LtPVNxRyB6Dot0zGtsvVns4G8=; b=EQ5W8v7a6rHTP3faoXA2/XNPxduJSL0pxq9wEN1LYzAyLNlTbE6zha/0wnAnZR8PgZ o8rC+m66rqvvXv31Y6XXPPt3ervbbCB5a0Qkmt9QjAQEbeBGWEVMUXNYkaTzJXKpRqBY +yH9fienue/LAdjsOUMQzlnrQDBxGP2S5oAdfbKuvznQYAWFJKe+7MhdwcdB7wJ4aUMH utlw1xwfwJel5+oHkc1HO2N2gkVIfQ+6HfcKws0YEOGX3UIC8x5zXVkIM3e01XTqBbVE qTBivVykWanGEz0s6+cyuG/wJvHsAQ58XpJ6KBF0iOcDHR5LdfRYsUDDRJeXs11Yorc4 qIuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Gf9WysobRV/vxkpgR0LtPVNxRyB6Dot0zGtsvVns4G8=; b=CjaQsVg8hyK0b7aBdNmxFr6+ndCEiOTOuseAiXzIzpTHAa/yt3scGK+9bxVdbHl9Dd Aqf+9XVB9Xd7i772L/VpqoyFmoMgsGyzpCfto/Zj1T0tW2+RIisRJF3Byj0lzPbh7+Ms ETypnQqoae3Kd4LQH0x5T1NExTY6hUNiTeUk3RsjK05w0C85f/mt5X+t4bBfwIcKGkAn UKEhbY0Me6ZvtlezR62hDPcFq50vGEXtDd00R2JVpNRhUVsgaSD7Ixs9FR8Hyj/yrlFQ XQlAjfJ2yrzRtYyDQyVjj0gPLq3u7odRGVjhi7tiVEC46NI80hFI848C8wQvwUHlK0rI 2X7w== X-Gm-Message-State: ALoCoQn/2k2NSzoXre4MhbUQ/bJOOBCFO0cZmfBNKVreyaBj7Izt943gOitqontUHaCAF30vAtUo X-Received: by 10.31.8.21 with SMTP id 21mr10501586vki.82.1445549070982; Thu, 22 Oct 2015 14:24:30 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:8711 Archived-At: Hi all, I saw this thread on the web archive but am not sure how to respond to the thread directly as a new joinee of the ML. I hope this finds its way... I am one of the developers of Kubernetes and I own the DNS portion, in particular. I desperately want to use Alpine Linux (based on musl) but for now I have to warn people NOT to use it because of this issue. On Fri, Sep 04, 2015 at 02:04:29PM -0400, Rich Felker wrote: > 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. I understand your point, though the world at large tends to disagree. Everyone has a primary and secondary `nameserver` record (or should). If the first one times out, try the second. Most resolver libs seem to accept a SERVFAIL response or a timeout as a signal to try the next server, and I would encourage you to do the same. Stopping on positive response or NXDOMAIN seems to be commonly accepted with a caveat. You can't query all nameservers and just take the first NXDOMAIN to respond. You can only accept NXDOMAIN if all of the higher-priority (listed first in resolv.conf) nameservers have timed out or SERVFAIL'ed. You can issue queries in parallel, but you must process responses in order, which is what you describe below. > 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. The real world is not ideal. Not all nameservers are identically scoped - you MUST respect the ordering in resolv.conf - to do otherwise is semantically broken. If implementation simplicity means literally doing queries in serial, then that is what you should do. Similarly, you can't just search all search domains in parallel and take the first response. The ordering is meaningful. > 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. We use multiple search paths and ndots > 1. I'm not sure what you mean by "unioning" here. Search path ordering is as meaningful as nameserver ordering. You can't avoid making the query for each search suffix in the worst case, and it has the same restriction as nameserver - the search order must be respected. There does seem to be some different implementations that search for the "naked" query first vs last, though. I think the semantically correct (but pessimal performance) is to search for that last. > 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). DNS is a very lightweight protocol. We have not measured any practical detriment for having 6 search domains and ndots=5. In the normal case it fails very quickly. That aside, it should be my business if I want to (mis)configure my system that way :) > 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). I think that would be correct. If I have 3 dots and ndots=2, search paths should be ignored. Tim