Rich Felker:
[dnssec end-to-end probe, log a warning if for any reason results
do not have the authentic data' bit set]'.
> This sounds like a great plan that will also mitigate the problem of
> glibc's AD-stripping by default. FYI I've raised concerns about that
> again on libc-alpha:
>
> https://sourceware.org/pipermail/libc-alpha/2020-May/114174.html
>
> > Postfix would still disable the res_nxxx() calls into libc-musl, but
> > that would be safe, even if those calls end up to get added later.
>
> Can you do this via the published __RES API version in resolv.h,
> rather than probing ldd? The latter is flaky and will get wrong result
> in various cases I mentioned before.
The test for res_nxxx() support needs to be at build time, because
the build fails when the library does not define the res_nxxx()
API.
(Also, you stated that runtime libraries may arbitrarily differ in
feature set from the build-time library. In that light, the only
safe choice is to never call the res_nxxx() API.)
Given that __RES is a number, how would one encode that MUSL
supports the res_nxxx() API, and not screw up other code??
The __RES value varies wildly between different platforms. __RES
never changes for glibc, but it does change on other platforms.
#define __RES 19991006 // Fedora 30, glibc 2.29
#define __RES 19991006 // Alpine 3.11.5, pretends-to-be glibc 2.29
#define __RES 19991006 // Fedora 32beta, glibc 2.31
#define __RES 20030124 // FreeBSD 8
#define __RES 20090302 // FreeBSD 12
All of the above implement res_nxxx() except the pretends-to-be glibc 2.29.
Wietse
