From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14162 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: DNS resolver patch Date: Thu, 30 May 2019 09:54:02 -0400 Message-ID: <20190530135402.GM23599@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> <20181228172124.GP23599@brightrain.aerifal.cx> <87o93kba29.fsf@mid.deneb.enyo.de> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="209946"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Florian Weimer Original-X-From: musl-return-14178-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 30 15:54:23 2019 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.89) (envelope-from ) id 1hWLVd-000sPH-2n for gllmg-musl@m.gmane.org; Thu, 30 May 2019 15:54:21 +0200 Original-Received: (qmail 5956 invoked by uid 550); 30 May 2019 13:54:18 -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 5934 invoked from network); 30 May 2019 13:54:17 -0000 Content-Disposition: inline In-Reply-To: <87o93kba29.fsf@mid.deneb.enyo.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14162 Archived-At: On Thu, May 30, 2019 at 10:50:22AM +0200, Florian Weimer wrote: > * Rich Felker: > > On Thu, Dec 27, 2018 at 08:18:16PM +0100, Florian Weimer wrote: > >> 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. > > But that's exactly the scenario when people want to ignore referrals. > A name server which provides recursive service will never send a > referral, after all. If it cannot complete the recursion, it will > respond with SERVFAIL instead. Yes, I just wasn't clear how to interpret that combination of bits. I should re-read the spec I guess. > > 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. > > I expect that the authoritative-only server is put first in this case. Note that musl does not have a concept of an order between the nameservers; they're just treated as alternative sources for the same data. > My position is that this is not really worth supporting, though. It's > easy enough to run a local caching resolver which can implement such > policies, including forwarding queries for certain zones to certain > authoritative servers. Then there's no need to resort to search path > hacks and listing non-recursive name servers in etc/resolv.conf. I agree completely. Fancy policy things like unioning and remapping are best done in an external process. Moreover, with DNS privacy and integrity becoming such a critical issue in the future (or perhaps the present), it's going to be mandatory to run a (proxy, at least) nameserver on localhost anyway to perform DNSSEC validation and/or DNS-over-HTTPS. Rich