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

RESOLVED DUPLICATE of bug 693808

Status

()

Core
Document Navigation
P3
normal
RESOLVED DUPLICATE of bug 693808
17 years ago
3 years ago

People

(Reporter: Jeremy M. Dolan, Unassigned)

Tracking

({perf})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 years ago
what do you do to reporduce this bug? what happens that shouldn't happen?
(Reporter)

Comment 2

17 years ago
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.

Comment 3

17 years ago
do you know where those four bogus requests are coming from?

Comment 4

17 years ago
jud does this go to you or now to rpotts? 
Assignee: gagan → valeski

Updated

17 years ago
Target Milestone: --- → M19

Comment 5

17 years ago
over to matt
Assignee: valeski → matt

Comment 6

16 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 7

16 years ago
I wish we could turn this feature off...
Keywords: mozilla1.0
(Reporter)

Comment 8

16 years ago
URL guessing seems to be not working now anyway, so if it's been removed (yay!),
this is a nonissue.

Comment 9

16 years ago
Jeremey: if this is gone, you can mark it RESOLVED/WFM, and put a feather in
your contributor cap.
(Reporter)

Comment 10

16 years ago
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.

Updated

16 years ago
Target Milestone: --- → mozilla1.0

Comment 11

16 years ago
Check to see if internet keywords is off. If it is on, then the keyword search
logic picks up DNS failures.

Comment 12

16 years ago
keyword bug 
Assignee: matt → sgehani

Comment 13

16 years ago
Sounds like the original issue is no longer posing a problem.
Target Milestone: mozilla1.0 → ---

Comment 14

16 years ago
Really resolving.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 15

16 years ago
Linux 2001111613 (096 branch). URL guessing still using search path.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 16

16 years ago
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

16 years ago
Is internet keywords turned off?
(Reporter)

Comment 18

16 years ago
Yes, it's off, although I don't understand how they relate.

Comment 19

16 years ago
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

Comment 20

16 years ago
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.
(Reporter)

Comment 21

16 years ago
> 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.

Updated

16 years ago
Status: REOPENED → ASSIGNED

Comment 22

15 years ago
+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).
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)

Updated

15 years ago
Depends on: 115539

Comment 23

15 years ago
What is the real world user impact of this bug for a user or Top Site?

Comment 24

15 years ago
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?
(Reporter)

Comment 25

15 years ago
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.

Comment 26

15 years ago
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2

Comment 27

15 years ago
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.
Keywords: nsbeta1- → nsbeta1+
Target Milestone: mozilla1.2 → mozilla1.0

Comment 28

15 years ago
ccing mr security here too.

Comment 29

15 years ago
#25: okay. the order of the queries makes sense now. Still really bad, good
thing we got the plus...

Comment 30

15 years ago
Reassigning 'several bugs at once' to Steve Morse, to level the load better
across the team.
Assignee: sgehani → morse
Status: ASSIGNED → NEW

Comment 31

15 years ago
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]

Comment 32

15 years ago
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

Comment 33

15 years ago
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha

Comment 34

15 years ago
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.

Comment 35

15 years ago
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!
Keywords: perf

Comment 36

15 years ago
reassigning to component owner
Assignee: morse → new-network-bugs

Updated

15 years ago
Blocks: 154816

Comment 37

15 years ago
+helpwanted - this needs an owner, cc gordon.
No longer blocks: 154816
Keywords: helpwanted

Comment 38

15 years ago
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.

Comment 39

15 years ago
> 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);

Comment 40

15 years ago
nominating again...
Keywords: nsbeta1- → nsbeta1

Updated

15 years ago
Blocks: 154816

Comment 41

15 years ago
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

Comment 42

15 years ago
-> gordon
Assignee: new-network-bugs → gordon

Comment 43

15 years ago
-> 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 → ---

Comment 44

15 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1 → 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
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/>

Comment 47

13 years ago
francois-xavier: You need to file that problem as a new bug.
Component: Location Bar → Embedding: Docshell
QA Contact: claudius → benc

Comment 48

13 years ago
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

Updated

13 years ago
Status: NEW → ASSIGNED
Keywords: mozilla1.0, nsbeta1-
Whiteboard: [adtneedinfo]
Target Milestone: mozilla1.8alpha1 → mozilla1.8alpha3
Assignee: benc → nobody
Status: ASSIGNED → NEW
QA Contact: benc → docshell
Blocks: 580093

Updated

5 years ago
Depends on: 700470
Target Milestone: mozilla1.8alpha3 → ---

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 16 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 693808
You need to log in before you can comment on or make changes to this bug.