-> >
-> My /etc/resolv.conf:
->
-> ; generated by /sbin/dhclient-script
-> search csds.local
-> nameserver 192.168.1.4
-> nameserver 65.106.1.196
-> nameserver 65.106.7.196
->
I have read the future parts of this thread and came back to here.
I was doing some test loads and what I noticed was that when I enabled dhcp
on an interface that it would look to the router ip as the primary dns and
then put in a secondary and a tertiary.
So what and then the bogus search domain
So what I ended up doing for this was making a /etc/resolv.bak with just the
real primary and secondary as the router doesn't have bind running of course
and getting rid of the search and putting in something in /etc/rc.local like
cp -af /etc/resolv.bak /etc/resolv.conf
and the problem went away.
Remember I was just testing 4.4 upgrades and how well the mirrors were
handling the stress etc etc before I blow up some production servers.
It appears to me in this case you should focus on dhcp issues or some
sort...
i.e. look at this /etc/resolv.conf file and it tells you the answer as far
as I am concerned. It is *generated* by the dhcp
also, is there more than one Ethernet interface on this machine?
It would have been easier to see if the resolver was working on the
192.168.1.4 box before you took it out of the loop...
I could be wrong about dhcp issues of course yet at least I tried
;->
- rh
--
Robert - Abba Communications
Computer & Internet Services
(509) 624-7159 - www.abbacomm.net
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
