nslookup's Server: 0.0.0.0 but resolves correctly

Tanguy Pruvot tanguy.pruvot at gmail.com
Mon Nov 3 03:54:26 UTC 2014


My repo (tpruvot) is the base of CyanogenMod one, which is the submitted to
CyanogenMod one (im the maintainer of the project in CM).

I do my tests on it (and tests for future version/arch).

The main change about nslookup is the requirement of __res_state nres
object inside the caller -> busybox. Ive seen that before about an error
variable.

bionic added some new __hidden attributes to prevent users to use the
"private to libc" one

2014-11-02 23:59 GMT+01:00 Rich Felker <dalias at libc.org>:

> On Sun, Nov 02, 2014 at 09:02:57PM +0000, Steven Honeyman wrote:
> > On 2 November 2014 18:05,  <stroblsw at gmail.com> wrote:
> > >> musl:
> > >>
> > >>  24
> > >>  25 /* unused; purely for broken apps */
> > >>  26 typedef struct __res_state {
> > >>  27     int retrans;
> > >>
> > >
> > > sorry you lost me.
> > > is this an nslookup.c from your own repo?
> > > I thought musl only needs header patches with bb.
> >
> > No - that's in the dns related source code of musl libc (which is also
> > broken like you describe android bionic)
> >
> > I should really say now, I know almost nothing about android/bionic
> > which is why I can't offer any direct suggestions for that... but I
> > use musl quite a bit so can try to approach that way.
> >
> > Basically, busybox tries to get dns settings through an (old?) method
> > that is not supported in musl (and possibly bionic). The code in musl
> > behind the scenes is just a bunch of return 0; to keep "broken apps"
> > happy in thinking the res functions work, but meanwhile it uses its
> > own method of parsing resolv.conf - which might be the easiest way I
> > can think of to work around this issue... but I'm sure there is a much
> > better way that I don't know about.
> >
> > ^ that's my current understanding at least, but if anyone can explain
> > better then I'm sure we'd all benefit!
>
> I'll try to explain what it's like for musl.
>
> The above comment in regards to __res_state is referring to the idea
> that this structure was never meant to be a public API, but got abused
> as one by applications attempting to override nameservers or settings
> or otherwise fiddle with the resolver's internal state.
>
> musl's resolver is completely stateless and parses resolv.conf on each
> request. This both ensures that it's always using fresh data (e.g. on
> systems where the DNS configuration changes frequently) and avoids all
> the issues of having global state that's not thread-safe or
> library-safe. (IIRC glibc avoids this by making the resolver state
> thread-local, and by providing the new "n-prefixed" versions of the
> res functions which can use a caller-provided __res_state.)
>
> The res_* functions are not stubs/dummies in musl. As of a few
> versions ago, they're all intended to work. res_init is a nop simply
> because there is no state.
>
> The right way to do lookups with a custom DNS is to call res_mkquery
> and then sendto() your preferred DNS.
>
> Rich
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20141103/e5de2c55/attachment.html>


More information about the busybox mailing list