Prev: Stats comp.mail.sendmail (last 7 days)
Next: killall -HUP sendmail
From: Steve Hajducko on 9 Feb 2010 19:39
I ran into an issue on an AIX system recently and while I have it
resolved, it's brought up some questions that I can't find answers to.

Our AIX system is in an internal network that forwards all mail to a
smart host that is allowed to relay out through the firewall. We do
have DNS for the tier but the DNS is only specifically for that
network tier - it has no knowledge of outside addresses nor can it
retrieve them.

I tried simply setting the SMART_HOST to this system, but this
resulted in:

stat=Deferred: Name server: relay.example.com: host name lookup
failure

In the end, I found the reason was because I didn't have an MX record
specifically for my SMART_HOST - I had one for the domain the
SMART_HOST was in, but not for the smart host itself.

I had this:

example.com IN MX 5 relay.example.com

So by adding another record:

relay.example.com IN MX 5 relay.example.com

I fixed the problem.

The other solutions I found to this were:

1) Putting [ ] around the smart host ( ie - DS[relay.example.com] ) to
prevent MX lookups
2) Setting a FallbackMXHost
3) Using a mailertable entry

My question, at the end of this long charade - why does sendmail try
and do an MX lookup for the smart host? Why doesn't it instead try to
do the MX lookup on the domain the smart host is in? ( ie - where it's
usually defined )

Is it going with the assumption that my smart host isn't directly
accessible and therefore wants to find an MX record to how to deliver
the mail to my smart host? If so, then it's surprising that
FallbackMXHost doesn't follow the same guidelines. sendmail will
*try* and find an MX for FallbackMXHost but if it doesn't, just
attempts to send the mail directly to the host - something I would
assume the normal smart host would do as well.
From: Robert Bonomi on 10 Feb 2010 18:01
In article <5364aa8b-8863-41ca-8664-65a6c0f805c1(a)a5g2000prg.googlegroups.com>,
Steve Hajducko <hajducko(a)gmail.com> wrote:
>I ran into an issue on an AIX system recently and while I have it
>resolved, it's brought up some questions that I can't find answers to.
>
>Our AIX system is in an internal network that forwards all mail to a
>smart host that is allowed to relay out through the firewall. We do
>have DNS for the tier but the DNS is only specifically for that
>network tier - it has no knowledge of outside addresses nor can it
>retrieve them.
>
>I tried simply setting the SMART_HOST to this system, but this
>resulted in:
>
>stat=Deferred: Name server: relay.example.com: host name lookup
>failure
>
>In the end, I found the reason was because I didn't have an MX record
>specifically for my SMART_HOST - I had one for the domain the
>SMART_HOST was in, but not for the smart host itself.
>
>I had this:
>
>example.com IN MX 5 relay.example.com
>
>So by adding another record:
>
>relay.example.com IN MX 5 relay.example.com
>
>I fixed the problem.
>
>The other solutions I found to this were:
>
>1) Putting [ ] around the smart host ( ie - DS[relay.example.com] ) to
>prevent MX lookups
>2) Setting a FallbackMXHost
>3) Using a mailertable entry
>
>My question, at the end of this long charade - why does sendmail try
>and do an MX lookup for the smart host? Why doesn't it instead try to
>do the MX lookup on the domain the smart host is in? ( ie - where it's
>usually defined )
>
>Is it going with the assumption that my smart host isn't directly
>accessible and therefore wants to find an MX record to how to deliver
>the mail to my smart host? If so, then it's surprising that
>FallbackMXHost doesn't follow the same guidelines. sendmail will
>*try* and find an MX for FallbackMXHost but if it doesn't, just
>attempts to send the mail directly to the host - something I would
>assume the normal smart host would do as well.

Your entire analysis appears to be faulty.

'host name lookup failure' indicates that sendmail could not get DNS
data when trying to resolve 'relay.example.com'.

In the course of mucking around with the MX record, you apparently fixed
the 'real' problem.

I.e., in the _in-memory_ database that the DNS server answers queries from,
there was no 'A' record, or no CNAME, or the CNAME pointed (possibly
through other CNAMEs to a name that did not exist.

One can 'think' the record is there -- you see it in the 'zone' file -- but
it is not actually being handed out by the DNS Server. This state of affairs
can happen for any of several reasons -- the one of the most common reasons
being that one forgot to update the 'serial number' in the zone file; next is
a failure to tell the DNS server to 'reload the zone files'. A third reason
that can lead to this behavior is "improper caching" of 'negative answers'
from the DNS server, either by a slave server, a DNS forwarding server, or
a local resolver.

This particular kind of a 'problem' is a bear to troubleshoot, because it tends
to 'spontaneously' cure itself -- giving the impression that 'something else'
(that was actually unrelated to the problem) getting changed _was_ the 'fix'.
When the 'actual cure' was the result of the DNS server expiring its in-memory
date, and actually reading the modified file.







 | 
Pages: 1
Prev: Stats comp.mail.sendmail (last 7 days)
Next: killall -HUP sendmail