From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12655 Path: news.gmane.org!.POSTED!not-for-mail From: William Pitcock 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 14:19:48 -0500 Message-ID: References: <20180330185225.29656-1-nenolod@dereferenced.org> <20180330191452.GS1436@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" X-Trace: blaine.gmane.org 1522437483 6504 195.159.176.226 (30 Mar 2018 19:18:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 19:18:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12669-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 30 21:17:59 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 1f1zXD-0001Zi-1V for gllmg-musl@m.gmane.org; Fri, 30 Mar 2018 21:17:59 +0200 Original-Received: (qmail 9832 invoked by uid 550); 30 Mar 2018 19:20:03 -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 9774 invoked from network); 30 Mar 2018 19:20:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YYG4nqtqto4WN9ja/bpO+iBcqmMuPMs+J5QffpgXBU8=; b=b5FPtW3Ryjrh/VlRniPipnzbfIkMh/W064uLWZ4R7Mnab7SjoGpwjc78c6yXPoyycF IPIArixuh1ficQDzc2i2JbsTpbjo1qlHoxq6fwA/WEFzEJWNGUsvfmRVHOdqk5gHlJcq a2R/Y5dqv4Nyr0T9CLihpmpfjijtOee8nWqKdNAKmO2fb7nHxmjxTb7nGbD3vDEZRUPa /XoHynNJz9m3KArQWYRW8VUbisi9W22oZUba76aHyik96MA+9QA+AcEWRtJRSAsiWv9+ jQ42fa8193EWIBdEnBIdni5VQ0P/eiJUMJveo7SGVguT0Fb9CFFncFcTWwjQDlp/Z8qN G+nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YYG4nqtqto4WN9ja/bpO+iBcqmMuPMs+J5QffpgXBU8=; b=P2RMXK12MLGQHVqi4eZH5u8FJQ735IIeTrqmwlMOjWK5xqF9PB8kMslvsVo5CbiuFQ brAIyu4UE2gGdQpQ9d4ArysGBTSfu3mcNj5TBYO1W2hniZ1/c/mNPPfclGWFox0zMKFt +fC3xPRdgrf/t+NvZQeT+WDSi2nejGLP/a6Y1+072FXJMycB0YaJaPXmtVbKGpOORct2 fTYQaJ6B0pqMmanz3OHgfXKFL9q4btSBgSOW4wp91VCyWwYR8JxdUGRhzAA140ORpHRC pAsZCiIJ6N7Jfyigjpt+U83sT6LY+xQngSKVHFVaPtejSAQUcw1MjiVPpphavjFpBJRR l45g== X-Gm-Message-State: ALQs6tCrywxKQmxyjH0NLSk3M2Avvz9jzlq97TE3BVmJ1ft1mcl6lmhC aIS7Nc9BiHmetYDqOcv7/munim8op6DFRRAfDZjFlw== X-Google-Smtp-Source: AIpwx4/YmNq2WHRuCK6e/kij018rN2bLVVTa2g2lqu7PSHAYVGIb0cxawnFUlqapWiP35bOsf3Mw0JPKMl1H4Rs1/pI= X-Received: by 10.55.185.69 with SMTP id j66mr345394qkf.216.1522437589354; Fri, 30 Mar 2018 12:19:49 -0700 (PDT) In-Reply-To: <20180330191452.GS1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12655 Archived-At: Hello, On Fri, Mar 30, 2018 at 2:14 PM, Rich Felker wrote: > 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. Kubernetes imposes a default search path with the cluster domain last, so: - local.prod.svc.whatever - prod.svc.whatever - svc.whatever - yourdomain.com The cloudflare issue is that they send SUCCESS code with 0 replies, which causes musl to error when it hits the yourdomain.com. Do you have any suggestions on a mitigation which would be more palatable? We need to ship a mitigation for this in Alpine 3.8 regardless. I would much rather carry a patch that is upstreamable, but I am quite willing to carry one that isn't, in order to solve this problem. William