Last Comment Bug 40082 - Domain Guessing: should call resolver explicitly (and not trigger DNS search domains)
: Domain Guessing: should call resolver explicitly (and not trigger DNS search ...
Status: RESOLVED DUPLICATE of bug 693808
: perf
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
P3 normal with 4 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 700470
Blocks: 154816 dns_perf
  Show dependency treegraph
Reported: 2000-05-21 19:34 PDT by Jeremy M. Dolan
Modified: 2014-07-31 15:57 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

test condition & locked mozilla process status (10.13 KB, text/plain)
2003-11-28 05:02 PST, francois-xavier kowalski
no flags Details

Description User image Jeremy M. Dolan 2000-05-21 19:34:12 PDT
URL guessing (assuming www. and .com) is firing off non-rooted DNS queries.
These will never match and waste time, cycles, and bandwidth.
Comment 1 User image Jesse Ruderman 2000-05-21 20:19:22 PDT
what do you do to reporduce this bug? what happens that shouldn't happen?
Comment 2 User image Jeremy M. Dolan 2000-05-21 20:26:29 PDT
Jesse: to reproduce, simple trigger URL guessing. (Location: foo <enter>)

it will fire off A queries for:


the last two and garunteed never to hit
tested on linux. obviously, don't actually use 'foo', as i'm sure that one is
Comment 3 User image Jesse Ruderman 2000-05-21 21:02:36 PDT
do you know where those four bogus requests are coming from?
Comment 4 User image Gagan 2000-05-23 13:29:18 PDT
jud does this go to you or now to rpotts? 
Comment 5 User image Judson Valeski 2000-12-15 14:12:02 PST
over to matt
Comment 6 User image benc 2001-05-23 12:40:59 PDT
mass move, v2.
qa to me.
Comment 7 User image benc 2001-06-12 09:19:58 PDT
I wish we could turn this feature off...
Comment 8 User image Jeremy M. Dolan 2001-06-15 19:20:09 PDT
URL guessing seems to be not working now anyway, so if it's been removed (yay!),
this is a nonissue.
Comment 9 User image benc 2001-06-21 14:22:18 PDT
Jeremey: if this is gone, you can mark it RESOLVED/WFM, and put a feather in
your contributor cap.
Comment 10 User image Jeremy M. Dolan 2001-06-21 14:38:07 PDT
Well, URL guessing seems to not be active at all (note I'm not complaining),
which blocks me checking this. 

Is it disabled on UNIX now, or is this a bug? I type in "fakedomain", for
example, the cursor changes to the watch for a second, it tries to DNS
fakedomain, when a negative responce is recieved, Mozilla returns the cursor to
the pointer and does nothing. No dialog/error page. Linux build 2001062015.
Comment 11 User image benc 2001-09-25 14:00:01 PDT
Check to see if internet keywords is off. If it is on, then the keyword search
logic picks up DNS failures.
Comment 12 User image matt 2001-11-19 13:03:45 PST
keyword bug 
Comment 13 User image Samir Gehani 2001-11-19 13:07:34 PST
Sounds like the original issue is no longer posing a problem.
Comment 14 User image Samir Gehani 2001-11-19 13:07:54 PST
Really resolving.
Comment 15 User image Jeremy M. Dolan 2001-11-19 13:23:51 PST
Linux 2001111613 (096 branch). URL guessing still using search path.
Comment 16 User image Jeremy M. Dolan 2001-11-19 13:25:23 PST
What puzzles me is the first query with www. and .com doesn't have the search
path on it, that comes second. That's not normal resolver behaviour, to my
knowledge, unless Mozilla is doing something exceptionally funky.
Comment 17 User image Samir Gehani 2001-11-19 14:12:50 PST
Is internet keywords turned off?
Comment 18 User image Jeremy M. Dolan 2001-11-19 14:15:52 PST
Yes, it's off, although I don't understand how they relate.
Comment 19 User image Jonas Jørgensen 2002-01-14 15:00:07 PST
Yet another bug that will also be fixed automagically when/if bug 115539 is
fixed - marking dependent on bug 115539.
Comment 20 User image benc 2002-01-22 11:09:10 PST
Unless we have existing documentation that calls this feature 'URL guessing',
I'd like something more descriptive, like "Domain guessing" and "search domains"
in the  subject.

Any opinions.

re # 18.

Internet keywords short-circuits domain guessing. The request gets transformed
into a url called "keyword:<string>", and errors terminate the general get this
URL activity. Domain guessing is the last step if all else fails -AND- Internet
Keywords is off.

re # 16.

The behavior would depend on the resolver (hence the OS). Some resolvers will
run the string (even if it has multiple labels) through the search domain list.
Comment 21 User image Jeremy M. Dolan 2002-01-22 11:18:51 PST
> like "Domain guessing" and "search domains"

the latter already has a meaning, in DNS. use domain guessing.

> Domain guessing is the last step if all else fails -AND- 

A good case for it being unnecessary bloat :).

> The behavior would depend on the resolver (hence the OS).

Yes, figured that bit out later.

However, attempting to resolve first:

"typed in stuff"

then the guessing trying:

"prefix.typed in stuff.suffix"

will always uselessly try the search path with that. Adding a period on to the end:

"prefix.typed in stuff.suffix."

should stop the extra-extra queries and fix this bug.
Comment 22 User image benc 2002-03-04 00:00:44 PST
+nsbeta1 - this probably accounts for some really horrible delays between typing
a string that will fail all forms of hostname resolution.

I have not looked at hte code, but I think the previous description is correct.
To elaborate:

We are sending the post-domain-guessed string "" to the resolver
w/o making it an FQDN (i.e., we should sand "").

Usage of "." terminated DNS queries is contemplated in bug 124565, so marked
this bug as a depends of that.

Since this bug is about the suprious search attempts of the domain-guessed
string  (not about changing the larger string->URL resolution issues, I removed
the depends on 115539).
Comment 23 User image Jaime Rodriguez, Jr. 2002-03-05 13:41:23 PST
What is the real world user impact of this bug for a user or Top Site?
Comment 24 User image benc 2002-03-07 09:06:05 PST
This probably slows down the time from link-click to error dialog significantly.

This is bad DNS client behavior too, because most of the extra queries are
suprious, which means they waste DNS server capacity, as well as eat up memory
on systems that do negative DNS caching. 

In some cases where DNS wildcards are used for a domain, you might end up at the
wrong server as well, which brings up security problems like revealing the URI.

I think we need some sample data with a recent build, because the order of
queries was not consistent with what I expect the resolver to do... 

Jeremy, can you try to reproduce and record this again?
Comment 25 User image Jeremy M. Dolan 2002-03-07 14:28:18 PST
OK, I just typed in "BenjaminChuang" in the location bar. Here's the order:

query: BenjaminChuang.search1
response: NXDOMAIN
query: BenjaminChuang.search2
response: NXDOMAIN
query: BenjaminChuang
response: NXDOMAIN
query: (likely a droped packet)
response: NXDOMAIN
response: NXDOMAIN
response: NXDOMAIN

Then, Mozilla pops up a dialog says: " could not be
found". Which isn't what I typed in.

This is RHL72. Remember, it tries search path first by default because there are
no dots in BenjaminChuang. RTM on ndots I believe, if you don't know that part.
Comment 26 User image Peter Trudelle 2002-03-07 16:46:43 PST
nsbeta1- per Nav triage team, ->1.2
Comment 27 User image Gagan 2002-03-07 18:58:39 PST
No no no. 
This bug is far more serious than being pushed aside for mozilla1.2. Even links
are subject to causing enough security trouble, let alone the query strings that
we forward on. Jaime: To answer your question here is the nasty user scenario--
you publish a document on our intranet site say 'adt' and put in a link to
another document on adt that uses a cgi which tells in the URL the mysterious
machV date. Now when I click on this link (and if for whatever evil network
reason I can't reach 'adt'( I am sent to along with the
whole query string which you intended only for the intranet site. Anyone with
access to logs now has our secretly guarded machV ship date!
Hope I made this clearer-- Pulling this back in for mozilla1.0 and plussing.
Comment 28 User image Gagan 2002-03-07 19:00:14 PST
ccing mr security here too.
Comment 29 User image benc 2002-03-08 11:15:20 PST
#25: okay. the order of the queries makes sense now. Still really bad, good
thing we got the plus...
Comment 30 User image Peter Trudelle 2002-03-13 14:29:12 PST
Reassigning 'several bugs at once' to Steve Morse, to level the load better
across the team.
Comment 31 User image Claudius Gayle 2002-03-13 17:06:31 PST
adt needs info:
What're you asking for here? Gagan, is the behavior you are trying to prevent
just for links, or typing in the URL bar or what?
Comment 32 User image Gagan 2002-03-13 17:12:28 PST
I think I goofed up-- my comments are more applicable for bug 115539 which is
what I confused with one with. Apologies. But this bug can still be an issue for
DNS lookups. though not necessarily an issue for mach v. removing the plus and
contemplating/suggesting a minus (though I'd still leave it for mozilla1.0)
Comment 33 User image Peter Trudelle 2002-03-19 14:34:20 PST
nsbeta1- per Nav triage team, ->1.2
Comment 34 User image jlms 2002-05-28 09:32:26 PDT
This happens as well in Solaris 2.8 [build 2002041818]

if I type mymachine I am redirected to

But that is not the worst, our developpers (god bless them) code all the
Intranet stuff using the short name of the web server, thus something like this:


is expanded to

thus the webmaster at would be able to reconstruct
pretty quickly the full structure of our web server tree... Not good.

I would never ever even attempt to convince auditors in my company to allow
Mozilla in the firm with this "feature"...

This build has enabled a check box that would seem to turn on/off this, but it
is not working. The button is in 

Edit>Preferences>Navigator>Smart Browsing>Automatically complete text typed into
Location bar

It is obviously not a location bar only problem, clicking a link like in the
example above exhibits the same behaviour.
Comment 35 User image benc 2002-06-05 07:25:48 PDT please file a new bug for this problem, it is a regression of a
different bug for this feature.

JMD has filed a very specific bug, and I don't want this to morph b/c it is
difficult enough to explain!
Comment 36 User image Stephen P. Morse 2002-06-27 18:09:03 PDT
reassigning to component owner
Comment 37 User image benc 2002-06-28 08:57:14 PDT
+helpwanted - this needs an owner, cc gordon.
Comment 38 User image TGOS 2002-08-31 01:05:07 PDT
Ah, one of my favorite bugs. When I enter "test" in IE, it tries to open
http://test/, which is what I expected.

In Opera DNS guessing does exist, but it's configurable, e.g., you can choose
what shall be added to front (www by default) and what do end (com by default,
but you can select net, org or enter some customer top domain). Of course you
can disable it in Opera as well.

If I enter "test" in Mozilla and Keywords are disabled, I end up on Stupid question: How can I disable that?

Exactly, I think this behavior should be dropped at once in Mozill and should be
replaced by a new setting in the preferences:

[ ] Enable DNS auto complete
    Append to front: [__www.__]
     Append to back: [__.com__]

Users can customize the text fields. If a DNS request returns no result (and
ONLY then), Mozilla checks if this option is enabled and if it is enabled, it
will append whatever is written into the text fields. I have suggested such an
option, I don't know, half a year ago (no idea what happened to this bug), but
nobody seems to care for it.

Unfortunately the Internet Keyword Search option make the Mozilla DNS system a
big mess, so I think I should file an own bug for redefining the whole DNS
querry system.
Comment 39 User image Jonas Jørgensen 2002-09-01 03:04:54 PDT
> If I enter "test" in Mozilla and Keywords are disabled, I end up on
> Stupid question: How can I disable that?

user_pref("browser.fixup.alternate.enabled", false);
Comment 40 User image benc 2002-09-06 14:28:06 PDT
nominating again...
Comment 41 User image benc 2002-09-21 19:28:59 PDT
Gagan's #27 and Jlms' #34 actually refer to bug 34943 (just to clarify).

gagan, peter:
This is milestoned for mozilla 1.2a, but not assigned to anyone. Can someone
take ownership so this doesn't fall through the cracks? I think all you need to
do is add a period to the end of the string you send to the system resolver.
Comment 42 User image Doug Turner (:dougt) 2002-10-22 17:10:38 PDT
-> gordon
Comment 43 User image benc 2002-12-16 09:30:13 PST
-> URL bar, corrected summary
removed DNS from title because (as gordon has pointed out), this isn't really
DNS/networking. I'll be using "domain guessing" at the front of these bugs from
now on, to make them searchable.

Cleaned dependencies, which were wrong. 

Reset milestone, because it was not clear that trudelle could set a milestone
for gordon, and this has slipped.
Comment 44 User image Samir Gehani 2002-12-27 14:42:14 PST
Nav triage team: nsbeta1-
Comment 45 User image francois-xavier kowalski 2003-11-28 05:02:23 PST
Created attachment 136449 [details]
test condition & locked mozilla process status
Comment 46 User image francois-xavier kowalski 2003-11-28 05:03:24 PST
On Linux, Name resolution is hanged after an off-line toggle with a
DHCP-reassigned resolution scheme.  The process does not exit & must be
TERM-inated or KILL-ed.

The problem affects not only the location bar, but also the whole reolution
within Mozilla: smtp server, imap, ...etc. Even "localhost" can no longer be

Setting the host domain explicitly in the hostname (uname) fixes the issue...
but it makes the machine no longer really use DHCP.

Mozilla version

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016

mozilla-1.5 on RedHat Linux 9, from:

Comment 47 User image benc 2004-01-26 13:00:17 PST
francois-xavier: You need to file that problem as a new bug.
Comment 48 User image benc 2004-05-19 06:46:55 PDT
heh, I think I have an idea on how to fix this...

Use about:config, change "browser.fixup.alternate.suffix" to ".com."

That will force all your resolver queries to be explicit.

I won't have time to test this right away.
Comment 49 User image Frank Yan (:fryn) 2014-07-31 15:57:43 PDT

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

Note You need to log in before you can comment on or make changes to this bug.