Closed Bug 40082 Opened 21 years ago Closed 6 years ago

Domain Guessing: should call resolver explicitly (and not trigger DNS search domains)


(Core :: DOM: Navigation, defect, P3)






(Reporter: jmd, Unassigned)



(Keywords: perf)


(1 file)

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? 
Assignee: gagan → valeski
Target Milestone: --- → M19
over to matt
Assignee: valeski → matt
mass move, v2.
qa to me.
QA Contact: tever → benc
I wish we could turn this feature off...
Keywords: mozilla1.0
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.
Target Milestone: --- → mozilla1.0
Check to see if internet keywords is off. If it is on, then the keyword search
logic picks up DNS failures.
keyword bug 
Assignee: matt → sgehani
Sounds like the original issue is no longer posing a problem.
Target Milestone: mozilla1.0 → ---
Really resolving.
Closed: 19 years ago
Resolution: --- → WORKSFORME
Linux 2001111613 (096 branch). URL guessing still using search path.
Resolution: WORKSFORME → ---
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.
Depends on: 115539
Summary: URL guessing shouldnt use search path → URL guessing shouldn't use search path
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 "" 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).
Depends on: 124565
No longer depends on: 115539
Keywords: nsbeta1
Summary: URL guessing shouldn't use search path → DNS: domain-guessing should be explicit (and not trigger DNS search domains)
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: (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.
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.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'( 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.
Keywords: nsbeta1-nsbeta1+
Target Milestone: mozilla1.2 → mozilla1.0
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.
Assignee: sgehani → morse
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?
Whiteboard: [adtneedinfo]
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)
Keywords: nsbeta1+nsbeta1
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha
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. 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!
Keywords: perf
reassigning to component owner
Assignee: morse → new-network-bugs
Blocks: 154816
+helpwanted - this needs an owner, cc gordon.
No longer blocks: 154816
Keywords: helpwanted
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.
> 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);
nominating again...
Keywords: nsbeta1-nsbeta1
Blocks: 154816
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.
OS: Linux → All
Hardware: PC → All
-> gordon
Assignee: new-network-bugs → 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.
Assignee: gordon → hewitt
Component: Networking → URL Bar
No longer depends on: 115539, 124565
QA Contact: benc → claudius
Summary: DNS: domain-guessing should be explicit (and not trigger DNS search domains) → Domain Guessing: should call resolver explicitly (and not trigger DNS search domains)
Target Milestone: mozilla1.2alpha → ---
Nav triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
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:

francois-xavier: You need to file that problem as a new bug.
Component: Location Bar → Embedding: Docshell
QA Contact: claudius → benc
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.
Assignee: hewitt → benc
Keywords: helpwanted
Target Milestone: --- → mozilla1.8alpha
Keywords: mozilla1.0, nsbeta1-
Whiteboard: [adtneedinfo]
Target Milestone: mozilla1.8alpha1 → mozilla1.8alpha3
Assignee: benc → nobody
QA Contact: benc → docshell
Depends on: 700470
Target Milestone: mozilla1.8alpha3 → ---
Closed: 19 years ago6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 693808
You need to log in before you can comment on or make changes to this bug.