177062 - DNS lookup failure and appending DNS search to FQDN

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Jeff Mandel]

FQDN lookups fail at times with build 2002101612. I experience the same problem
on the Solaris 8 build. (sorry I don't have its 1.2b build number handy) This is
a DNS bug that was common in Netscape. Snoop shows the actual lookups generated.
Mozilla is trying the FQDN with "." at the end, but doesn't seem to wait for the
reply before sending another request:
nudnik.chinik.com -> ns1          DNS C www.mozilla.org. Internet Addr ?
nudnik.chinik.com -> ns1          DNS C www.mozilla.org.probes.com. Internet Addr ?
         ns1 -> nudnik.chinik.com DNS R  Error: 3(Name Error)

It will search through as many domain searches as you have in your DNS resolver.
I think the key here is why it misses the first one, but also why it would
continue down the search path when it already has a FQDN.

Comment 1

[Jo Hermans]

Mozilla doesn't generate DNS-lookups itself, it depends on the host OS itself to
resolve the name, which means gethostbyname() or a similar functioncall.

The behaviour is normal when the reply from the DNS-server arrives slower than
expected. You seem to have a problem with your network setup, maybe an
overloaded nameserver.

Comment 2

[Greg K.]

Jeff, can you reproduce this problem from another machine on a different network, preferably 
with different DNS configuration?

Comment 3

[Jeff Mandel]

This case was done back on the local network from solaris build 2002101422.

I just went down the list of bookmarks, the following was the first to behave
this way:
         ion -> ns1          DNS C www.sean.de. Internet Addr ?
         ion -> ns1          DNS C www.sean.de.probes.com. Internet Addr ?
         ns1 -> ion          DNS R  Error: 3(Name Error)
         ion -> ns1          DNS C www.sean.de.probes.nl. Internet Addr ?
         ns1 -> ion          DNS R  Error: 3(Name Error)
         ion -> ns1          DNS C www.packetfactory.net. Internet Addr ?
         ion -> ns1          DNS C www.packetfactory.net.probes.com. Internet Addr ?
         ns1 -> ion          DNS R  Error: 3(Name Error)
         ion -> ns1          DNS C www.packetfactory.net.probes.nl. Internet Addr ?
         ns1 -> ion          DNS R  Error: 3(Name Error)
         ion -> ns1          DNS C www.packetfactory.net. Internet Addr ?
         ns1 -> ion          DNS R www.packetfactory.net. Internet Addr
209.234.217.205

The third time is usually the charm. Netscape had the DNS helper that never
worked too well either. I have been using current releases of mozilla as it
comes out, this build was the first time I saw these resolver errors so
freqently. I used to ONLY see these problems on Solaris, with these builds I'm
now seeing the errors on both MacOS9 and Solaris.

name server is bind, on an E450
/usr/local/sbin/named -version
named 8.3.3-REL Mon Oct 28 09:21:21 PST 2002

On a secondary name server that has practically no load:
ion.probes.com -> ns2          DNS C aci.net. Internet Addr ?
ion.probes.com -> ns2          DNS C aci.net.probes.com. Internet Addr ?
         ns2 -> ion.probes.com DNS R  Error: 3(Name Error)
ion.probes.com -> ns2          DNS C aci.net.probes.nl. Internet Addr ?
         ns2 -> ion.probes.com DNS R  Error: 3(Name Error)
ion.probes.com -> ns2          DNS C aci.net. Internet Addr ?
         ns2 -> ion.probes.com DNS R aci.net. Internet Addr 209.151.201.29

These lookups never fail from nslookup.

If you think it's worth it, I'm happy to set my resolver to a public DNS you
suggest and see if I can get the same results, though that might introduce the
latency or poor performance issues Jo mentions.

Comment 4

[gordon]

Jeff, what are the actual URLs that you see this problem with?

Comment 5

[Jeff Mandel]

These were the ones I could get at the time I posted the snoop querries.
http://www.packetfactory.net/Projects/index.html
http://www.sjmercury.com/

They also worked eventually, usually on the third try. nslookup showed that it
was already non-authoratative, so the name servers had found and cached the
entry. Have people been adjusting the timeouts from local resolvers, if there is
such a setting in mozilla?

I've since restarted all of my name servers and flushed state tables on the
firewall. I will post the next url to fail as soon as I can get it.

Comment 6

[Jeff Mandel]

I think I've confirmed that this is happening almost exclusively over my DSL VPN
connection. I haven't seen a single instance of failed lookup since the
nameserver reloads and state table flushes mentioned in my previous posting. I
think this is probably a client DNS resolver timeout issue as Jo mentioned. My
apologies, I think we can close this one up.

Comment 7

[gordon]

Okay, great.  Thanks for checking.

I'm going to mark this bug as INVALID.  That seems to be the closest resolution
that makes sense, though an argument could be made for WONTFIX.  Six of one,
half a dozen of the other.