Closed Bug 109313 Opened 23 years ago Closed 21 years ago

DNS: Proxy: caching prevents proxy switching from working

Categories

(Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME
mozilla1.2alpha

People

(Reporter: drfickle, Assigned: gordon)

References

Details

I have two network profiles that I use, one for home and one for work.
Obviously they have different DNS servers. When I have Mozilla running at
home, switch my network profile, come to work, enable the proxy server via
the Settings menu, Mozilla will not use the proxy until I restart it. I
assume this is because it is caching my DNS servers from home when I first
started it and now that I am at work it can no longer contact them. Once I
restart Mozilla, it now finds my work DNS servers and the proxy begins to
work. I could be wrong in my assumptions, but something is requiring me to
restart Mozilla before things will work. 

Thanks.

P.S. I normally use Galeon, but I also verified with Mozilla 0.9.5.
"DNS caching" is generally considered the caching of DNS lookups, not the
servers, but I think you understand the underlying problem. We don't really
cache, its more like we load once, and never look back.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's really glibc that's caching /etc/resolv.conf so it's sort of a 
system issue. There are ways around it but they're very non-standard.
Ah, being that my web browser is the only proxable app that I keep open between
work and home, I guess I never thought about it being a glibc issue. I did say I
was guessing right? :) 

It'd sure be nice to have this working magically, but consider it a wishlist
item I guess. There are probably more important bugs to squash.

Thanks.
I think we will be getting to this soon. It should start affecting more Netscape
corporate laptop users soon (VPN usage should go up now that we upgraded to
something usable).

:)
Whiteboard: dupeme
On Linux, one workaround is to run a local named as a caching-only DNS 
server and use that in/etc/resolv.conf. When you switch networks you 
restart named with a new configuration.  No user app, like mozilla, ever 
sees the change.
dns
Assignee: neeti → gordon
Target Milestone: --- → mozilla0.9.9
Priority: -- → P3
Target Milestone: mozilla0.9.9 → mozilla1.0
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Would this bug be fixed by means of the recently fixed bug 64857 ? Seems to be a
very similar situation.
*** Bug 158511 has been marked as a duplicate of this bug. ***
reporter, one additional question: what did you mean by "network profile" is
that a specific feature?
Summary: DNS server caching prevents proxy switching from working → DNS: server caching prevents proxy switching from working
Network profiles is a feature offered by linuxconf to change your DNS servers,
network interfaces, and gateway for people who don't use DHCP. I used to use
token ring at work, then come home to ethernet. Once your profiles are set up,
you can call 'linuxconf --selectprofile [Home|Office]' to change your settings. 
I don't use that feature in Linux, so I guess it is another item I need to learn
more about. Thanks for the info.
I had similar problem.
Here are the steps in which I reproduced it.
i start mozilla, set it up to use proxy called 'proxy' on port 8080.
At this time proxy has a dns entry 192.168.1.234
When the proxy is up everything works. I shutdown the proxy server, and mozilla
no longer can work.
I start another proxy server on 192.168.1.233, and change the dns entry for
'proxy' to this IP address.
Then I expect Mozilla to continue to work, but it doesn't.
If I try Windows NT's 
ftp proxy
I connect to the new IP address, same with ping. So it doesn't seem like caching
by the operating system.
I tried loading a couple of pages, but with no success. And Mozilla tell me it
cannot connect to www.mozilla.org, instead of telling me that it cannot connect
to the proxy server.

If I stop mozilla and start it the problem disappears. Only then mozilla
recognizes that 'proxy' no longer means 192.168.1.234 but 192.168.1.233.

This happens with Mozilla build 2002081204 on Windows NT.
Blocks: 61683
The problem is sounding like a record caching (vs. a DNS server list caching)
problem. 
Summary: DNS: server caching prevents proxy switching from working → DNS: caching prevents proxy switching from working
This has been annoying me for some time on SuSE 8.0.
In SuSE, if you control your PPP dialup connection from the desktop,
then you will go from no route to the internet and no dns, to route through the
ppp0 device, and your chosen dns for you ISP.

This means all SuSE dialup users will be annoyed by this problem if they try to
work offline. (Off line, in terms os terms, not mozilla's)
They cannot work on-line till they re-start mozilla.

In SuSE the Konqueror browser copes with DNS changes in resolv.conf
This bug seems to be related to bugs 151683 & 117613.
I'm not at all sure which of these bugs I've been seeing.
Might they be duplicates?
They are all related, but I'd like to keep them separate for a while, until I
sort everything out. Even if it is the same problem, I like to keep separate
bugs for each area (mail, proxy, browsing...) that is affected.
The bug seems to be universal. I'm using Mozilla under Windows.

I'm also roaming between home and office, where in both cases a server called
"proxy" (within different domain suffixes) exists. If mozilla is configured
manually to use "proxy" as the http proxy server, it once looks up the IP
address and never does a lookup again. Thus, after switching the environment
(and connecting another ethernet cable to the laptop and receiving a new IP
address per DHCP), mozilla still wants to contact the proxy server using the old
IP address. Unfortunately, that proxy-server is not reachable anymore (but the
new proxy server is).

The problem is the caching of the DNS record for the proxy server name.

A solution would be to do RFC conformant cacheing of the proxy DNS records (in
the operating system) and to do lookups (from the application view) on every
proxy usage.

Thus, the application lookups will be received by the operating system. The
operating system decides when to forward the lookup to a DNS server. It should do so
(1) if the current cached record has expired or
(2) if the current DNS suffix has changed

The latter is important, because for proxy server names which are not fully
qualified, the mapping from simple names to IP addresses not only depends on the
DNS servers but also depends on the current domain name suffixes.

If the operating system resolving method does not comply to this requirements,
mozilla should emulate a correct implementation.
There are sound reasons for fixing this bug, but I wanted to note that your
configuration is not a good one.

You should be using fully qualified domain names (FQDNs) for everything, even
proxy servers. Using hostnames for a service that provides networking access is
not a good idea. Although we generally want to fix things, we would not go out
of our way to support a config that you have described.
Depends on: 162871
Whiteboard: dupeme
*** Bug 207792 has been marked as a duplicate of this bug. ***
> You should be using fully qualified domain names (FQDNs) for everything, even
> proxy servers. Using hostnames for a service that provides networking access is
> not a good idea. Although we generally want to fix things, we would not go out
> of our way to support a config that you have described.

Using the same fully qualified hostnames is not possible (at least feasible) for
two distinct hosts. There are two proxy servers, one at home and one at office.
The office-proxy server may only be used from within the office's IP address
space. The home-proxy server can only be used from within the home's (private)
IP address space. If users were forced to use fully qualified host names for
proxy servers, they would have to change these settings eacht time they change
their location, e.g. twice a day.

If this kind of configuration could be automated (e.g. via DHCP or another
location sensitive autodetection method), we would not need to make proxy host
lookups expireable. But behaving as specified by DNS is good.
I just found the message below at
http://www.mail-archive.com/mozilla-netlib@mozilla.org/msg01608.html :


Proxy & DNS cache

    * From: wolruf
    * Subject: Proxy & DNS cache
    * Date: Wed, 25 Jun 2003 15:29:12 -0700 

Hi,

I have the following issue and wonder how to solve it:

- I have Mozilla on Win2k setup with a proxy as a host name called "proxy",
- I connect to a HotSpot[1] where my proxy is transparently handled (i.e.
spoofed to 1.1.1.1 for eg., usually with a low DNS TTL: 1),
- I launch a VPN client which connect me with a new IP address and new DNS
settings (new search string and DNS IP address),
- the proxy should now resolve to "proxy" + the default search string
"corporate.com" -> proxy.corporate.com which then resolve to 172.16.1.1.
- however, Mozilla doesn't re-resolve "proxy" to be used as proxy and still use
the old IP address for this host (1.1.1.1),
- I have to restart Mozilla to "reset" the proxy host to its new IP address.

I looked at the code and cannot see if there's a way for the proxy host
resolution to respect the DNS TTL.
All DNS requests work fine, it's just that the proxy host got "cached".
Is there anyway for Mozilla to know that the DNS settings changed and he has to
re-resolve the proxy hostname just once (obviously, he shouldn't re-resolve for
every request) ?

IE6 has the same issue.
Mozilla on Linux may behave different as it has it own DNS resolver but I guess
the proxy host will also be cached for the whole session.

This is more and more frequent with HotSpots implementing this kind of
plug-n-play feature.

Olivier.

PS: It's a coincidence that Darin actually talk about a DNS rewrite in his blog :)

[1] HotSpot example: StarBucks coffee, etc.
I have tested that bug a bit with settings:

  user_pref("network.dnsCacheEntries", 32);
  user_pref("network.dnsCacheExpiration", 10);

(the DNS entry "proxy" has a timeToLive of 60 seconds)

The result is:
- If you request http://proxy/ as an ordinary page, a DNS lookup can be observed
on the network.
- If you request http://proxy/ as an ordinary page 20 seconds after the request,
no lookup can be observed on the network. This may be due to the operating
system (Windows XP) caching the application request.
- If you request http://proxy/ as an ordinary page 70 seconds after the request,
you can observe lookup on the network again. This behaviour is expected.

- If you request using an arbitrary URL with "proxy" as the configured HTTP
proxy, a DNS lookup can be observed on the network.
- If you re-request using an arbitrary URL with "proxy" as the configured HTTP
proxy 70 seconds after the first request, you still cannot observe a DNS lookup
on the network.

Thus, it seems, the proxy server IP address is handled different from the
web-site IP-addresses.
folks, now that bug 162871 is fixed, can you please test a recent nightly build
of mozilla?  you would need to grab a pre-1.6a test build.

marking WORKSFORME.  please reopen this bug if the problem persists.  thanks!
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
I no longer have a proxy at home or at work, so I cannot test this. Hopefully
some of the other commenters can test it. Thanks.
I have just downloaded and tried the following:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20030924

The IP address for proxy is renewed only after clicking "disconnect" and
"connect" icon on the botton right corner of the browser. Othervise, if I do not
reconnect, the IP entry for proxy stays the same.

This is what I needed and expected. Thanks!
VERIFIED:

actually, this bug is two problems, the morphing occurred at #14.

The original problem was that in Linux/UNIX only, the DNS server entries would
not update when you switched networks.

Related, but a separate problem, is the on-again-off-again DNS caching, which
has probably existed as three distinct implementations since Comm 4.

Mihail, Xuan and Marius are talking about this second type of problem.

I'm generally displeased with the new nature of the bug, I've unduplicated Bug
207792, and will ask Darin to give a verdict there on what I consider to be a
separate design issue:

Should proxy name -> IP mappings receive special caching treatment?

Discussion should occur on that bug.
Status: RESOLVED → VERIFIED
Summary: DNS: caching prevents proxy switching from working → DNS: Proxy: caching prevents proxy switching from working
You need to log in before you can comment on or make changes to this bug.