Xref: utzoo comp.mail.sendmail:88 comp.dcom.lans:1828
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!woods
From: woods@ncar.ucar.edu (Greg Woods)
Newsgroups: comp.mail.sendmail,comp.dcom.lans
Subject: Re: sendmail, the resolver and /etc/hosts
Summary: why I want to do this; I have good reasons
Message-ID: <729@ncar.ucar.edu>
Date: 21 Sep 88 06:46:11 GMT
References: <713@ncar.ucar.edu> <1469@valhalla.ee.rochester.edu>  <1473@valhalla.ee.rochester.edu> <285@hal.UUCP>
Reply-To: woods@handies.UCAR.EDU (Greg Woods)
Organization: Scientific Computing Division/NCAR, Boulder CO
Lines: 69

In article <285@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes:
>>Many times a user on one of my systems begins a correspondance with someone
>>at a site we previously never mailed to.  The user at the remote site
>>gives our local user an address that he "knows" is good, 'cause its in the
>>hosts table.  Our user sends mail to that address and it bounces... there
>>isn't a nameserver to answer for that host in that domain.

  This is *precisely* the situation I am running into, and all too often
the "user" in question is our Division Director, or some other bigwig here.

>In that case contact the Zone Contact for this domain - It is their
>responsibility to maintain their files, not yours.

  That isn't a good answer, although a lot of people seem to think it is,
based on the mail I've gotten. My users want mail to work. They don't
want to hear a lot of excuses about how it's the other site's fault.
Especially since the "simple" hosts-file-based mailer on the other
machine can get it there. That is the reality. It's all well and good
for us hackers to know that it is, in fact, the other site's fault.
We all know they've had plenty of time to convert. But my users don't
*care* about that; they really don't! And besides, if they don't have
a working name server, how the hell do I find out who the "Zone Contact"
is? Face it, folks, it ain't a perfect reality we live in. There are hosts
and domains out there that were registered before the days of name servers,
that are legitimately registered, and that my users want to send to.
My bosses want to send there. Therefore, I have to support it. That's it.
Period. What those other sites *should* be doing is TOTALLY IRRELEVANT
to the reality I (and apparently some others too) am faced with.

>If you are running the nameserver then the /etc/hosts file is necessary
>only during those times the nameserver is down, such as in standalone
>mode or during testing.

  Untrue, see above.

>>What is the "right thing" to do here?  
>The "right thing" would be to contact the other site.

  That doesn't get mail working. That is the "right thing" in one sense,
but in reality it does NOTHING to solve my problem. Nor does it deal with
the "it works on the other machine" hassles. Nor does it help me justify
the added effort to keep up the name server, resolver, and hacked versions
of sendmail and other applications.

>Any site in the NIC's host file is available to the nameserver.

  WRONG. See first paragraph.

>My suggestion AS A TEMPORARY FIX would be just to use the internet number
>for the site rather than the site name.

  Not a good temporary fix from the user's point of view. Fine for us, but
the users don't want to deal with this nonsense. All they understand is
that the information is available and my mailer can't find it.

  Thanks to those who sent me patches. None of them were for the exact
software I have, so I haven't been able to make any of them work yet.
In BIND 4.7.2, there were 4 patches to gethostnamaddr.c. With the
BIND 4.8 code, none of them would apply. I can only find two of the
places in the code where they should go, and even after putting them
in by hand, neither nslookup nor sendmail can resolve host names I
placed in /etc/hosts that aren't available through the name servers.
Running nslookup under dbx(1) shows that gethostbyname() is never called
unless a server is specified on the command line, so it never gets
to the patched part of the code. 
   I hope to have more luck with the 5.59 sendmail patch I got, although
what I have is hacked 5.58, so I'm expecting more trouble.

--Greg