Closed Bug 148707 Opened 21 years ago Closed 7 years ago

Proxy: non-DNS name resolution sightings


(Core :: Networking, defect)

Not set





(Reporter: resuna, Unassigned)


At least that's what it looks like. I have it set to use my squid proxy for
everything, and it sits there 20-30 seconds with the "Resolving" message before it seems to suddenly decide to use the proxy
and things start moving quickly again.

I am behind an application-proxy-only firewall. There are no real internet
servers visible and all DNS servers configured in resolv.conf return an
immediate fail to requests. It's like Mozilla has its own DNS library and is
ignoring all my local setup,
wfm 2002060123

Mozilla sends this to the proxy: (

> GET HTTP/1.1
> Host:
> User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.0.0+) Gecko/20020602
> Accept:
> Accept-Language: en-us, en;q=0.50
> Accept-Encoding: gzip, deflate, compress;q=0.9
> Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> Keep-Alive: 300
> Proxy-Connection: keep-alive
.. and mozilla doesn't try to resolve

and btw:
> It's like Mozilla has its own DNS library and is ignoring all my local setup,
if you change anything in /etc/hosts & co. you'll have to restart mozilla :/
No, really, it's doing its own name resolution, somewhere.

More information:

1. I'm behind a proxy-only firewall.
2. I have my own DNS servers that return "no such domain" immediately when
presented with anything but "my local domain". This has been confirmed multiple
times with nslookup and dig. They don't forward and they have had all references
to the root servers surgically removed (under anesthetic, I'm quite humane).
3. I have restarted mozilla several times during this process, and in any case I
have made no changes to resolv.conf, my nameservers, hosts, &c &c &c &c...

Yes, Mozilla does eventually send the right thing to the proxy.

However, I've been experimenting further. My initial proxy settings were cloned
from the ones Netscape had been using: host name "firewall" port "1984" for
everything (well, everything but socks, of course, socks is empty), and a set of
exceptions for IP addresses the firewall doesn't know how to get to because
they're inside a deeper firewall that doesn't fully trust the outer firewall.

Now before you go all "aha" at me again, I'll add that I haven't tried to get to
any of those addresses with Mozilla.

So, I took out those IP addresses, on the assumption that maybe it's doing a
gethostbyname(target) to check it against those addresses. Nope. So, now I'm
sitting here scratching my head, checking that maybe my ponytail is tied too
tight, the usual stuff a BOFH does when things are getting weird. Anyway...

Time for the big guns. Time for tcpdump.

I've got a lot of random extraneous traffic on my local net, so I go and get the
kids computers down and all videogames suspended (and there was much wailing and
gnashing of teeth), and fire up tcpdump. And...

When I enter a name in Mozilla I get netbios traffic. Now I'm not enough of a
Windows geek to know what this traffic actually is, and I didn't pull out the
necronomicon to see... but it's a broadcast on port 138 to my local subnet with
the source name equal to my local computer name (truncated to the first word and
in UPPERCASE), and I know damn well I shouldn't be getting netbios traffic from
a FreeBSD 4.5 box. So I go check my proxy settings again and change "firewall"
to "firewall.domain.from.resolv.conf"... that is, I put in the fully resolved

Now I enter "", and it gives me a brief "resolving" and looks up my firewall, then sends the proxy request.

Now, this is downright weird.

I don't have the mozilla source locally to look at (I downloaded the FreeBSD
binary from your website, and then built the necessary gnome-infested libraries
from the FreeBSD ports tree), but it sure seems like Mozilla is going "whoa,
dude, that's an unqualified name. Before I go and waste time on trying to find
its name on your undoubtedly Bill-Gates-infected network, I'll do a quick check
for a WINS server and take care of you...", instead of saying "whoa, dude,
that's an unqualified name. What's resolv.conf want me to do with unqualified
names? OK, I'll do that, hey, that works, cool..."

I could be imagining things, but that's sure what it looks like. I
double-checked in case I'd installed Samba some time and had forgotten about it,
but no, that's not it. I am... well... staggered. I can see why this kind of
thing might get into the code base, but I sure as heck didn't expect this behaviour.

So, the workaround: use a FQDN in the proxy settings.

Well, that seems to be working, anyway.

The fix: now, if it was up to me, I'd rip out any funky traditional-netscape
name resolution code and just use the local operating system's "gethostbyname".
OK, OK, I know that some systems (Solaris, for example) have some pretty ugly
code in there, but at least give me a prefs option to say "no, I am using the
holy anointed gethostbyname from the pure source of all good bits, BSD and BIND,
and by all that's holy, by the name of McKusick and the name of Vixie I enjoin

OK? Is this thing on?

Summary: Mozilla attempts to resolve name before passing to proxy → Mozilla attempts to resolve SOMETHING before passing to proxy
So much text :)

> So, the workaround: use a FQDN in the proxy settings.

Ok.. now i can see the problem (2002060123 linux ppc):

- Entering 'localhost' and 'ibook' as proxy doesnt work -> mozilla just sends

- But '' or 'ibook.lunix' does work..

(OS -> ALL?? Is this a unix-only bug? Has win32 also this problem?)

-> NEW
..and i am confused that i couldn't find a dup for this..
Ever confirmed: true
ok, so mozilla simply calls 'gethostbyname' on unix systems.  it calls
'gethostbyname' to lookup the proxy servers address.  if that is what is taking
so long then i'm not sure what can be done about it.  does ping have similar
problems with non-FQDN's?
Of course I can't completely rule out a bug in my DNS setup. But...

If there's a problem with my DNS setup it's sufficiently obscure that it hasn't
erupted in the past few years. I have two local DNS servers running Bind 8, each
set up without the root name cache (so unknown domains return failure
immediately), resolv.conf looks like this:


Everything else on my system resolves the firewall's name perfectly well,
including Netscape 4.

You absolutely sure Mozilla's just calling the normal gethostbyname() for the
proxy? I tried looking through the source online but glimpse isn't really the
best tool for tracing lots of method calls and message passing to helper apps
and things...
netwerk/dns/src/nsDnsService.cpp calls PR_GetIPNodeByName which calls
gethostbyname_r under linux.  you'd have to check the source code for
PR_GetIPNodeByName to see what it resolves to under FreeBSD.
Well, it doesn't look there's any paths that lead to hell or Microsoft there,
but I would imagine that any suspect code would be further back up the tree then
the DNS resolver, but I can't trace the twisty little maze of method calls. I've
spent too much time digging through it already (look at the timestamps) and I'm
no closer to figuring out where the actual proxy name resolution happens.
I can verify this happens on FreeBSD, but I'm not using any proxy configuration
whatsoever.  As such, I haven't been able to use the workaround mentioned above.
Any domain name I type in for a particular session hangs for 30 seconds or so
with the status bar reading "Resolving host [whatever]..."  No other process
that does DNS resolution has ever had this problem.  Once the host name is
looked up, everything works fine, until I travel off to another host or close

A coworker of mine had exactly the same issue, also on FreeBSD.

Here's all of my version info:

/home/kris $ uname -rsv
FreeBSD 4.5-STABLE FreeBSD 4.5-STABLE #0: Wed Apr 24 14:54:33 MST 2002

/home/kris $ mozilla --version
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020607 <developer

/home/kris $ pkg_info | grep -i mozilla
mozilla-1.0,1       The open source, standards compliant web browser
mozilla-embedded-1.0,1 The embeddable component of mozilla communicator
mozilla-headers-1.0,1 Header files for mozilla communicator web-surfboard
-> gordon (DNS)

does anyone build debug?  if so, you can try enabling the following environment
variables to try to see what mozilla is doing.

  setenv NSPR_LOG_MODULES nsHttp:5,nsSocketTransport:5
  setenv NSPR_LOG_FILE /tmp/moz.log

if you upload /tmp/moz.log to this bug report, we might be able to get to the
bottom of this bug.  thx!
Assignee: darin → gordon
Component: Networking: HTTP → Networking
I'll look into this soon.
QA Contact: tever → benc
Summary: Mozilla attempts to resolve SOMETHING before passing to proxy → Proxy: attempts to resolve SOMETHING before request
Same behaviour on Mozilla 1.6 on both windows 95 and windows 98. 

Status bar shows "Resolving host ..." before it sends the request to the proxy
server. (and the corresponding delay. I've taken the DNS server offline and
Mozilla waits a looong time for the name query to timeout).
I had a strange linux experience where the same thing happened, I had crippled
DNS by hacking resolv.conf and rebooting, (so no OS caches either). If I tried
to look up hostnames, there would be a strange, long pause, and then a connection.

This doens't happen on my Mac when I trace, but I've seen the same symptoms.
Summary: Proxy: attempts to resolve SOMETHING before request → Proxy: non-DNS name resolution sightings
I have been experiencing the same thing here on Win2k behind HTTP proxy server.
There's local DNS servers running. I usually open a bunch of tabs when i start
Firefox and it does take a small delay (which actually tends to vary?) before I
get the HTTP Proxy Authentication window. Never seen this in IE where the Proxy
authentication is almost instant. 
I have the same problem using Firefox on WinXP behind MS ISA server - it freezes for the 30secs time period.

I discovered that this problem occurs if:
1) "autodetect proxy settings" is on
2) and netbios is enabled
3) and non existing host is contacted

the tcpdump shows that before the browser sends the request to the proxy server it tries to detect the domains IP. DNS fails immediately but netbios request are sent to the network many times until the resolving after about 30secs expires. Then the proxy is contacted and "page not found" from proxy received.

The solution is to disable netbios on the network device interface or manually enter proxy settings.
Assignee: gordon → nobody
QA Contact: benc → networking
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.