From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13567 Path: news.gmane.org!.POSTED!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: DNS resolver patch Date: Thu, 27 Dec 2018 20:18:16 +0100 Message-ID: <87o996srrb.fsf@mid.deneb.enyo.de> 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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1545938184 5926 195.159.176.226 (27 Dec 2018 19:16:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Dec 2018 19:16:24 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13583-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 27 20:16:20 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 1gcb8m-0001Rc-9R for gllmg-musl@m.gmane.org; Thu, 27 Dec 2018 20:16:20 +0100 Original-Received: (qmail 25664 invoked by uid 550); 27 Dec 2018 19:18: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 25646 invoked from network); 27 Dec 2018 19:18:28 -0000 In-Reply-To: <20181225020617.GM23599@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 24 Dec 2018 21:06:17 -0500") Xref: news.gmane.org gmane.linux.lib.musl.general:13567 Archived-At: * 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; } (Oops: When EDNS support is enabled, this check is buggy because anhp->arcount is not necessarily zero due to the OPT record.) 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. Curiously this isn't something that was part of the original BIND stub resolver code. It's a fairly recent addition to the glibc stub resolver, dating back to 2005 only. Recognizing referrals reliably is quite hard; I wouldn't immediately know how to implement that in a stub resolver. (Back in 2005, referrals with a non-empty answer section were still common, I think.) It's easier in a recursive resolver because you can just follow the referral (with some safeguards to deal with loops and other nastiness). And you can do a lameness check if you know that the sever should be authoritative.