Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Dec 2018 09:13:01 -0500
From: Rich Felker <>
Subject: Re: DNS resolver patch

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 ( 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; 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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.