/etc/resolv.conf and sendmail

Gene Heskett gene.heskett at verizon.net
Tue Jul 13 10:49:10 UTC 2004


On Tuesday 13 July 2004 06:07, Philippe wrote:
>On Tue, 2004-07-13 at 16:56, Gene Heskett wrote:
>> On Tuesday 13 July 2004 05:38, Philippe wrote:
>>
>> You'll need a line in your hosts file that defines AAA, and you
>> should have a line "order hosts,bind" in the host.conf file IIRC.
>
>Yes I have this line.
>
>> Here, I pass the buck by having the firewall's local ip as the
>> only nameserver entry in resolv.conf, and the firewall in turn
>> passes it to the real world if its not in the hosts file on the
>> firewall.
>
>Ouch .. to technical for me ;-)

Not really, you don't have to sacrifice any virgins or anything like 
that. It might take a chicken, but those from KFC work just fine. :-)

>So I have an idea. As I am on a dialup connection, when sendmail is
>launched, I still don't have any DNS set up (they come from my ISP).
> So could it be the cause of my problem ?

I'd suspect the major reason for the long delays is a lack of being 
properly configured.  Since I'm behind a firewall, here are those 
files from this machine in order to explain:

/etc/hosts
--------
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1	localhost.localdomain	localhost
192.168.77.1	gene.coyote.den		gene
192.168.77.2	amiga.coyote.den	amiga
192.168.77.3	coyote.coyote.den	coyote
192.168.77.4	shop.coyote.den		shop
--------------
you'll need to define AAA in this file by adding something like this 
to yours:
192.168.pick-subnet-address.pick.machine-address	FQDN	alias

where the FQDN (Fully Qualified Domain Name) might be 
AAA.domain-name.whatever and the alias is then AAA

This address block, the 192.168.x.x is not a routable block and is 
intended to allow all internal nets to share addresses without 
clashing with the rest of the world in doing so.

Then in your /etc/host.conf:
order hosts,bind
----------

So that the protocol will first saerch the hosts file to locate AAA, 
then if that fails, goto bind (the Berkeley Internet Name Daemon)
Now, if you are going online and getting your address via dhcp 
protocol, your /etc/resolv.conf will be re-written each time you go 
online and will then contain the addresses of the domain servers your 
ISP has assigned for your use, probably two entries.  Here is the one 
from my firewall box from an ssh login there:

[root at gene root]# cat /etc/resolv.conf
search coyote.den
nameserver xxx.xxx.0.39
nameserver xxx.xxx.32.43

which since its told to search my local domain first by the search 
coyote.den directive, will do so, but if that doesn't resolve, then 
it will use the other 2 addresses for a dns query.  Since those are 
outside addresses that shouldn't be used by anybody but verizons 
customers, I've slightly mangled them above with the xxx thingies, 
but you get the idea.

>What I can see, but not sure 100%, is after being connected, if I
>restart sendmail, or if I flush the queue, all the next mails, even
>hours after, will be sent correctly.

Back when I was on dialup, I had no such problems, and typically had a 
new address each time my script to go get the mail triggered, which 
was an autodial thing, going online on demand.  So it seems to me 
like the local name resolution described above may be a larger 
problem than the dynamic ip address you are getting.  Or your ISP 
isn't responding correctly with its nameservers addresses when you 
login.  In that event however, you would not be able to browse the 
net once connected.

Hopefully, this made a little sense :)

>Philippe
>--
>Philippe, Chiangmai, Thailand

-- 
Cheers, Gene
There are 4 boxes to be used in defense of liberty. 
Soap, ballot, jury, and ammo.
Please use in that order, starting now.  -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004, 
Maurice E. Heskett, all rights reserved.





More information about the fedora-list mailing list