URL guessing (assuming www. and .com) is firing off non-rooted DNS queries.
These will never match and waste time, cycles, and bandwidth.
what do you do to reporduce this bug? what happens that shouldn't happen?
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
do you know where those four bogus requests are coming from?
jud does this go to you or now to rpotts?
over to matt
mass move, v2.
qa to me.
I wish we could turn this feature off...
URL guessing seems to be not working now anyway, so if it's been removed (yay!),
this is a nonissue.
Jeremey: if this is gone, you can mark it RESOLVED/WFM, and put a feather in
your contributor cap.
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.
Check to see if internet keywords is off. If it is on, then the keyword search
logic picks up DNS failures.
Sounds like the original issue is no longer posing a problem.
Linux 2001111613 (096 branch). URL guessing still using search path.
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.
Is internet keywords turned off?
Yes, it's off, although I don't understand how they relate.
Yet another bug that will also be fixed automagically when/if bug 115539 is
fixed - marking dependent on bug 115539.
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.
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.
> 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.
+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.
We are sending the post-domain-guessed string "www.string.com" to the resolver
w/o making it an FQDN (i.e., we should sand "www.string.com.").
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).
What is the real world user impact of this bug for a user or Top Site?
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?
OK, I just typed in "BenjaminChuang" in the location bar. Here's the order:
query: www.BenjaminChuang.com (likely a droped packet)
Then, Mozilla pops up a dialog says: "www.BenjaminChuang.com 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.
nsbeta1- per Nav triage team, ->1.2
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'(.mcom.com)) I am sent to www.adt.com along with the
whole query string which you intended only for the intranet site. Anyone with
access to www.adt.com logs now has our secretly guarded machV ship date!
Hope I made this clearer-- Pulling this back in for mozilla1.0 and plussing.
ccing mr security here too.
#25: okay. the order of the queries makes sense now. Still really bad, good
thing we got the plus...
Reassigning 'several bugs at once' to Steve Morse, to level the load better
across the team.
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?
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)
This happens as well in Solaris 2.8 [build 2002041818]
if I type mymachine I am redirected to http://www.mymachine.com
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 http://www.mymachine.com 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
It is obviously not a location bar only problem, clicking a link like in the
example above exhibits the same behaviour.
firstname.lastname@example.org: 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!
reassigning to component owner
+helpwanted - this needs an owner, cc gordon.
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
www.test.com. 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
> If I enter "test" in Mozilla and Keywords are disabled, I end up on
> www.test.com. Stupid question: How can I disable that?
Gagan's #27 and Jlms' #34 actually refer to bug 34943 (just to clarify).
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.
-> 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.
Nav triage team: nsbeta1-
Created attachment 136449 [details]
test condition & locked mozilla process status
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/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
mozilla-1.5 on RedHat Linux 9, from:
francois-xavier: You need to file that problem as a new bug.
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.
*** This bug has been marked as a duplicate of bug 693808 ***