198594 - DNS: "shift-reload" should reload DNS cache too, and be documented

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Brad Garcia]

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.

Comment 1

[benc]

-> NEW, +clean-report

That is a really good idea. I wish I had thought about it.

Comment 2

[Doug Turner (:dougt)]

-> gordon

Comment 3

[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?

Comment 4

[Darin Fisher]

i like this idea too, but definitely only for the shift-reload case, since i
think javascript can cause a normal reload to occur.  we'd need to check the
LOAD_BYPASS_CACHE load flag on each channel.  getting this to be done only for
the first occurance of a domain per overall page load will be very tricky since
we don't have any existing machinery for that in necko, save for the loadgroup.
 we could perhaps tack on some info to the loadgroup.  or we could maybe just
add a minimum freshness time to the cache(s) such that a shift-reload would be
ignored if a DNS lookup had not sat in the cache long enough.  that would mostly
suffice if tuned correctly (which is a big "IF" i know).

as for the socket transport's cache, remember that the DNS service is actually
wedged behind the socket transport.  so, in order for the channel's to cause the
DNS's cache to be bypassed, the channel's would have to pass some info to the
socket transport that it would have to then pass onto the DNS service.  so, the
socket transport would necessarily know what is going on =)

Comment 5

[Brad Garcia]

I *strongly* disagree with doing this for shift-reload.  It should be done
whenever the user requests a reload.

You are making a bad assumption - the assumption is that the user even knows of
the existence of shift-reload.  The user does not.  I still don't know what
shift-reload does.  When I search for "shift reload" in mozilla help, it turns
up nothing.

The user knows about the reload button, and they know about the reload menu item
under the "View" menu.  That is all.  If you want javascript reloads to not
affect the DNS cache, then make javascript reloads behave differently than
UI reloads.

Comment 6

[benc]

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.

Comment 7

[Darin Fisher]

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.

Comment 8

[benc]

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.

Comment 9

[Matthew Elvey]

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.

Comment 10

[Robert Accettura [:raccettura]]

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.

Comment 11

[Tom Whipple]

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.

Comment 12

[benc]

Tom: new bug please. The cache expires by default after 60 seconds.

Comment 13

[Tom Whipple]

(In reply to comment #12)

Bug 232335 has been entered, as requested.

Comment 14

[Andrew Hagen]

*** Bug 166146 has been marked as a duplicate of this bug. ***

Comment 15

[:Gavin Sharp [email: [e-mail]]]

*** Bug 277829 has been marked as a duplicate of this bug. ***

Comment 16

[Patrick McManus [:mcmanus]]

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).