From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13568 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: DNS resolver patch Date: Fri, 28 Dec 2018 12:21:24 -0500 Message-ID: <20181228172124.GP23599@brightrain.aerifal.cx> References: <1934405743.3003283.1544074315707.JavaMail.zimbra@totalphase.com> <87r2eu1zbc.fsf@oldenburg2.str.redhat.com> <20181206164820.07cc96f4@ncopa-desktop.copa.dup.pw> <87ftvaiknn.fsf@oldenburg2.str.redhat.com> <466f7852-8535-38d7-afe5-23eb491842d8@adelielinux.org> <20181225020617.GM23599@brightrain.aerifal.cx> <87o996srrb.fsf@mid.deneb.enyo.de> 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 1546017575 30773 195.159.176.226 (28 Dec 2018 17:19:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Dec 2018 17:19:35 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13584-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 28 18:19:31 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 1gcvnG-0007rd-7Y for gllmg-musl@m.gmane.org; Fri, 28 Dec 2018 18:19:30 +0100 Original-Received: (qmail 21602 invoked by uid 550); 28 Dec 2018 17:21:38 -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 21559 invoked from network); 28 Dec 2018 17:21:37 -0000 Content-Disposition: inline In-Reply-To: <87o996srrb.fsf@mid.deneb.enyo.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13568 Archived-At: On Thu, Dec 27, 2018 at 08:18:16PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Thu, Dec 06, 2018 at 07:46:02PM +0000, Laurent Bercot wrote: > >> >The musl resolver should be able to handle a resolver returning NODATA. > >> >That is popular for having a separate extranet infrastructure - your > >> >extranet DNS only contains records for your local domain and returns > >> >NODATA for requests outside that domain. > >> > >> No, you are talking about servers containing data. The musl client > >> (which is not a resolver, because it only performs recursive queries) > >> should not contact those directly. It should contact a real resolver, > >> a.k.a. cache, and the cache will contact the servers containing data. > >> If the domain has been configured properly, the servers are never asked > >> for data that are outside that domain. > >> > >> It is the single most annoying, most bug-prone, and most confusing > >> flaw of DNS to have "communication between the DNS client and the DNS > >> cache" (recursive queries) and "communication between the DNS cache > >> and the DNS server" (non-recursive queries) happen on the same port. > >> I'd even take a different _protocol_ if it could stop people from > >> misconfiguring DNS. > >> > >> The default usage of BIND, which was "one single daemon is both a > >> cache and a server and we entertain the confusion", did a lot of harm > >> to the Internet. As your post illustrates, this harm pertains to this > >> day. > > > > I'm not sure what the relation to the confusion between querying an > > authoritative server and a recursive server is here, but the quoted > > interpretation of NODATA above is wrong independent of any such > > confusion. NODATA does not indicate that the server you asked doesn't > > know about the queried name. It indicates that that queried name > > exists but has no records of the requested type. > > Maybe a referral looks like a NODATA response upon cursory inspection? > > glibc has code which switches to the next configured nameserver upon > encountering what looks like a referral: > > if (anhp->rcode == NOERROR && anhp->ancount == 0 > && anhp->aa == 0 && anhp->ra == 0 && anhp->arcount == 0) { > goto next_ns; > } Can you elaborate or provide a citation on how this "looks like a referral"? I don't see any obvious difference between this and a nodata response except possibly RA==0, which would only happen when you have an auth-only nameserver listed in your resolv.conf. This would not be useful for unioning in musl because it depends on an ordering between the nameservers rather than providing a true union; at least one of the servers is going to be recursive and return an nxdomain or nodata which could be seen before the auth-only local server responds. > (Oops: When EDNS support is enabled, this check is buggy because > anhp->arcount is not necessarily zero due to the OPT record.) FTR, also not an issue for musl since we intentionally don't do EDNS. > REFUSED is handled the same way, so I think this enables the > misconfiguration A. Wilcox described. Fortunately, we still only > support three name servers, so there is a limit to what people can do > with this. Refused and other errors are pretty much ignored in musl; they're at least not conclusive unless all nameservers have responded with an error, since another one could still succeed. Rich