> Found a workaround to the problem. By replacing the fully qualified
> domain name in my resolv.conf file with the ip address of the dns server
> it started working.
>
> original resolv.conf:
>
> search
> nameserver ns1.helpfulhome.com
> nameserver authns1.mpls.qwest.net
> nameserver authns2.dnvr.qwest.net
> nameserver 168.103.24.1
> nameserver 204.147.80.1
>
> new resolv.conf
>
> search
> nameserver 207.224.115.73
> nameserver authns1.mpls.qwest.net
> nameserver authns2.dnvr.qwest.net
> nameserver 168.103.24.1
> nameserver 204.147.80.1
>
> Now I grant that Qwest has my reverse DNS totally hosed. But other mail
> servers are finding me just fine and dig and nslookup were both able to
> find the record without any delay. I would dearly like to know if this
> is a bug in exim or ???? All other packages on the system worked and
> continue to work fine (apache, ssh, cocoon, tomcat, telnet, proftp...)
> Let me know what other information you would like....
>
From recollection...
a) all nameserver entries in /etc/resolv.conf should be dotted quads
(numerics) and not FQDNs otherwise you have a chicken-and-egg
problem
b) the maximum number of nameserver entries in /etc/resolv.conf
on most systems is three - dunno what happens if you use more.
On all of our deployed systems we have a local (site) wide DNS
box, ie. dns.whereever.com which is the main resolving namserver,
ie. talks to the root servers, hosts our own domains, etc. and our
mail servers have a copy of bind configured as a caching nameserver
(option forward only, forwarders points to site wide machine) and
then the entry in resolv.conf is just "nameserver 127.0.0.1".
This works well and we have no issues with Exim and DNS (other
than sites with lame nameservers).
Recommend that you use either a max of three external nameserver
machines which you have tested for correct operation, or implement
your own site server - either way use the dotted quad ip addresses.
Mike
