> On Apr 13, 2020, at 4:56 AM, Christian <list-christ...@web.de> wrote: > > The container is running on alpine, hence with muslc libc. After seeing > the tcpdump yesterday, I thought as well, if that could be an issue. > > I am no programmer, however 2 things strike me: > Dig is able to construct a proper request and I thought it is using the > resolver routines for its tests?
No, dig(1) does not use libresolv, it has its own, much more sophisticated DNS packet encoding and decoding routines, which expose features not available via the traditional libresolv. > resolv.h for musl-libc at lease mention RES_USE_DNSSEC and > RES_USE_EDNS0 (not sure if that means anything) > https://git.musl-libc.org/cgit/musl/tree/include/resolv.h#n102 > https://git.musl-libc.org/cgit/musl/tree/include/resolv.h#n105 The comment on line 25: https://github.com/runtimejs/musl-libc/blob/master/include/resolv.h#L25 is not encouraging. It suggests that _res is unused. If so, Postfix DNS does not work correctly with this C library. And not just for DANE, since Postfix is also unable to to control RES_DEFNAMES and RES_DNSRCH. Indeed searching the github repo for RES_USE_DNSSEC and RES_USE_EDNS0 finds hits only the header file, and similarly: https://raw.githubusercontent.com/runtimejs/musl-libc/master/src/network/res_state.c pretty much rules out support for configurable lookup options. Bottom line: https://dilbert.com/strip/1995-06-24 > So I am not sure if this means anything for postfix, but how could we > find out that it is indeed an incompatibility? Is there a way to log > the construction of the request and hence the failure to properly send > it? You are logging it, with tcpdump. I am afraid that musl-libc is unsuitable for use with Postfix. You'll need a container with a less crippled C-library. -- Viktor.
