Closed Bug 198594 Opened 18 years ago Closed 9 years ago
DNS: "shift-reload" should reload DNS cache too, and be documented
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030302 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030302 The "reload" button has the effect of telling the browser to ignore the cache and to talk to the server to fetch the page. It should also tell the browser to ignore the DNS cache. Otherwise, the only way to force the browser to get new DNS information immediately is to shut it down and restart it. I know there are several *similar* PR's dealing with DNS caching, but I didn't see any that specifically say that the reload action should cause the cache to be ignored. Please don't mark this as a DUP unless the original PR specifically mentions this. Reproducible: Always Steps to Reproduce: 1. Access a web site 2. Change that web site's IP address & DNS entry 3. Try reloading the page Actual Results: mozilla keeps trying to access original IP address Expected Results: mozilla should refetch dns information and access new IP address.
Summary: DNS cache should be ignored for "reload" → DNS cache should be ignored & updated for "reload"
-> NEW, +clean-report That is a really good idea. I wish I had thought about it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: DNS cache should be ignored & updated for "reload" → DNS: "reload" should reload DNS cache too
Assignee: dougt → gordon
I like this idea, but I think it should be tied to "shift-reload" rather than a simple reload. It could be tricky to implement. When loading a page via shift-reload, ideally we would only flush those DNS cache entries requested by the page, and only the first time they are requested. Currently the DNS Service doesn't have access to the state, and doesn't have an interface to clear a specific DNS entry. Adding a flag to flush a DNS entry would be easy to add, but then well need to change doc loader or layout to use it. Of course, the socket transport also caches dns results, which may make the cache in nsDnsService completely redundant. I'm not sure if it's feasible for the socket transport to cooperate in the "flush DNS cache on reload". Darin, what are your thoughts on this concerning the socket transport?
Status: NEW → ASSIGNED
These are somewhat independent. I think clearly yes for shift-reload. Reload sounds desirable to some, but my understanding is that there is an assumption that reload always causes network-level events to fire, and I don't think this is true in all cases.
benc: no, reload always means talk to the server. sometimes that only means talk to the proxy server. but, we always try to make sure that the user sees the most up-to-date copy of the document following a reload.
darin: thanks for the extra info. I might have been thinking a little bit about "refresh", which in Communicator may not have re-loaded from the network. The other point I was mulling is that reload is for most situations (load that file again), while shift-reload has more application when the user feels the expected data is not going to arrive unless a more comprehensive, lower-level set of events are triggered to reload the file. It sounds like we all agree here, so I've changed the summary.
Summary: DNS: "reload" should reload DNS cache too → DNS: "shift-reload" should reload DNS cache too
Reassigning bug to owner and QA contact of selected component, as gordon is 'gone', adding doc request to summary (Should be offshoot bug?). FYI, some good news: Bug 192798 (DNS: Offline->Online does not clear the DNS cache) has been fixed.
Assignee: gordon → darin
Status: ASSIGNED → NEW
Summary: DNS: "shift-reload" should reload DNS cache too → DNS: "shift-reload" should reload DNS cache too, and be documented
I've experienced this quite a bit as well (most recently today). Would be nice if Mozilla/Firebird would support ignoring DNS info (and retrieving fresh) when the shift key is used. It makes sense, considering it should completely refresh the information, ignoring all cashe.
This could be considered a security problem. Here's the situation: A user looks up an intranet host on a laptop, puts the laptop to sleep, and moves to a different network. The user then thinks he has VPN'd back to the intranet, but the connection fails for whatever reason. The user then attempts to access the same intranet site, but gets a completely differenent host (same private IP). If that host was malicious, it could attempt to steal login information from the user. (If it isn't malicious, it is still confusing to the user.) I propose deleteing the _entire_ DNS cache if the hosts DHCP assigned ip address changes. Or at least if the subnet changes.
Tom: new bug please. The cache expires by default after 60 seconds.
*** Bug 166146 has been marked as a duplicate of this bug. ***
*** Bug 277829 has been marked as a duplicate of this bug. ***
shift-reload forces that host's dns entry (or the proxy's dns entry) to be looked up in cache bypass mode (which will then update the cache).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.