170694 - Hostname with dead DNS server makes resolver very slow, inoperable

Status: VERIFIED DUPLICATE of bug 70213

(Core :: Networking, defect)

Description

[mike]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020920
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020920

It seems that, whenever the name server for my domain name goes down, Mozilla
becomes very unusable: domain names take 30 seconds or so to resolve.

Background: my machine's hostname is xyz.domain.com (different domain, of
course, but same format). I use mozilla for mail; however, no mail servers are
resolved by ns.domain.com. This behaviour is seen without ever launching the
mail component.

Now, back to the problem. Domain.com is a badly managed domain; of the two
nameservers on record with network solutions (the registrar), the first host is
the authority on xyz.domain.com and all of domain.com, but has dropped offline.
The second host, which is an old NS that no longer has any authoritative
information on domain.com, is up, but probably can't resolve the domain because
it would have to ask the dead host anyway.

In other words, there is no good way to resolve the hostname, since the only
server with any information on it is down. But for some reason -- which I
attribute to mozilla repeatedly trying to resolve my hostname with every and any
NS lookup it performs -- it takes mozilla about 30 seconds to realize this,
during which time no other lookups succeed.

I think the problem is this: either because the first NS is offline, or because
the second NS is reachable but cannot resolve the name, we have this problem.

So, when my DNS server drops offline, ever NS resolution by mozilla takes 30-40
seconds. (They do, however, get cached internally). Resolving at the command
line takes <1 second as expected, any domain


Reproducible: Always

Steps to Reproduce:
1. set hostname to something.domain.com
2. knock primary NS for domain.com offline. optionally set secondary NS of
domain.com to some host that really knows nothing about it. (note: not sure if
this optional step is crucial or not; have only tested as described)
3. attempt to surf. note slowness in resolving (but speed in subsequent
resolving = cached)

Actual Results:  
Hostname lookups dreadfully slow, somehow due to a timeout in attempting to
contact the dead NS (probably trying to resolve hostname).

Expected Results:  
I would expect mozilla to, at the very least, respect /etc/hosts before trying
to contact external NS. I have /etc/nsswitch set as desired. Additional, I
question the need to lookup the hostname (if that is indeed what the resolver is
doing). Finally, whatever the source of the 30-second or so delay, I would
expect mozilla to not block other resolver requests. I don't really mind if moz
tries to contact my dead NS for 30 seconds, or 30 minutes -- so long as it
doesn't affect my other priorities.

Will attempt to produce logs from mozilla, but might not be able to. (No
experience compiling mozilla / using dev options.)

Comment 1

[Jo Hermans]

Mozilla isn't doing anything special - it's using the resolver of the OS to
lookup the name. What are you using to "resolve on the commandline" ? If it's
nslookup, then you're *not* using the resolver, but you're directly going to the
nameserver.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> I would expect mozilla to not block other resolver requests

That's bug 70213

Comment 3

[mike]

> Mozilla isn't doing anything special - it's using the resolver of the OS to
> lookup the name. What are you using to "resolve on the commandline" ? If it's
> nslookup, then you're *not* using the resolver, but you're directly going to the
> nameserver.

I'm using 'host'. Nevertheless, it appears comment #2 is the source of the
problem: the behaviour I am seeing indicates that the NS lookups are indeed
serialized.

Parallel NS requests would hide the problem, so this part may be a dupe.. Though
the other may still remain: does the hostname really need to be resolved?

Additional comment: I forgot to mention that the startup time is increased with
the same timeout whilst the hostname is unresolvable. That is, my browser window
won't show up until this ns request hits its timeout.

Comment 4

[Jo Hermans]

ok, it's a dupe of bug 70213. 

BTW, we're using gethostbyname() internally (see
http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/misc/prnetdb.c#694 ),
just like any other application ... But that's an interface that sucks big - no
io-completion, serialised access (on most platforms), no timeouts, ...

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

Comment 5

[benc]

VERIFIED/dupe
We've had some reports that /etc/hosts is not working for people, but that
should be mentioned in a separate bug (please include /etc/nsswitch.conf if you
file).