Bug 9974 - something keeps putting "stanford.edu" in /etc/resolv.conf
Summary: something keeps putting "stanford.edu" in /etc/resolv.conf
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ppp
Version: 7.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-03-05 11:18 UTC by Jamie Zawinski
Modified: 2007-04-18 16:26 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-14 18:04:45 UTC
Embargoed:


Attachments (Terms of Use)

Description Jamie Zawinski 2000-03-05 11:18:11 UTC
I'm not sure under what conditions it happens, but something keeps
editing my /etc/resolv.conf to read:

	# eth0 begin
	search stanford.edu
	# eth0 end
	domain jwz.org
	search jwz.org
	nameserver 168.253.48.19

when previously it had read:

	domain jwz.org
	search jwz.org
	nameserver 127.0.0.1

The last time this happened, I even made resolv.conf be read-only, but
no, whatever does this overwrote the file anyway.

First of all, setting my search path to include stanford.edu is completely
insane, and I can't figure out *where* this is coming from.  I have no
association with Stanford, and have never typed that word into any
configuration script, ever.  I grepped in the usual places, and I can't
figure out where "stanford.edu" is coming from.

Second, changing my nameserver to some random one (where in the world did
it get that one?) is unacceptable.  I have a cacheing name server running
on localhost and I want to use it.  Don't second-guess me.

I suspect this happens as a result of running "usrnetctl" to bring the
eth0 and ppp0 interfaces up and down, but I'm not sure.  Sorry if I've
picked the wrong module.

Comment 1 Nalin Dahyabhai 2000-03-06 13:50:59 UTC
If you're using rp3 and/or wvdial, the wvdial dialer will use MSDNS information
supplied by your server to modify the resolv.conf file.  The latest version of
initscripts adds a sanity check to this (specifically, if the first DNS
server address returned is already in resolv.conf, the list remains unmodified,
specifically to not trash people who are using caching nameservers).

Please grab the versions of ppp, wvdial, and rp3 from the 6.2 beta and see if
together they solve the problems you're experiencing.

Comment 2 Nalin Dahyabhai 2000-06-10 21:42:39 UTC
Any news?  If not, I'll close this bug.

Comment 3 Jamie Zawinski 2000-06-11 00:08:44 UTC
Sorry, I never got around to trying this because I basically gave up
on using my laptop as a laptop.  Now it just sits on my desk all the
time, and it mostly works.  Trying to change its network connection,
or trying to run on battery power, or really doing anything laptop-like
at all, just makes Linux malfunction in a thousand different ways, so
I finally learned my lesson and stopped.



Comment 4 Need Real Name 2001-08-07 08:03:01 UTC
pppd seems to change the resolv.conf.
I tested it on RedHat 7.0 and RedHat 7.1.
It happens when you dial up.
I scanned the newsgroup for a solution.
As I understood them right pppd seems to tell the system some DNS servers which 
then are at resolv.conf
They where talking about dhcp

To change this behaviour at PEERDNS="no" at cat /etc/sysconfig/network-
scripts/ifcfg-ppp0

This is not documentated at the man pppd pages !
It will prevent pppd from changing the DNS servers at resolv.conf

I personaly think pppd by default shouldn't change resolv.conf.
(I've no dhcp but a static IP on dial up)
Changing DNS could fool systems on my local LAN.
What if I would make a paymant to largebank.com to a spoofed server.
(Someone with a spoofed site looking like largebank.com)
This way they could retrieve my credit card number.

Also its better to use the local nameserver for speed.



Comment 5 Stephen John Smoogen 2003-01-24 16:34:49 UTC
There have been large amounts of changes in the PPPD, kernel, and network code
since Red Hat Linux 7.1. Is this still a problem in Red Hat 8.0

There are a couple of things that could be listed as RFE items from this, but
should be done as new tickets.

1) Network/PPP tools should allow for a no-change flag to be set. In most cases,
the user of a dial-up should trust the information of DNS, routeing, etc that
the ISP provides. That way when the ISP changes such values, their clients are
quick to get new routes, DNS servers etc instead of complete failure, extra
support costs, etc. For the users who are not in a trusted environment with an
ISP, they should have the option of turning this off.

Comment 6 Jay Turner 2003-04-14 18:04:45 UTC
Closing out due to bit-rot.


Note You need to log in before you can comment on or make changes to this bug.