Is sendmail caching DNS or getting it via different method than host/dig/nslookup?

Question

We've got a linux server running sendmail that relays email through our primary mail server, but ever since a change of DNS servers last week, it's been timing out connecting to our mail server. Upon further investigation, /var/log/maillog shows lines like the following, incl. the incorrect IP address for the mail server:

Apr  4 15:37:32 yip sendmail[20583]: p34JVgLE020540: to=<[email protected]>, ctladdr=<[email protected]> (0/0), delay=00:05:50, xdelay=00:02:00, mailer=esmtp, pri=258071, relay=mailserver.domain.tld. [xxx.xxx.xxx.xxx], dsn=4.0.0, stat=Deferred: Connection timed out with mailserver.domain.tld.

Now, we had updated the linux server's DNS servers last week along with the migration by editing /etc/resolv.conf. Running dig mailserver.domain.tld, host mailserver.domain.tld, or nslookup mailserver.domain.tld on the linux server all result in the correct IP address being returned. Where could sendmail be getting/caching the incorrect IP address and how can I resolve that issue?

Solution 1

• Restart sendmail.
• Restart nscd (if it's in use on the system).

Also make sure you have the correct MX record entries. Sendmail relies on the MX lookup.

Try dig mx domain.tld and see if that results in the correct host. If not, you can force sendmail to deliver mail destined for a particular domain using the mailertable file typically found in /etc/mail/.

A typical mailertable entry looks like:

xxx.com esmtp:[192.168.1.2]

Where "xxx.com" is the domain and the IP for delivery is explicitly stated.

Solution 2

sendmail does cache information about a host's status before reconsulting DNS. Tweaking Timeout.hoststatus can change this, but then again restarting sendmail for your particular case is the way to go (instead of waiting for the timeout to expire).

Solution 3

Sendmail doesn't do any caching itself, it relies on the local name server.

There's a couple of things that are worth checking, though you'll probably of done them already:

• Check /etc/hosts has no entries for the relay server, that'll take precedence over DNS
• Check the Sendmail resolver options to see if it's actually set to use DNS
• Ensure /etc/resolv.conf is only pointing to updated DNS servers, and 1 of them isn't still returning the old value. Do this manually by running nslookup and entering "server 1.2.3.4" for each DNS server, remember it could return 2 different IPs on repeat queries if it's set to have duplicate entries. I've seen this plenty of times.

I know they're all pretty basic, but it's easy for a very rushed admin to make a simple mistake like one of these.

Comments

[morgant]

/etc/mail/sendmail.cf had no entry for ResolverOptions, so it was relying on the defaults (I'm unsure whether that'd include DNSRCH, but I'd assume so). I had used dig @server mailserver.domain.tld to verify that each of the DNS servers in /etc/resolve.conf was dishing out the correct IP.

[morgant]

I had used dig -t MX domain.tld to verify the MX record matched the hostname of the mail server in question. A restart of sendmail using /etc/init.d/sendmail restart seemed to resolve the issue and mail started flowing. Any idea why sendmail would've held onto the old IP for so long?

[morgant]

Thanks, very good to have confirmation of what I was seeing (and how to adjust in the future, if needed).

[geekosaur]

@morgant: If you actually changed DNS servers (their addresses, as opposed to their contents), that information is cached from /etc/resolv.conf by libc the first time the resolver is invoked.

[morgant]

That explains it. Yes, the DNS server changed and the former DNS server was dishing out old IPs, so it was still querying against the old server.

[Ewan Leith]

yes the default includes DNSRCH.

[Doug Luxem]

The default timeout setting for TO_HOSTSTATUS is 30 minutes. Normally this is ok, but some mail providers (like Message Labs) rotate the IPs of their mail servers frequently as an antispam measure. These means that Sendmail may be up to 30 minutes out of date with its IP address for the remote mail host. From what I can tell, the TTL of the DNS records is NOT taken into account in Sendmail's caching.