What could be the reason sendmail is reporting "host name lookup
failure", while I can just do a "dig +short " and this hostname resolves
fine?

On 03/11/2022 23.22, None wrote:
> What could be the reason sendmail is reporting "host name lookup
> failure", while I can just do a "dig +short " and this hostname resolves
> fine?

It could be your /etc/nsswitch.conf (Linux and a bunch UNIX variants),
check the hosts setting, I think a quite common one is

hosts: files dns

Sure there could be other reasons, which I'm not aware of.

--
//Aho

None wrote:
> What could be the reason sendmail is reporting "host name lookup
> failure", while I can just do a "dig +short " and this hostname resolves
> fine?

Did you do the same lookup types as sendmail does?
(MX, CNAME, TLSA, A, AAAA?)
Maybe you can give a real example?
And if you use some OS with the $#$%^@ that is called systemd:
they screwed up the resolver behaviour if some options are set.

Moreover, DNS lookups can change with each try as different
servers might be involved.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

>> What could be the reason sendmail is reporting "host name lookup
>> failure", while I can just do a "dig +short " and this hostname
>> resolves fine?
>
> It could be your /etc/nsswitch.conf (Linux and a bunch UNIX variants),
> check the hosts setting, I think a quite common one is
>
> hosts:      files dns
>

Just to be sure I commented this out, but restarting sendmail after this
still gives the lookup failure

#hosts: files dns myhostname
hosts: files dns

>> What could be the reason sendmail is reporting "host name lookup
>> failure", while I can just do a "dig +short " and this hostname resolves
>> fine?
>
> Did you do the same lookup types as sendmail does?
> (MX, CNAME, TLSA, A, AAAA?)

For every john@example.com email, I am having a mailer table entry
mail.example.com which only has an A record.

> Maybe you can give a real example?
> And if you use some OS with the $#$%^@ that is called systemd:
> they screwed up the resolver behaviour if some options are set.

It must be indeed related to newer versions because nothing changed in
the mail flow (configured in ldap).

I have a frontend server looking up email addresses xxx@example.com in
the access table (stored in ldap) allowing for relay.
And I have mailer table (stored in ldap) entry for the domain
example.com with esmtp:mail.example.com, directing to the 'backend
server' where the mail should be delivered.

The weird thing is that in the vast majority emails go through. Today
this seems to happen in ~3% of the deliveries, and these get a 'Cannot
send message for 5 days'.
Within this period other emails to the same email address and unchanged
setup, are delivered correctly.

> Moreover, DNS lookups can change with each try as different
> servers might be involved.
>

On 07/11/2022 11.55, None wrote:
>
>>> What could be the reason sendmail is reporting "host name lookup
>>> failure", while I can just do a "dig +short " and this hostname
>>> resolves fine?
>>
>> It could be your /etc/nsswitch.conf (Linux and a bunch UNIX variants),
>> check the hosts setting, I think a quite common one is
>>
>> hosts:      files dns
>>
>
> Just to be sure I commented this out, but restarting sendmail after this
> still gives the lookup failure
>
> #hosts:      files dns myhostname
> hosts:      files dns

I don't know if your mail server is using systemd or not, but if you
are, you could look at this post in stackexchange to see how to get more
information out of systemd-resolved:

https://unix.stackexchange.com/questions/328131/how-to-troubleshoot-dns-with-systemd-resolved

Sadly I don't have much of advice what to look for in this case, the
latest issues I have had has been opendkim/mimdefang/spamassassin
related (versions not compatible with the installed sendmail).

--

//Aho

>>
>> Just to be sure I commented this out, but restarting sendmail after
>> this still gives the lookup failure
>>
>> #hosts:      files dns myhostname
>> hosts:      files dns
>
> I don't know if your mail server is using systemd or not, but if you
> are, you could look at this post in stackexchange to see how to get more
> information out of systemd-resolved:
>
> https://unix.stackexchange.com/questions/328131/how-to-troubleshoot-dns-with-systemd-resolved
>
>
> Sadly I don't have much of advice what to look for in this case, the
> latest issues I have had has been opendkim/mimdefang/spamassassin
> related (versions not compatible with the installed sendmail).
>

I don't think it is running, I have disabled NetworkManager and run with
the old ifcfg scripts still.

And these do not show any sign of some resolve process running

systemctl list-unit-files | grep reso
find /run -iname "*resolv*"
find /lib -iname "*resolv*"

[@]# ps -e | grep systemd
1 ? 00:02:25 systemd
602 ? 00:00:18 systemd-journal
615 ? 00:00:01 systemd-udevd
695 ? 00:00:40 systemd-logind
631568 ? 00:00:00 systemd

On 07/11/2022 14.36, None wrote:
>
>>>
>>> Just to be sure I commented this out, but restarting sendmail after
>>> this still gives the lookup failure
>>>
>>> #hosts:      files dns myhostname
>>> hosts:      files dns
>>
>> I don't know if your mail server is using systemd or not, but if you
>> are, you could look at this post in stackexchange to see how to get
>> more information out of systemd-resolved:
>>
>> https://unix.stackexchange.com/questions/328131/how-to-troubleshoot-dns-with-systemd-resolved
>>
>> Sadly I don't have much of advice what to look for in this case, the
>> latest issues I have had has been opendkim/mimdefang/spamassassin
>> related (versions not compatible with the installed sendmail).
>>
>
> I don't think it is running, I have disabled NetworkManager and run with
> the old ifcfg scripts still.
>
> And these do not show any sign of some resolve process running
>
> systemctl list-unit-files | grep reso
> find /run -iname "*resolv*"
> find /lib -iname "*resolv*"
>
> [@]# ps -e  | grep systemd
>       1 ?        00:02:25 systemd
>     602 ?        00:00:18 systemd-journal
>     615 ?        00:00:01 systemd-udevd
>     695 ?        00:00:40 systemd-logind
>  631568 ?        00:00:00 systemd
>

It would have appear with
$ ps -e | grep resolve
3691 ? 00:00:00 systemd-resolve

_so at least you have one less thing to worry about. _

Just a side note, the machine I was looking at that has systemd and
systemd-resolve, do not have networkmanager installed, so seems that
systemd can use the resolver for something else than together with
networkmanager (I can see some statistics data, so I know it has been used).

--

//Aho

>
> Moreover, DNS lookups can change with each try as different
> servers might be involved.
>

for an outlook recipient that has one mx record that resolves to
different ip addresses. I wanted the email to be delivered to 1 specific
address. So I just added to the /etc/hosts

x.x.x.x mx.client.outlook.com

Hoping that if sendmail resolves mx.client.outlook.com the forced ip
address is being used. Yet it seems to bypass the /etc/hosts file and
just continue to use the dns.

None wrote:

> address. So I just added to the /etc/hosts

> x.x.x.x mx.client.outlook.com

> Hoping that if sendmail resolves mx.client.outlook.com the forced ip
> address is being used. Yet it seems to bypass the /etc/hosts file and

See the fine documentation:

Notice: since sendmail must access MX records for
correct operation, it will use DNS if it is configured
in the ServiceSwitchFile file. Hence an entry like

hosts files dns

will not avoid DNS lookups even if a host can be found
in /etc/hosts.

See cf/README how to use mailertable and how to suppress
MX lookups ([host])

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.