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)
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.
Comment 2•20 years ago
|
||
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...
Comment 4•20 years ago
|
||
(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?
Comment 5•20 years ago
|
||
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.
Comment 6•20 years ago
|
||
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.
Comment 7•20 years ago
|
||
(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
Comment 10•19 years ago
|
||
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/
| Reporter | ||
Comment 11•19 years ago
|
||
Looks like beeing fixed at least for Win 98 SE
Updated•19 years ago
|
Assignee: darin → nobody
QA Contact: benc → networking
Comment 12•16 years ago
|
||
=> WFM per comment 11
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Comment 13•16 years ago
|
||
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 → ---
Updated•9 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 9 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•