Hello Viktor, thanks again, please see my answers inline. Am Sonntag, den 12.04.2020, 22:47 -0400 schrieb Viktor Dukhovni: > On Mon, Apr 13, 2020 at 02:12:49AM +0200, Christian wrote: > > > thanks for the response! Apparently the mail was too long (>4000) and > got rejected, hence I put it to pastebin: > https://pastebin.com/1e3sR0Hq > > The query in your PCAP file was not sent to 127.0.0.11, and had no > EDNS > OPT record (so no "DO" bit): > > Internet Protocol Version 4, Src: 192.168.4.5, Dst: 192.168.4.254 > User Datagram Protocol, Src Port: 34651, Dst Port: 53 > Domain Name System (query) > Transaction ID: 0x55b7 > Flags: 0x0100 Standard query > 0... .... .... .... = Response: Message is a query > .000 0... .... .... = Opcode: Standard query (0) > .... ..0. .... .... = Truncated: Message is not truncated > .... ...1 .... .... = Recursion desired: Do query > recursively > .... .... .0.. .... = Z: reserved (0) > .... .... ...0 .... = Non-authenticated data: > Unacceptable > Questions: 1 > Answer RRs: 0 > Authority RRs: 0 > Additional RRs: 0 > Queries > do.havedane.net: type MX, class IN > Name: do.havedane.net > [Name Length: 15] > [Label Count: 3] > Type: MX (Mail eXchange) (15) > Class: IN (0x0001) > > Is 127.0.0.11 inside the container == 192.168.4.254 outside?
Yes, sorry. Should have mentioned it. The 127.0.0.11 ist the docker way of saying: This DNS is configured by docker. And indeed the docker container IP of unbound is 192.168.4.254. > What C-library and operating system is this? Perhaps the C-library > in > Docker ignores RES_USE_EDNS0 and RES_USE_DNSSEC or more generally > changes to _res.options? > > > I think the tcpdumps are interesting, as they show that postfix is > not > requesting with the right flags (If I am not reading everything > wrong). > > When Postfix is configured with "smtp_dns_support_level = dnssec", > the > RES_USE_DNSSEC and RES_USE_EDNS0 flags are set around calls to the > resolver routines. If your C-library (perhaps only inside docker) > has > an incopatible resolver API, then you'll need a more compatible > resolver > library and/or a different container technology. > 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? 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 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? Will also contact musl-libc to see if they have ideas.
