[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181206162349.19319ffb@ncopa-desktop.copa.dup.pw>
Date: Thu, 6 Dec 2018 16:23:49 +0100
From: Natanael Copa <ncopa@...inelinux.org>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: DNS resolver patch
On Thu, 6 Dec 2018 09:13:01 -0500
Rich Felker <dalias@...c.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
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.
