From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13510 Path: news.gmane.org!.POSTED!not-for-mail From: Natanael Copa Newsgroups: gmane.linux.lib.musl.general Subject: Re: DNS resolver patch Date: Thu, 6 Dec 2018 16:23:49 +0100 Message-ID: <20181206162349.19319ffb@ncopa-desktop.copa.dup.pw> References: <882247050.3003099.1544074074084.JavaMail.zimbra@totalphase.com> <1934405743.3003283.1544074315707.JavaMail.zimbra@totalphase.com> <20181206141301.GA23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1544109724 1281 195.159.176.226 (6 Dec 2018 15:22:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2018 15:22:04 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13526-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 06 16:21: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 1gUvTT-0000Cv-Cj for gllmg-musl@m.gmane.org; Thu, 06 Dec 2018 16:21:59 +0100 Original-Received: (qmail 30285 invoked by uid 550); 6 Dec 2018 15:24:08 -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 30261 invoked from network); 6 Dec 2018 15:24:07 -0000 In-Reply-To: <20181206141301.GA23599@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:13510 Archived-At: On Thu, 6 Dec 2018 09:13:01 -0500 Rich Felker wrote: > On Wed, Dec 05, 2018 at 09:31:55PM -0800, Tarun Johar wrote: > > Hi Team, > > > > The VirtualBox --natdnsresolver does not support IPv6 AAAA address > > queries. It returns "NotImp" (code 4) for such queries. > > > > The MUSL library (https://www.musl-libc.org/) resolver does not > > recognize this code and retries the query until the timeout. This > > causes DNS lookups to take several seconds after which they are > > eventually successful. > > > > The GLIBC resolver works properly with the same configuration, > > suggesting that a fix should be made to MUSL to handle the "NotImp" > > response code. > > > > The root cause is this section of code in musl/src/network/res_msend.c:149 > > /* Only accept positive or negative responses; > > * retry immediately on server failure, and ignore > > * all other codes such as refusal. */ > > switch (answers[next][3] & 15) { > > case 0: > > case 3: > > break; > > case 2: > > if (servfail_retry && servfail_retry--) > > sendto(fd, queries[i], > > qlens[i], MSG_NOSIGNAL, > > (void *)&ns[j], sl); > > default: > > continue; > > } > > > > If "case 4" is added after "case 3" and before "break", the NotImp > > code is treated as a positive or negative response and the name > > resolution loop completes immediately. > > > > Can the patch for this be included in MUSL 1.1.21 ? > > No, this is specifically wrong. If one buggy nameserver is responding > with "NotImp", the correct behavior is waiting for a response from a > different one that's not broken. It's possible that we could try to > remember such errors for each nameserver, and abort the lookup early > with an error (not a negative result, since this is not a result) if > *all* of them have failed, but it's not clear that that's the right > thing to do if there might be multiple actual servers behind each > logical one (ip address), which is probably the case for things like > 8.8.8.8; in that case an error from one should not result in aborting > the query. Note also that treating it as an error would not help with > the practical need, since then the whole query would fail and you > wouldn't get the IPv4 results either. > > The real fix here is just making VirtualBox's nameserver do the right > thing, or bypassing it and querying a real nameserver. Apparently > there's some reason it's desirable for use with certain NAT setups, > but I'm not clear on what this is. If it's returning real results, it > should just support AAAA and pass it through. If it's returning faked > results for some reason, and doesn't use IPv6 for them, it should just > return NxDomain for AAAA queries rather than an error. I'm happy to > help in explaining to upstream why the current behavior is problematic > if needed. For the record, here is a good explanation: https://nlnetlabs.nl/pipermail/unbound-users/2017-August/004866.html RCODE 4 means "Not Implemented - The name server does not support the requested kind of query." where "kind of query" is specified in OPCODE[1] field (eg query or notify) and is not the RR type. -nc [1]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-5