"Deferred: Name server: nohost: host name lookup failure"

"Deferred: Name server: nohost: host name lookup failure"

Post by Jonathan I. Kame » Tue, 28 Mar 1995 02:03:24



I'm running sendmail 8.6.11, the Linux 1.2.1 kernel, and Linux libc 4.5.26.

When I try to send mail to a host that doesn't exist in my domain, e.g.,
"nohost", sendmail reports "Deferred: Name server: nohost: host name lookup
failure" for three days instead of immediately bouncing the message with "Host
uknown".  I believe that this problem is new with either a recent version of
sendmail or a recent Linux kernel.

My /etc/host.conf says: "order hosts, bind" and "multi on".

Does anybody have any suggestions about what may be causing this or how to fix
it?
Thanks.

--

 
 
 

"Deferred: Name server: nohost: host name lookup failure"

Post by Jonathan I. Kame » Wed, 29 Mar 1995 11:58:49



BIND code from ftp.vix.com:/pub/bind/testing, tweaked it a little bit to get
it to compile with Linux libc 4.5.26, and then relinked sendmail 8.6.11
against it.  This caused the problem I was seeing to go away.

Practically speaking, it's good for me that the problem has gone away, but on
another level, I still suspect that somethin in a recent sendmail release
broke things for people who aren't running the newest version of BIND, and
that's probably not such a good thing.

--


 
 
 

"Deferred: Name server: nohost: host name lookup failure"

Post by Jeffrey C. Oll » Wed, 29 Mar 1995 13:23:54




>BIND code from ftp.vix.com:/pub/bind/testing, tweaked it a little bit to get
>it to compile with Linux libc 4.5.26, and then relinked sendmail 8.6.11
>against it.  This caused the problem I was seeing to go away.
>Practically speaking, it's good for me that the problem has gone away, but on
>another level, I still suspect that somethin in a recent sendmail release
>broke things for people who aren't running the newest version of BIND, and
>that's probably not such a good thing.

I experienced the same problems, and the person working on a port of the libc
code to Linux claimed that it was a bug in the resolver code included with
certain versions of the Linux libc.

I first noticed this problem first when I upgraded libc to 4.6.27.

--
Jeffrey C. Ollie
Iowa Network Services Support Daemon