> On Dec 4, 2020, at 9:41 AM, Sergio Belkin <seb...@gmail.com> wrote:
>
> > dnsmasq-2.76-7.el7.x86_64
>
> Is there a compelling reason to run a stripped-down (and typically not
> adequately standards-conformant) DNS resolvers on a mail server?
>
> I use mainly for caching purposes
That's a reason to run a local caching resolver, which is highly
recommended on an MTA, *but* it is not a reason to choose a shoddy
resolver like dnsmasq or systemd-resolved, ... which is barely
good enough for laptop use, where integration with DHCP, roaming
etc. provides some "pros" to offset the "cons", but on a server
MTA there is no plausible reason to choose these.
> I'd steer well clear of "dnsmasq", "systemd-resolved" and other
> "DNS made simple" resolvers.
Steer well clear of "dnsmasq", "systemd-resolved", ...
> Install "unbound", "bind" or "knot", whichever you're most
> comfortable with.
Install "unbound", "BIND" or "Knot", whichever you're most
familiar with.
But before you do that, it would be useful to stick with
what you have for a little longer, with "debug_peer_list"
enabled in the hope that we can narrow down the source of
the problem. My present bet is on a bug in "dnsmasq". But
it is possible that some DNS load-balancer or other in some
Microsoft datacentre is unexpectedly responding NODATA for
IPv4.
A bug in Postfix soft-error handling sure looks unlikely.
All the relevant functions note soft lookup errors and do
not let subsequent hard lookup errors erase a preceding soft
error status.
--
Viktor.
