require_rdns
in [Sendmail]
|
From: DJ GRP on 26 Feb 2010 03:52 > It does not exclude option that sendmail cached "as DNS allowed" > DNS replies "straightened" just before sendmail restart. > Have you "cured by restart" more than once? OK, it could be like this. And I really don't care about the way the problem was resolved (by restarting sendmail, restarting DNS or even restarting a server). The important thing here IMHO, is that the -according to sendmail- unresolved host NEVER ceased to have a reverse entry, and no DNS server was stopped at the specified interval. So, even if we suppose that we are talking about cached entries, I can assure you that at no time the host in question was left unresolved. What do we have to suppose taking all this into account?
From: Per Hedeland on 26 Feb 2010 16:05
In article <hm823g$tdu$1(a)news.grnet.gr> "DJ GRP" <deejay.grp(a)gmail.com> writes: >> It does not exclude option that sendmail cached "as DNS allowed" >> DNS replies "straightened" just before sendmail restart. >> Have you "cured by restart" more than once? > >OK, it could be like this. And I really don't care about the way the problem >was resolved (by restarting sendmail, restarting DNS or even restarting a >server). The important thing here IMHO, is that the -according to sendmail- >unresolved host NEVER ceased to have a reverse entry, and no DNS server was >stopped at the specified interval. So, even if we suppose that we are >talking about cached entries, I can assure you that at no time the host in >question was left unresolved. What do we have to suppose taking all this >into account? Any chance that you at some point changed /etc/resolv.conf, and that the old contents were no longer valid (i.e. not giving the address of working DNS servers anymore)? The OS resolver library, which sendmail and most everything else uses, only reads resolv.conf once. Hence processes that are both long-running and DNS-using *must* be restarted in this scenario - and parallell tests with 'dig' etc are not relevant, as resolv.conf gets read for each invocation of those programs. --Per Hedeland per(a)hedeland.org |