Sendmail DNS issues

[James Stenglein]

Hello all,

I know this has been brought up before, but I can't seem to find the exact solution so I???ll give it a post also....

We have 2 servers running hpux 11 and sendmail 8.12. One is inbound traffic and one is outbound traffic. The outbound server is getting the error Deferred: Name server: xxxx.xxxx.com.: host name lookup failure message at a high rate (maybe 1 in 20 emails to legitimate sites). It is failing on such sites as Yahoo, Hp, and Excite for example. If I do nslookups from the server outbound itself, it finds the correct ip.

On some occasions, it will fail 2 of 3 times before it finally finds the ip and sends the email out or it might even fail completely. We are using out isp's resolver and there have been no changes made to our firewall. It just seems to be getting slowly worse as we went from 15-20 a year ago to 400-600 failures now.

I understand that network congestion plays a part in these messages, but I don't understand why sendmail fails to lookup records but I can from the same server?

Is there anything that I can do about these dns issues? Are there any timeouts that you would suggest we change? Anything at all?

Thanks in advance!!

[Steven E. Protter]

You are having dns resolution problems.

On the outbound server

nslookup yahoo.com

I expect you NOT to get an answer.

Two ways of handling it.

modify /etc/resolv.conf

put a server in there that will actually resolve Domain names for you.

Save the file, your email should go.

Second solution: mail relay

If you have a firewall, it can probably also relay smtp traffic and handle DNS resolution for you.

The admin of the firewall must allow relay from your IP address.

Then you modify /etc/mail/sendmail.cf

Look for the DS directieve.

Change it to:

DS
[IP address of the relay server]

save the file

/sbin/init.d/sendmail stop
/sbin/init.d/sendmail start

Retry mail with diagnostics

sendmail -v -d38.9 -d8.99 targetemail@targetdomain.com

this will give you diagnostics and tracing

run the command above

type a tag line like "I wuz here"
Hit enter
type a period(dot)
.

Hit enter

SEP

[James Stenglein]

We can lookup yahoo.com and it returns the correct ip. It just happens occasionally that it will fail. The resolv.conf is set to the ISPs resolver which i assume points to the root servers. Unless we can query the root servers themselves without building dns on the sendmail servers. The network guys have told me that the firewall will not act as a relay for sendmail or a dns resolver.

I am more curious as to why the dns failures happen when the lookups that we do from the server comeback correct.

Thanks in advance!

[someone_4 · Accepted solution]

Hello there

What do you have in your /etc/nsswitch.conf for your hosts settings?

You can try one of theese settings and see if your results get better.

hosts: files [NOTFOUND=continue TRYAGAIN=continue] dns

hosts: files [NOTFOUND=continue UNAVAIL=return TRYAGAIN=return] dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

hosts: files [NOTFOUND=continue UNAVAIL=return TRYAGAIN=return] dns


Also take a look at /etc/resolv.conf.
should be something like

domain yourdomain.net
nameserver xx.xx.xx.xx
nameserver xx.xx.xx.xx

xx.xx.xx.xx being the ip of your nameserver.

Here is a link for a doc on that
http://docs.hp.com/hpux/onlinedocs/B2355-90685/B2355-90685.html

Good Luck
Richard

[Steven E. Protter]

Based on your update you might want to look at your sendmail.cf and take out any DS directives.

If the machine resolves hosts correctly then sendmail should.

I think you need to follow the advice and make sure nsswitch.conf is standardized and tries dns first.

But it should already, based on your results.

when you run nslookup yahoo.com

the utilty indicates whether the answer came from dns or files.

Can you verify your answers are coming from DNS?

Thanks.

Quite a situation.

Hmmm. Network congestion. my pea brain molecules activate.

Ping those ISP servers and see if there are delays when congestion is heavy and your mail doesn't go through.

traceroute to them and look for long delays our timeouts in the hop. This could indicate wire, congestion our router ios problems.

SEP

[James Stenglein]

All,

Thanks again for the quick replys...

I changed the nsswitch.conf and we'll see where that takes us. My previous entry in it was
#hosts: files [NOTFOUND=continue UNAVAIL=return TRYAGAIN=continue] dns

I'll look at that document you referenced and check if the TRYAGAIN=continue would have caused failures.

As far as the traceroutes go, i never even thought of that. If I can prove that the ISP's resolvers stink as bad as we suspect, thats a good case for BIND. I do have to wait for an outage window to get over there. DMZ and they had turned off ping/traceroute/etc to it :(

Here is another instance that i notice..

in hosts I have internal.server.com and i still get 1 out of 5 going to internal.server.com as a dns failure even though it does a correct nslookup for me.

Thanks in advance!!!