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: foo.search1 foo.search2 foo www.foo.com www.foo.com.search1 www.foo.com.search2 the last two and garunteed never to hit tested on linux. obviously, don't actually use 'foo', as i'm sure that one is registered.

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.

keyword bug

Sounds like the original issue is no longer posing a problem.

Really resolving.

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. 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.

> 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. To elaborate: 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: BenjaminChuang.search1 response: NXDOMAIN query: BenjaminChuang.search2 response: NXDOMAIN query: BenjaminChuang response: NXDOMAIN query: www.BenjaminChuang.com query: www.BenjaminChuang.com (likely a droped packet) response: NXDOMAIN query: www.BenjaminChuang.com.search1 response: NXDOMAIN query: www.BenjaminChuang.com.search2 response: NXDOMAIN 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)

nsbeta1- per Nav triage team, ->1.2

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: http://mymachine/mydir/mydocument.html is expanded to http://www.mymachine.com/mydir/mydocument.html 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 Location bar It is obviously not a location bar only problem, clicking a link like in the example above exhibits the same behaviour.

jlms@yahoo.com: 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 querry system.

> If I enter "test" in Mozilla and Keywords are disabled, I end up on > www.test.com. Stupid question: How can I disable that? user_pref("browser.fixup.alternate.enabled", false);

nominating again...

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.

-> gordon

-> 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-

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 resolved... 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: <http://ftp.mozilla.org/pub/mozilla.org/mozilla/yum/SeaMonkey/releases/1.5/redhat/9/i386/>

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.