Bogus entry in /etc/resolv.conf
 

My /etc/resolv.conf has a bogus entry: my DSL router. Many applications are hanging waiting for my router to provide name service. Others are apparently able to look past the bogus entry to the correct entry. When I delete the entry by hand, all applications work, but my changes get overwritten the next time I boot. What is the correct way to change the configuration so that this entry does not appear?

Here are the relevant stanzas from my /etc/network/interfaces:

auto lo
iface lo inet loopback

iface tg30 inet dhcp
name Network connection on Broadcom NetXtreme BCM5788 Gigabit Ethernet
device Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet
plugable true

I studied the man page for interfaces(5), but I don't see how to specify the nameservers in /etc/network/interfaces.

My /etc/resolv.conf contains

nameserver 192.168.0.1
nameserver 205.171.3.65
search domain.actdsltmp

The first is the bogus line. The third line also suffers from mild bogosity -- it is not useful, but I don't think it will hurt having it there. The DSL router is made by Actiontec, so I suppose that must be where the domain name comes from (act from Actiontec + dsl + tmp).

Any suggestions of how the /etc/network/interfaces needs to be changed to prevent the generation of the first nameserver entry in /etc/resolv.conf?

two things. first of all, there's an -R option for dhcpcd, which will prevent it from overwriting your resolv.conf. i'm not sure where dhcpcd is called on your system (in slackware it's /etc/rc.d/rc.inet1, if that helps), but you need to add the -R option.

but on to my second topic. you need a nameserver. either you can specify your own in a static resolv.conf, or you can let the dhcp server supply it for you. now, a lot of routers act as caching nameservers by default. it may be worthwhile to log into your router by opening firefox or whatever your browser is, and typing 192.168.0.1 in the address bar. then look around for any mention of dhcp and/or nameservers, maybe you can stop the problem at it's source, and then leave dhcpcd alone. post up what you find if you need help.

I can't find dhcpcd (or just dhcp) in the files in any /etc/rc* directories.

My router does not cache. I have poked around in the router's configurator several times but see nothing that appears to be relevant.

I contacted the router manufacturer. They claim that it is normal for a router to return its own IP number as one of the DNS servers. I found some evidence on the web that this claim is true. In fact, I discovered that my old OS has the same nameserver entry in its /etc/resolv.conf, yet when I ran the old OS no application ever had a problem accessing the Internet. Apparently, something else changed, and deleting that nameserver entry circumvents the problem. It makes sense that the router would return its own IP number, because it knows to forward DNS requests to the real DNS server. In fact, whether I do

dig <the real DNS server> www.yahoo.com

or

dig 192.168.0.1 www.yahoo.com

I get an answer. If dig can get names resolved by sending DNS requests to the router, then Firefox must be able to as well. Yet Firefox hangs unless I delete that nameserver entry from /etc/resolv.conf. Any other ideas?

I took a break for supper and when I came back Firefox was working even with the "bogus" entry. I don't know what's been going on with my system, but for now I am considering the problem solved.

Bogus Entry in /etc/resolv.conf
 

Been away a long time, but something odd is occuring
Just installed Mandrake/Mandrive 10.2, very nice, but networking was odd.
Everthing on the internet was accessible, except by Firefox.
Turned out to be the 192.168.0.1 router entry in resolv.conf.
Corrected this, and the problem was solved....
But no, something is apparently overwriting it !
Even when all write permissions are removed from the file
Something very powerful ....
I am currently running dhclient, and I suspect this. Cannot tell why it affects only Firefox ( and NTP setuup as well... )
Probably have to go static until I can cure it.
Any Ideas ?

First of all, correct /etc/resolv.conf. Secondly, configure dhclient not to overwrite /etc/resolv.conf. Here is how,

1. locate directory dhclient-enter-hooks.d in /etc, in a Debian based system, it's in /etc/dhcp3
2. change .../dhclient-enter-hooks.d/dhclient-enter-hooks to have,
That will do the trick.

Bogus entry in /etc/resolv.conf
 

thanx unxrl for the tip

However, the Mandrake/Mandriva 10.2 install I was using was not quite as you have advised. The install did not make and of the following files : dhclient.conf, dhclient-exit-hooks files, and the dhclient-script turned out to be in /sbin. I found the make_resolv_conf() function is in this file.
I have made the modification now and am about to test it - but I expect it should work.
I could also have probably unchecked the 'get DNS servers from DHCP in the system config as well, but the relay should work... (It does with WIN#$%#%$#%$)
I reckon also from the man pages that using the -g option with dhclient could work, but when I looked at the scripts I saw they are quite involved.

Now I reckon that I am an experienced programmer - 30 dialects of basic's over 30 years, 15 assembly languages, C, C++, fortran, and even pascal, and have extensive infrastructure systems in current use in the field eg Railway signal control systems (Borland C++), Vital control systems with voting computers in assembly language (Z80 - yay!) temperature monitoring systems for rail buckling (Microsoft C++), and Council herbicide vehicles, with technologies from GPS, GPRS, MDB(yeerk!), UDP (including in DOS with from packet drivers, ARP, RARP, ICMP, TCP, PLCs (12 types), and too many others to list, but oddly I have not yet learned the basics of the bash shell ! If anyone can point me to a good on-line reference I shaould be quite gratefull. The Man pages are quite good IMHO, but I need to know the shape of the language to get the best out if it, eg the thinking behind good C & C++ programs is actually quite good to really drive it along.
Regards
James Fuller:D

Try: http://www.tldp.org/LDP/abs/html/

thanx folks
sorry to mispell your sign, nuxrl. From that post, I am surprised nobody has told me that before I can program, I need to spell. Looks like a good site camh, cheers.
Regards, james

-------------------------

yeah mate : before I can program, I need to spell

Good luck to everyone who needs knowledge
------
Knowledge is POWER

Re: Bogus entry in /etc/resolv.conf
 

I know this is a bit late for a reply. :)

Having just gone through a similar sequence (bogus IP address in /etc/resolv.conf), yet experiencing no trouble at all with several Macs, Windows (hardware and virtual), or a couple of older Linux distributions, I trolled Google, LQ, and several other sites for information.

Most of the fixes and work-arounds pointed to modifying resolv.conf and other DHCP-related files.
This is fine for someone who does have the time and the desire to fix things that should not be broken in the first place.

Looking at the issue from the perspective of someone who will be giving a Linux-based machine to a shelter as a donation, the idea of the work-arounds is neither practical or acceptable, although the information was valuable and will be kept for future reference.

Researching the problem caused me to re-install my original Verizon-supplied Westell ADSL modem and Linksys BEFSR41 router: the problem vanished regardless of the Linux version and the DHCP client version used.

Next, the Actiontec (sound familiar ?) GT704 was placed back in operation: the problem re-appeared in all its splendor.

A decision was made to replace the Actiontec unit with a product from Zoom Telephonics, their model 5654.

The problem vanished.

I certainly respect and appreciate all the effort put forward by so many responders through various forums, but it appears that the root of the problem lies entirely with the Actiontec brand of ADSL modems.

Although I did look for firmware updates, official and non, the GT704 was purchased with the most recent firmware revision available from the manufacturer.