From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12664 Path: news.gmane.org!.POSTED!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] resolver: only exit the search path loop there are a positive number of results given Date: Sat, 31 Mar 2018 12:42:17 +0200 Message-ID: <874lkw1q7q.fsf@mid.deneb.enyo.de> References: <20180330185225.29656-1-nenolod@dereferenced.org> <20180330191452.GS1436@brightrain.aerifal.cx> <20180330193548.GT1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522492831 21106 195.159.176.226 (31 Mar 2018 10:40:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Mar 2018 10:40:31 +0000 (UTC) Cc: musl@lists.openwall.com To: William Pitcock Original-X-From: musl-return-12678-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 31 12:40:27 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1f2Dvs-0005Lf-MU for gllmg-musl@m.gmane.org; Sat, 31 Mar 2018 12:40:24 +0200 Original-Received: (qmail 5662 invoked by uid 550); 31 Mar 2018 10:42:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5639 invoked from network); 31 Mar 2018 10:42:29 -0000 In-Reply-To: (William Pitcock's message of "Fri, 30 Mar 2018 14:44:44 -0500") Xref: news.gmane.org gmane.linux.lib.musl.general:12664 Archived-At: * William Pitcock: > A local proxy isn't going to be workable, because most people are > going to just say "but Debian or Fedora doesn't require this," and > then just go use a glibc distribution. Some parts of the glibc behavior are clearly wrong and not even internally consistent. Rich is right that for correctness, you can only proceed on the search path if you have received a successful reply. However, making changing in this area difficult, both due to the current state of the glibc code, and existing deployments depending on corner cases which are not well-understood. I'm not entirely convinced that using different search path domains for different address families is necessarily wrong. Historically, the NODATA/NXDOMAIN signaling has been really inconsistent anyway, and I suspect it still is for some users. What Cloudflare is doing appears to be some kind of protection against NSEC-based zone enumeration, and that requires synthesizing NODATA response. They are unlikely to change that, and they won't be the only ones doing this. (going further upthread) > Kubernetes imposes a default search path with the cluster domain last, so: >=20 > - local.prod.svc.whatever > - prod.svc.whatever > - svc.whatever > - yourdomain.com Do you have a source for that? Considering that glibc had for a long time a hard limit at six entries, I find that approach rather surprising. This leaves just three domains in the end user's context. That's not going to be sufficient for many users. Anyway =E2=80=A6 > The cloudflare issue is that they send SUCCESS code with 0 replies, > which causes musl to error when it hits the yourdomain.com. Is the long search path really the problem here? Isn't it ndots:5? It means that queries destined to the general DNS tree hit the organizational tree first, where the search stops due to the NODATA response. So you never get the expected response from the public tree. Is this what's happening?