"relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

"relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host

Jon Leech
    I'm using postfix 3.4.14-0+deb10u1 as the MTA on my Debian machine,
with

disable_dns_lookups = yes
relayhost [mail.sonic.net]:587

    This has worked fine for many years until on 12/3, without any
changes in my local OS / postfix configuration, it started failing to
deliver mail to the relayhost - which I only found out about 5 days
later when the default maximal_queue_lifetime expired.

    The only meaningful messages in the mail logs were

Dec 10 00:01:58 celly postfix/smtp[21050]: warning: relayhost configuration problem
Dec 10 00:01:58 celly postfix/smtp[21050]: send attr reason = unable to look up host mail.sonic.net: Name or service not known

    I cranked the debug level in master.cf up to 3 '-v's resulting in
lots of log messages, but no more details of *why* it was "unable to
look up". I can nslookup, dig (either A or MX records), telnet to port
587, etc. on mail.sonic.net, so it's not a general system DNS issue.

    The postfix FAQ sort of touches on this scenario in FAQs 52 and 53,
but about all I can make of that is that it might be running in a chroot
without the right resolv.conf or other resource to do a name lookup. If
that's true, any ideas on how I can figure out where the chroot is? And
why this behavior would have suddenly started happening, without any
changes in my local configuration (that I initiated, at least, and I
don't have any auto-updates configured)?

    Finally, is there any way to crank postfix's verbosity up to a level
where it would actually explain why and/or where it's getting these
errors? It would be nice if it would tell me something about *why* there
is a "relayhost configuration problem", in particular.

    I also have a query in to Sonic as to whether anything might have
changed on their end - they are Linux-friendly, and even the front-line
support people tend to be clueful.

    Thanks,
    Jon Leech
    [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: "relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host

Wietse Venema
DNS lookups are done by SYSTEM LIBRARY functions, and these log
nothing no matter how you twiddle Postfix options. Postfix is the
messenger of bad news; don't blame the messenger.

Consider using strace (see http://www.postfix.org/DEBUG_README.html)
and find out what if you have a 'missing file' or 'filer permission'
permission problem.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: "relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host

Viktor Dukhovni
In reply to this post by Jon Leech
On Thu, Dec 10, 2020 at 05:33:46AM -0800, Jon Leech wrote:

>     The only meaningful messages in the mail logs were
>
> Dec 10 00:01:58 celly postfix/smtp[21050]: warning: relayhost configuration problem
> Dec 10 00:01:58 celly postfix/smtp[21050]: send attr reason = unable to look up host mail.sonic.net: Name or service not known

Is the "smtp" transport using "chroot" in master.cf?

> I can nslookup, dig (either A or MX records), telnet to port
> 587, etc. on mail.sonic.net, so it's not a general system DNS issue.

Are your tests performed as "root" or as an unprivileged user?

> The postfix FAQ sort of touches on this scenario in FAQs 52 and 53,
> but about all I can make of that is that it might be running in a chroot
> without the right resolv.conf or other resource to do a name lookup. If
> that's true, any ideas on how I can figure out where the chroot is?

The chroot is always the Postfix queue directory, typically
/var/spool/postfix.  And its use is specified in the "chroot" column of
the master.cf service definition.

> And why this behavior would have suddenly started happening, without
> any changes in my local configuration (that I initiated, at least, and
> I don't have any auto-updates configured)?

A Debian update?

> I also have a query in to Sonic as to whether anything might have
> changed on their end - they are Linux-friendly, and even the front-line
> support people tend to be clueful.

Upstream is unlikely to be at issue.  Not DNSSEC-signed, but no issues
otherwise:

    https://dnsviz.net/d/mail.sonic.net/dnssec/

Best to not nag them with local issues on your end.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: "relayhost configuration problem" / "unable to look up host" when I can, in fact, look up the host

Jon Leech
On Thu, Dec 10, 2020 at 02:56:17PM -0500, Viktor Dukhovni wrote:
> On Thu, Dec 10, 2020 at 05:33:46AM -0800, Jon Leech wrote:
>
> > The only meaningful messages in the mail logs were
> >
> > Dec 10 00:01:58 celly postfix/smtp[21050]: warning: relayhost configuration problem
> > Dec 10 00:01:58 celly postfix/smtp[21050]: send attr reason = unable to look up host mail.sonic.net: Name or service not known
>
> Is the "smtp" transport using "chroot" in master.cf?

    It is.

> > I can nslookup, dig (either A or MX records), telnet to port
> > 587, etc. on mail.sonic.net, so it's not a general system DNS issue.
>
> Are your tests performed as "root" or as an unprivileged user?

    As an unprivileged user.

> The chroot is always the Postfix queue directory, typically
> /var/spool/postfix.  And its use is specified in the "chroot" column of
> the master.cf service definition.

    Aha, it is. NetworkManager thoughtfully erased everything from
/var/spool/postfix/etc/resolv.conf shortly before these problems began,
which almost certainly explains the problem.

    I despise NM.

> A Debian update?

    No. But IIRC, Comcast went down for a while and I switched to
tethering via my phone for data around that time, and did have to
restore /etc/resolv.conf. I had no idea about the chroot resolv.conf.

    Thanks very much!

    Jon

P.S. I despise NM.