From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12654 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker 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: Fri, 30 Mar 2018 15:14:52 -0400 Message-ID: <20180330191452.GS1436@brightrain.aerifal.cx> References: <20180330185225.29656-1-nenolod@dereferenced.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1522437189 16493 195.159.176.226 (30 Mar 2018 19:13:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 19:13:09 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12668-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 30 21:13:05 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 1f1zST-00043l-6f for gllmg-musl@m.gmane.org; Fri, 30 Mar 2018 21:13:05 +0200 Original-Received: (qmail 3221 invoked by uid 550); 30 Mar 2018 19:15:04 -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 3195 invoked from network); 30 Mar 2018 19:15:04 -0000 Content-Disposition: inline In-Reply-To: <20180330185225.29656-1-nenolod@dereferenced.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12654 Archived-At: On Fri, Mar 30, 2018 at 06:52:25PM +0000, William Pitcock wrote: > In the event of no results being given by any of the lookup modules, EAI_NONAME will still > be thrown. > > This is intended to mitigate problems that occur when zones are hosted by weird DNS servers, > such as the one Cloudflare have implemented, and appear in the search path. > --- > src/network/lookup_name.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/network/lookup_name.c b/src/network/lookup_name.c > index 209c20f0..b068bb92 100644 > --- a/src/network/lookup_name.c > +++ b/src/network/lookup_name.c > @@ -202,7 +202,7 @@ static int name_from_dns_search(struct address buf[static MAXADDRS], char canon[ > memcpy(canon+l+1, p, z-p); > canon[z-p+1+l] = 0; > int cnt = name_from_dns(buf, canon, canon, family, &conf); > - if (cnt) return cnt; > + if (cnt > 0) return cnt; > } > } This patch is incorrect, and the reason should be an FAQ item if it's not already. Only a return value of 0 means that the requested name does not exist and that it's permissible to continue search. Other nonpositive return values indicate either that the name does exist but does not have a record of the quested type, or that a transient error occurred, making it impossible to determine whether the search can be continued and thus requiring the error to be reported to the caller. Anything else results in one or both of the following bugs: - Nondeterministically returning different results for the same query depending on transient unavailability of the nameservers to answer on time. - Returning inconsistent results (for different search components) depending on whether AF_INET, AF_INET6, or AF_UNSPEC was requested. I'm aware that at least rancher-dns and Cloudflare's nameservers have had bugs related to this issue. I'm not sure what the status on getting them fixed is, and for Cloudflare I don't know exactly what it is they're doing wrong or why. But I do know the problem is that they're returning semantically incorrect dns replies. Rich