117613 - DNS: Cached state of failed prior lookup supersedes available nameserver

Status: VERIFIED INVALID

(Core :: Networking, defect, P3)

Description

[Mozilla.20.TEN]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.5) Gecko/20011012
BuildID:    2001101202

When the name server is not (yet) available (e.g. in a dial-up environment),
Mozilla will report that the domain entered could not be resolved, and ask the
user to retry at a later point in time.
However, it will KEEP doing so (even after reducing the
network.dnsCacheExpiration" down from its default of 5000) until the browser is
closed and restarted (see Additional Information below for workaround), even
when the name server has become available, i.e. even though the DNS lookup could
then be carried out successfully.

Reproducible: Always
Steps to Reproduce:
1.Be sure not to have access to the name server (e.g. on ISDN dial-up without
DoD, this would be the case after isdnctrl hangup ipppX)
2.Close and restart Mozilla
3.Try to access an URL that is known to exist and requiring to be resolved
through DNS
4.Expected error message shows up
5.Now make sure system does get access to the name server (e.g. by isdnctrl dial
ipppX in above setup, or by setting the appropriate route to the internet gateway)
6.Retry to access the URL chosen above
7.Wait for the timeout specified in your prefs.js to elapse
8.Retry to access the URL chosen above
9.Retry any other URL that is known to exist and requiring to be resolved
through DNS

Actual Results:  The error message keeps reappearing even though the DNS is
available
on points 6, 8 and even 9 above.

Expected Results:  In the above cases of 6, 8 and, definitely, 9, the IP address
not being known yet, it should have been resolved by retrying to query the DNS
which had become available, rather than relying on a cache which does not hold a
result yet

Workaround: Other than closing and restarting the browser, 
when the connection to the Internet (and therefore the name server) has become
available,
clicking File/Work Offline, then File/Work Online will remedy the situation,
i.e. the domain will be resolved properly after performing these steps.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** This bug has been marked as a duplicate of 64857 ***

Comment 2

[benc]

Based on other comments, this sounds like a problem where DNS stops working if a 
DNS query fails to connect to the server.

Comment 3

[Andreas Kunz]

Just want to add that I am able to reproduce that on Win95 using Mozilla 0.9.9. 
(directly entering the IP number instead works).
The "Work offline/online" workaround does not work around anymore (as Al already 
stated for Linux in Comment #66 of Bug 64857).

One difference I see is that with no connection during startup and first DNS 
lookup the only way to make Mozilla work again is restarting it, 
while everything works well after the dial-up connection has only been 
interrupted for some time and a DNS lookup has been tried during this 
interruption (of course without success). Even if the internet provider is a 
different one, DNS lookup works again after reconnecting.
This means that I do NOT see "DNS stop working if a DNS query fails to connect 
to the server" (although I have to admit I also had this impression before I 
tested it minutes ago).

Comment 4

[benc]

Enhancements to DNS service are coming, to make it smarter.

Still, I think we need a button for the user, hence bug 140232.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Is this not just bug 117628?

Comment 6

[benc]

Probably. I am going to re-read everything after I verify that fix, b/c I
suspect there is more than one Linux-only problem.

Comment 7

[Kai Lahmann (is there, where MNG is)]

just saw this yesterday (with 2002073022), added a host which DNS was broken to
my /etc/hosts and it didn't help - other browsers had no problem, because they
wheren't running before - so it can't be that FIXED bug ;)

Comment 8

[benc]

That might suggest that the DNS cache is not reset on failure, but we also have
new DNS behavior, perhaps neeti could find out who would be the best person to
explain those changes.

Comment 9

[neeti]

-->dns

Comment 10

[hirata masakazu]

I have been getting this bug for sometime. I hate this because I use notebook
computer with both wireless and wired networkings.
Everytime I switch networking, I need to relaunch Mozilla to access sites
previously accessed via different networking.
MacOS9.x 2002082008 trunk.

Comment 11

[hirata masakazu]

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

Comment 12

[Adam Hauner]

Dupe was Mac/MacOS X -> All/All

Comment 13

[Dave Oftedal]

I'm beginning to doubt that mozilla was ever made for use with DNSes.

And no, going offline, then online, changing the DNSes, waiting 15 minutes or
anything else doesn't work.

Just tell me where this cache is so I can delete it.

Comment 14

[gordon]

It looks like the offline/online toggle via the File->Work Offline menu is no
longer clearing the DNS cache and I consider that a regression.  It shouldn't be
too hard to fix.

There are other places DNS results can get cached as well (glibc, socket
transport service, PAC), and fixing the DNS service won't help or hinder those.
 If they still cause problems after this bug is fixed, we'll need to open new bugs.

Comment 15

[benc]

gordon: if you are going to fix that UI element, could you do it by reopening
bug 192798, or filing a new (regression bug)?

This bug really should be marked as a dupe of a "network.dnsCacheExpiration" or
"I don't like your caching behavior" bug. 

Comment 16

[gordon]

Okay Ben, I've reopened bug 192798, and added David Oftedal to the cc list (so
he can see when we fix it).

You can dup this one to whatever you want.

Comment 17

[benc]

RESOLVED/dupe:

This bug actually mixed up several problems, so I reopened the dupe and will
clean that up separately.

The original report was a linux user suffering from cached DNS servers (hence
the appearnce of failed requests being cached).

That is caused in part by our lack of good DNS error handling, bug 164715.

The user's expectation that DNS cache should expire is bug 164715, but the
actual situation never made it that far, so that is irrelevant.

Since we don't have a negative cache, the summary is largely invalid (bug 164715
requests this as a feature).

So, based on the summary, invalid.

Comment 18

[Matthias Versen [:Matti]]

verified invalid