From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8727 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Would love to see reconsideration for domain and search Date: Fri, 23 Oct 2015 01:31:09 -0400 Message-ID: <20151023053108.GG8645@brightrain.aerifal.cx> References: <20151022215608.GA8645@brightrain.aerifal.cx> <20151023042720.GE8645@brightrain.aerifal.cx> 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 1445578289 25670 80.91.229.3 (23 Oct 2015 05:31:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 05:31:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8740-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 23 07:31:29 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 1ZpUwl-0001fP-G8 for gllmg-musl@m.gmane.org; Fri, 23 Oct 2015 07:31:23 +0200 Original-Received: (qmail 24437 invoked by uid 550); 23 Oct 2015 05:31:22 -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 24419 invoked from network); 23 Oct 2015 05:31:21 -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:8727 Archived-At: On Thu, Oct 22, 2015 at 10:13:18PM -0700, Tim Hockin wrote: > >> > Consider what would happen if ns1 and ns2 have different responses, but ns1 > >> > for whatever reason times out (potentially an attacker). Then you get the > >> > results for ns2, even though ns1 is intended to override it. > >> > >> I agree in theory. And yet this is how most resolvers work today. > >> Are they all broken? > > > > No, the resolvers are not broken. The configuration is, at least the > > way I see it. The intent of the resolvers is that they're > > communicating with redundant servers, not a sequence of overlaid > > hostname databases. If that assumption is satisfied, there's no > > problem. > > The way you see it is not how everyone sees it, obviously. And > there's not a standard or spec here that I know of. That said, as > before, We can probably live with this assumption. Indeed. But if you want to consider the overlaid model as the proper one, then as we already noted, all existing implementations have an exploitable bug where an attacker who can cause transient failures can change the result of queries (rather than just making queries fail). That seems rather undesirable. > > BTW I think there are other strong reasons to move to a model based on > > a local nameserver that does the unioning, not just performance. The > > most compelling is DNSSEC, which requires a trusted channel between > > the nameserver and the stub resolver in order for results to be > > meaningful/trusted. In the future everybody should be running a > > nameserver on localhost to do DNSSEC signature validation. In that > > scheme, resolv.conf would just contain 127.0.0.1 (or could be omitted > > entirely since that's the default, at least on musl). > > I can see a local nameserver doing resolution, but doing search > expansion seems like a stretch (and superfluous since it is local). Search would also get a lot of performance benefit from doing in the caching nameserver, but I agree with your assessment that it's a separate issue and that there's no _need_ to do it at that level to ensure correctness. So for now let's focus on a plan for adding suitable search domain support in musl. I believe search only affects DNS queries, not hosts file lookups, right? So it should be at the name_from_dns stage in lookup_name.c. The simplest implementation approach is probably to wrap name_from_dns with a name_from_dns_search function that reads the search domains and repeatedly calls name_from_dns until it gets success. One oddity/ugliness of search that needs to be considered is that querying different address families may lead to differently-sourced results. For example if you query example.us with ndots=2, a search domain of example.com, and the following records present: example.us.example.com A example.us AAAA then an AF_UNSPEC or AF_INET query yields a v4-only result for example.us.example.com while an AF_INET6 query "sees through" to the example.us record because the search of example.com fails. This seems quite ugly and counter-intuitive, but I don't see any way to do better that makes sense. Also, are we agreed that queries with >=ndots dots, or a final dot (as in example.com.) should never be searched (rather than searched after first trying them in the root)? Rich