From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8728 Path: news.gmane.org!not-for-mail From: Tim Hockin Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Would love to see reconsideration for domain and search Date: Thu, 22 Oct 2015 22:37:53 -0700 Message-ID: References: <20151022215608.GA8645@brightrain.aerifal.cx> <20151023042720.GE8645@brightrain.aerifal.cx> <20151023053108.GG8645@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 X-Trace: ger.gmane.org 1445578710 31405 80.91.229.3 (23 Oct 2015 05:38:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 05:38:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8741-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 23 07:38: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 1ZpV3b-0001Gm-6R for gllmg-musl@m.gmane.org; Fri, 23 Oct 2015 07:38:27 +0200 Original-Received: (qmail 29789 invoked by uid 550); 23 Oct 2015 05:38:25 -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 29764 invoked from network); 23 Oct 2015 05:38:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=o0K8oXBis/4zC0/fysnt/1BJMrKHZrOxIBNKaX9Vrws=; b=bM7QAMDS1U6kuQrklcNqPf71XIair61DT9YvFsvnvRzSqAIFXIZy920Dh5uBK/CpCL S8nJ38sTDOiSAuOzAPrX/XylLKWSKnR3b2+g6cKtRai2qmX/JNkiIS4nji095X17PpiT 66z5/UcJLwsrezweZqI4BRnBRVMaNWDCVZir7xI7kC2ETYZZxPUDnhYr2YmgFrkDgojB IpfG0moan/NDjlpsuiUZfKnggIkoty/TS34v4D0qElQl0QH300i5TQ2oSQPOrQBM4WN5 +qiZbZ4wSeY8OFp2mRGuJ8VZybhosYVfRgMEaHSWvHANEZf5XmOoR9ku804Gpc2gTDB+ 5IGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=o0K8oXBis/4zC0/fysnt/1BJMrKHZrOxIBNKaX9Vrws=; b=ZZlO8VD6N6pUvdJXhZ9tiL1yROLsMyCrcUn7N1lyf4VOSlUk0Lhi8iUZ1bd1/OnuZB FcrPZlEw3+zqvqfGQAee59pcMHauBP2u4RZj+c1UiGYW9WKTN/gjOmzVpXrByX9+r01r Jc0IDWxxZMQyrXHbrU/8rTEUFPJc3cz1FWM7UidhG5ObR4Vch0jEppjBE2b3RhbsfyMv 2esVsYmQNbjAx1/n7rAsQemNTHYipi6YE2MQJPo3ywmF3f9TP3hZPdR0XGlUQEhgu0g4 0q+qKLg+yScDofjmDMVmhbSYS23Tz8cP7vbuXWhgQG3VtlXDfkqkJsIpZnXfIMFcPax0 aw8A== X-Gm-Message-State: ALoCoQkkixkC/4rXjjRQ9tZXCEdNQNV//Fis3G5He9283ieRgHyBGX5To5tbXZN8MRCH08zGOQWK X-Received: by 10.31.54.13 with SMTP id d13mr12025944vka.155.1445578693269; Thu, 22 Oct 2015 22:38:13 -0700 (PDT) In-Reply-To: <20151023053108.GG8645@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8728 Archived-At: On Thu, Oct 22, 2015 at 10:31 PM, Rich Felker wrote: >> > 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. Sounds right. > I believe search only affects DNS queries, not hosts file lookups, Also my understanding > 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. If that is how the records are laid out, I think you have to allow it. > 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)? That sounds right. I saw from a different thread that musl doesn't or didn't do TCP fallbacks - is that still the case? I know we need that for things like large multi-SRV sets (which I do not expect libc to support), and we have some people who have large A sets (which I do expect libc to support).