Date: Fri, 24 May 1996 14:54:20 -0500 From: Dave Bodenstab <imdave@synet.net> To: freebsd-questions@FreeBSD.org Subject: Weird behavior (bug? fix included) with sendmail/dns/gethostbyname Message-ID: <199605241954.OAA02123@base486.synet.net>
next in thread | raw e-mail | index | archive | help
I just discovered something weird. This might help a bunch of
folks, who like me, are connected via a dial-up line to an ISP. I've
seen other folks who have had the same problem I had: local email
caused a dns lookup which caused the ppp daemon to re-dial and
re-establish the connection. You might want to note this (gee, maybe
it is, I haven't looked at it recently :-( ) in the handbook.
This was a pain! I didn't want a dial-up connection made every time local
mail is being sent (cron, batch, at, etc.) I haven't seen a real solution
to this problem other than, as someone suggested, trying to setup a caching,
local name server.
So, I've put together this rather long message to document the behavior
I've discovered. My solution is much simpler -- trivial in fact. I
apologize if I'm just repeating well known info...
*** Warning! Long (150+ line) message follows! ***
Rather than supplying too little info, I'll error by trying to be complete.
Here are all my config files that are (might be) applicable:
/etc/hosts
127.0.0.1 base486 localhost base486.synet.net
/etc/host.conf
hosts
bind
/etc/resolv.conf
domain synet.net
nameserver 168.113.1.64 ; G30.SYNET.NET
nameserver 128.248.2.50 ; UIC-DNS1.UIC.EDU
/etc/sendmail.cf
# local info #
Cwlocalhost base486 base486.synet.net
# who I send unqualified names to (null means deliver locally)
DR
# who gets all local email traffic ($R has precedence for unqualified names)
DH
# who I masquerade as (null for no masquerading)
DMsynet.net
# class L: names that should be delivered locally, even if we have a relay
CLroot
CLbin
CLimdave
# class E: names that should be exposed as from this host, even if we masquerade
CEroot
/etc/sysconfig
hostname=base486.synet.net
defaultdomainname=NO
routedflags=NO
namedflags="NO"
gated=NO
$ hostname
base486.synet.net
$ domainname
$
$ uname -a
FreeBSD base486.synet.net 2.0.5-950622-SNAP FreeBSD 2.0.5-950622-SNAP #0: \
Thu Oct 19 22:04:51 CDT 1995 bin@base486.synet.net:/usr/src/sys/compile/base486 i386
This machine is not on a lan (no network card). I connect to an ISP (who
assigns addresses dynamically) with "User Process PPP" in -auto mode.
FWIW, the routing info (at this moment) is:
$ netstat -nr
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 168.113.1.2 UGc 1 0 tun0
127.0.0.1 127.0.0.1 UH 15 965516 lo0
168.113.1.2 168.113.1.3 UH 2 0 tun0
224 127.0.0.1 US 0 0 lo0
Now, everything seems to be setup OK, I can ping external hosts, surf the
Internet with netscape, send email to anyone on the Internet (I use popclient
to retrieve email,) ftp, etc. When I send mail, the masquerade works properly.
What is weird is that *order* of the hostnames on the line in /etc/hosts
affects whether or not sendmail does an external dns lookup for the host
for *local* mail delivery even though I've specified "hosts" before "bind"
in /etc/host.conf! With the line:
127.0.0.1 base486 localhost base486.synet.net
in /etc/hosts, then when I (from, say bin) send *local* email to myself (imdave)
with the command:
$ mail imdave
then sendmail does a dns lookup, and traffic goes out to the name server over
the ppp link. I notice this because if the ppp daemon has dropped the
connection due to the inactivity timeout, ppp will re-dial to re-establish
the link.
But, here's a (neat?) trick! (I don't know what made me try this.) Change
the order of the hostnames in /etc/hosts to:
127.0.0.1 base486.synet.net base486 localhost
Viola! Local email now does *not* cause the name server to be referenced!
I think this is weird!
Here's a little program I used to see what gethostbyname() was doing:
#include <sys/param.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
main( int argc, char **argv )
{
struct hostent *hp;
char *p;
int n, i;
while( --argc > 0 )
if ( hp = gethostbyname(*++argv) ) {
printf( "%s: %n%s\n", *argv, &n, hp->h_name );
for( i = 0; p = hp->h_aliases[i]; ++i )
printf( "%*s [%s]\n", n, "", p );
printf( "%*s%s\n", n, "", inet_ntoa(*(struct in_addr*)(hp->h_addr)) );
for( i = 0; p = hp->h_addr_list[i]; ++i )
printf( "%*s [%s]\n", n, "", inet_ntoa(*(struct in_addr*)p) );
}
else
fprintf( stderr, "%s: *********\n", *argv );
}
With /etc/hosts containing the line above, my program yields:
$ a.out base486 # or either of the other two hostnames
base486: base486.synet.net
[base486]
[localhost]
127.0.0.1
[127.0.0.1]
Just as one would expect.
Changing /etc/hosts back to the original line:
127.0.0.1 base486 localhost base486.synet.net
then gives:
$ a.out base486 # or either of the other two hostnames
base486: base486
[localhost]
[base486.synet.net]
127.0.0.1
[127.0.0.1]
Again, just as expected. I'll also mention that the test program does *not*
result in a dns lookup. So, I don't know what sendmail is doing that the
order of the hostnames would make a difference.
I'm totally ignorant about routing, subnets, netmasks, etc. I'm especially
ignorant about sendmail.cf. My setup has evolved to its current state just
by stumbling around and getting things to work one at a time. It might just
be that my network configuration is totally bogus -- after all, I am not on
a local lan. Should I be my own domain? If I were on a local lan, would I
not have to setup my own domain, especially since the addresses would have
to be, say, 10.*.*.*? In that case, the FreeBSD box would have two
"interfaces" (right?) and would need to (potentially) route between the
two? [I think this last statement is bogus since the 10.*.*.* addresses
should not be dumped out to the net, but if I had real, registered addresses,
then I think the previous statement would be true, wouldn't it?]
Anyway, thanks for reading, and I hope this has been useful to someone.
Should this go to freebsd-bugs also?
Dave Bodenstab
imdave@synet.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605241954.OAA02123>