Re: DNS resolver patch

[Natanael Copa <ncopa@alpinelinux.org>]

On Thu, 6 Dec 2018 09:13:01 -0500
Rich Felker <dalias@libc.org> 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