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). :)
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.
Assignee: neeti → gordon
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 firstname.lastname@example.org. 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.
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
*** 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://email@example.com/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 where my proxy is transparently handled (i.e. spoofed to 22.214.171.124 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 (126.96.36.199), - 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 :)  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
Last Resolved: 15 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.