Thanks all.. gives me some direction to keep digging.
-----Original Message-----
From: [email protected] <[email protected]> On
Behalf Of Viktor Dukhovni
Sent: Monday, September 5, 2022 9:36 AM
To: [email protected]
Subject: Re: Odd DNS issue requiring reboot.
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.
