Package: bind9 Version: bind9/stable,now 1:9.16.22-1~deb11u1 amd64 Severity: important
-- System Information: Debian Release: 11.2 APT prefers stable APT policy: (700, 'stable'), (500, 'stable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Report: In certain, but unpredictable cases, Bind reports a query failure, before Bind even tries to query the requested domain. But if the same request is sent immediately again, Bind resolves as expected and gives the correct answer to the client. I'm not sure, if this is really a bug. Chances are big, that it is a configuration failure on my site. But if the latter, till now I've found nothing helpful in the documentation. A dump of the network traffic shows following behaviour (lines 7 to 12 in the attached pcap dump): The client (172.16.2.222) asks Bind to resolve essentra.com. Bind tries to retrieve from 162.159.2.9 (cloudflare) the addresses not for essentra.com, but for anna.ns.cloudflare.com resp. vern.ns.cloudflare.com. That is okay so far, as this two are authoritative nameservers for essentra.com. Immediately after that (0,1 ms), Bind sends a failure notice to the requesting client. After another 1 ms, the answers from 162.159.2.9 come in. Too late for the client. The client repeats the request (lines 51 to 54 in the pcap) for essentra.com. Bind relays this query to anna.ns.cloudflare.com (173.245.58.102). After ~1 ms the answer from anna.ns.cloudflare.com comes in; Bind relays the answer to the requesting client. Everything's fine! The big problem of course is, that most clients (e.g. mta's like Postfix, Browsers, ...) do not repeat their request immediately. Postfix typically makes the next retry ~20 min later, and then (at least more often than not) the same cycle begins again - until finally Postfix reports a non delivery to the mail sender. This happens unpredictable and, as far as I have seen, for relative few domains only. Whenever I have seen this behavior, the auth. nameservers for the requested domains were either from cloudflare.com or from microsoftonline.com
anfrage_essentra.pcap
Description: application/vnd.tcpdump.pcap
09-Mar-2022 16:40:59.744 queries: info: client @0x7f2355518268 172.16.2.222#33886 (essentra.com): query: essentra.com IN A + (10.0.0.252) 09-Mar-2022 16:40:59.744 resolver: debug 1: fetch: essentra.com/A 09-Mar-2022 16:40:59.744 lame-servers: info: network unreachable resolving 'essentra.com/A/IN': 2a06:98c1:50::ac40:2066#53 09-Mar-2022 16:40:59.828 lame-servers: info: network unreachable resolving 'essentra.com/A/IN': 2606:4700:58::adf5:3bf3#53 09-Mar-2022 16:40:59.828 lame-servers: info: network unreachable resolving 'essentra.com/A/IN': 2606:4700:50::adf5:3a66#53 09-Mar-2022 16:40:59.828 lame-servers: info: network unreachable resolving 'essentra.com/A/IN': 2803:f800:50::6ca2:c1f3#53 09-Mar-2022 16:40:59.828 lame-servers: info: network unreachable resolving 'essentra.com/A/IN': 2803:f800:50::6ca2:c066#53 09-Mar-2022 16:40:59.828 lame-servers: info: network unreachable resolving 'essentra.com/A/IN': 2a06:98c1:50::ac40:21f3#53 09-Mar-2022 16:40:59.828 resolver: debug 1: fetch: anna.ns.cloudflare.com/A 09-Mar-2022 16:40:59.828 resolver: debug 1: fetch: vern.ns.cloudflare.com/A 09-Mar-2022 16:40:59.828 query-errors: info: client @0x7f2355518268 172.16.2.222#33886 (essentra.com): query failed (failure) for essentra.com/IN/A at query.c:7365 [...] 09-Mar-2022 16:41:02.616 queries: info: client @0x7f234c220218 172.16.2.222#41819 (essentra.com): query: essentra.com IN A + (10.0.0.252) 09-Mar-2022 16:41:02.616 resolver: debug 1: fetch: essentra.com/A 09-Mar-2022 16:41:02.628 queries: info: client @0x7f235553a7e8 172.16.2.222#41427 (essentra.com): query: essentra.com IN AAAA + (10.0.0.252) 09-Mar-2022 16:41:02.628 resolver: debug 1: fetch: essentra.com/AAAA 09-Mar-2022 16:41:07.568 queries: info: client @0x7f234c220218 10.0.0.11#48603 (25.0.16.172.in-addr.arpa): query: 25.0.16.172.in-addr.arpa IN PTR + (10.0.0.252) 09-Mar-2022 16:41:07.568 queries: info: client @0x7f234c220218 10.0.0.11#37720 (exchange-2019.glatz.intern): query: exchange-2019.glatz.intern IN A + (10.0.0.252) 09-Mar-2022 16:41:07.840 queries: info: client @0x7f235553a7e8 10.0.0.11#39632 (essentra.com): query: essentra.com IN MX + (10.0.0.252) 09-Mar-2022 16:41:07.840 resolver: debug 1: fetch: essentra.com/MX
