On Sun, Sep 04, 2022 at 10:31:06PM -0400, Dave Lewis - Mailinglist wrote:
> So what seems to be happening Is that if something causes a dns issue
> postfix stops sending mail, and outgoing mail queues with things like this.
>
> (Host or domain name not found. Name service error for name=gmail.com
> type=MX: Host not found, try again)
>
> Also incoming mail is also affected, but not completely. Some does
> still show up.
Sending and receiving email over the public Internet requires working
DNS. So far nothing unexpected.
> Now once I notice the issue (or someone tells me) postqueue -f does not
> work.
As expected, a congested queue is like a blocked toilet, *first* clear
the blockage, *then* flush.
> I end up having to reboot the box then run postqueue -f to get the
> queue to process.
Perhaps your resolver settings in the chroot jail become stale, and
are fixed when the "init script" resyncs the chroot with the /etc.
You might try running without chroot.
> Before I reboot the box, I can run dig commands to the cows come home
> and everything seems to be fine yet not fine with postfix.
See above.
> So what I don't get is, ok so I had a dns issue (maybe both my internal
> servers happened to get rebooted for updates close together or something),
> but why when they come back does things not start working again ?
See above.
> And why does it only impact some incoming mail and not others?
That depends on your restriction settings, whether you're using
postscreen (which has a cache) and on whether perhaps one of the
configured nameservers is working while the others are not, making
mail delivery too slow to keep up with the load.
> Has anyone seen this before ? is there a fix?
The fix is to have working DNS both outside any chroot jail, and
inside if applicable.
> I get DNS is important, but things can happen, and I would expect that
> things would start functioning normally and not require a reboot to
> "clear" the problem.
Rather depends on whether your DNS is getting reconfigured dynamically
from time to time outside the chroot, but not inside.
And on an MTA, you typically want a *local* (loopback) caching
(DNSSEC-validating) resolver, so that you can use RBLs without
running into limits on use of public forwarders.
/etc/resolv.conf:
search .
nameserver 127.0.0.1
# Recent glibc
options edns0 trust-ad
--
Viktor.
