Closed Bug 283291 Opened 20 years ago Closed 9 years ago

Firefox does NMB Lookup instead of DNS lookup if same domain suffix , intranet usage impossible

Categories

(Core :: Networking, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: m.knaus, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0

Config:

 ----------------.        ----------------.
 Router/DNS      |       |  WIN XP Client |
 192.168.6.1     |-------|  192.168.6.51  |
 fli4l.mylan.prv |       | xyz.mylan.prv  | 
 ----------------´       `----------------´

Access to http - Config- Server on Router:
Firefox tries to resolvfli4l.mylan.prv not
via DNS if domain .mylan.prv of workstation 
and target host are the same, it does a
net bios name lookup instead, this lookup 
fails, because the router has no nmb entry.

This has been figured out via ethereal, IE
does a correct dns lookup, only firefox
does a nmb lookup and fails.
nmb lookup is done by IP net directed broadcast.

If source and target domains differ, firefox
does a correct dns lookup and succeeds in 
accessing foriegn hosts, but fails in intranet.

Regards
Michael




Reproducible: Always

Steps to Reproduce:
1. Configure a Masquerading UNIX Router with DNS, HTTP Server, DHCP, but without
any smb protocol, no samba, no wins entry,...
2. give router and client same domain suffix
3. access router via http://routername.domainsuffix
4. Trace packets e.g. with ethereal and look for DNS lookup, there is none
5. look für nmb lookup and have a look on this broadcasting behaviour

Actual Results:  
Unable to reach page

Expected Results:  
The page, I've requested should be shown in Firefox
nslookup on the xp command line does resolve the target host ip correctly.
Mozilla is using the getbyhostname() from the OS
Assignee: bugs → darin
Component: OS Integration → Networking
Product: Firefox → Core
QA Contact: os-integration → benc
Version: unspecified → Trunk
I can't comment on the validity of the bug as I havn't tried looking at it, but
it would certainly explain some of the performance issues with FF talking to the
proxy server on our domain.

Just a thought...
(In reply to comment #2)
> Mozilla is using the getbyhostname() from the OS

Well... I'm seeing a very similar thing here.  Except in my case, I
independently tested NMB and DNS lookups against my name, using both the
fully-resolved name and just the hostname.  In my case, both "host" and
"host.my.domain" resolve with DNS; using nbtstat, only "host" resolves.  (My
local machine is also on .my.domain, as in the bug report.)

But I wrote a snippet of code to do a gethostbyname() function (based on the
MSDN example), and if I run it, both "host" and "host.my.domain" resolve quite
nicely.  In Firefox, neither one works.  So clearly something else odd is going
on here.

From what I'm seeing, the only combination that makes sense is that it's doing a
gethostbyname() to get the FQDN, and then is doing an SMB lookup on that (which
will fail).  Other applications (PuTTY, TightVNC) will resolve either form just
fine.

The strangest part is that the Firefox failure is only occurring on my laptop,
VPN'ed into work.  On my desktop system at work, it will connect to either one
fine.  Could it have something, perhaps, to do with having multiple network
adapters?

Michael - does this describe your case?
Just discovered something else interesting, in the process of trying to put in a
workaround.  I put "host.my.domain" in my HOSTS file in
\WINDOWS\SYSTEM32\DRIVERS\ETC - and Firefox *still* can't find it.
Okay... *now* I'm really confused.  I can't get there by IP address either
(again, in Firefox only).  This is clearly not a lookup problem.

I've verified that I can get to the same site by either name or IP in both PuTTY
and IE.
(In reply to comment #2)
> Mozilla is using the getbyhostname() from the OS

getaddrinfo, actually...
> The strangest part is that the Firefox failure is only occurring on my laptop,
> VPN'ed into work.  On my desktop system at work, it will connect to either one
> fine.  Could it have something, perhaps, to do with having multiple network
> adapters?
> 
> Michael - does this describe your case?

At the time I've detected the bug, there was only one physical network adapter,
an Firewire adapter but the Standard MS IPv6 tunnel pseudo adapters installed.

I think there must something going wrong in firefox, because no DNS packet is
leaving my notebook. So in an API function called by firefox or inside firefox
itself something like this must go on:
Oh, host is in same domain and OS is Windows, so DO NOT DO a DNS Lookup, do a
NMB lookup instead.

I also had entered the target host in \windows\system32\drivers\etc\host(s) and
firefox does not access this entry, so it bypasses the DNS lookup. I am not
sure, if a tunneled DNS lookup might have bypassed my ethereal sniffing, but I
think, I have examined all packets, that have left my host running firefox,
while the lookup has taken place.

Regards Michael
(In reply to comment #6)
> Okay... *now* I'm really confused.  I can't get there by IP address either
> (again, in Firefox only).  This is clearly not a lookup problem.

There might be a reverse lookup problem, too, so you cannot reach the target
host via IP.

Regards
Michael
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Looks like beeing fixed at least for Win 98 SE
Assignee: darin → nobody
QA Contact: benc → networking
=> WFM per comment 11
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
REOPEN:

There is a feature called something like "use LMHosts for lookup", or something like that. If it is on, then the OS will use netbios first in the lookup order.

http://support.microsoft.com/kb/q172218/

...discusses the topic, but doesn't mention what I'm thinking of. I am away from my office, so I can't check windows right now, but I do know that this happens in windows, because when I worked at netscape, someone had created a PC named "mozilla", and my windows system would always try to connect to it. (There was no mozilla.mcom.com.. but it would try to connect when I tested http://mozilla).
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.