558121 - Firefox redirects valid URL by adding a prefix and a suffix

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[Nigel Roberts]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8

http://gg is a valid URL.

But FF redirects to it to http://www.gg.com

http://gg. however, works. The terminating dot is not required for a TLD zone's A record.

The same behaviour is seen on any other TLD with an A record in the top level zone.

(Some versions of IE get it right!)

Reproducible: Always



Expected Results:  
SHould have looked up the A record for the valid DNS name, and connected to port 80 on the resolved IP address

Comment 1

[Boris Zbarsky [:bzbarsky]]

> But FF redirects to it to http://www.gg.com

I can't reproduce that.  If I type http://gg in my url bar, I end up at http://gg/index.shtml

The behavior you describe could happen if there were a DNS resolution failure for the hostname "gg" and only in that situation.  Is that what happened for you?

Comment 2

[Nigel Roberts]

It's totally reproducible. Here's more info .. with details of the DNS resolution on the desktop.

If there is an appearance of a DNS resolution failure, it can only be internal to FF -- from what I see using DIS the DNS appears resolves just fine, irrespective of which resolver I use.

I have both 127.0.0.1 and 8.8.8.8 listed in my resolv.conf. (Running unbound on the desktop machine).


nigel@tower:~$ dig @localhost +short @127.0.0.1 gg A
87.117.196.80

nigel@tower:~$ dig @8.8.8.8 +short gg A
87.117.196.80

Now using Firefox 

http://87.117.196.80    delivers the correct result

http://gg wrongly redirects to http://www.gg.com

http://gg. works as expected, delivering the correct result.


I then changed the resolv.conf to use different resolvers, this time using the one from our upstream (212.30.8.150 & 212.30.8.250).

I see exactly the same behaviour.

I'm running Firefox 3.5.8 on Ubuntu Desktop 9.10 (Karmic)


Incidentally, http://gg/index.shtml does not go to the right place either. I get :-
-------------------------------------------------------------------
Not Found

The requested URL /index.shtml was not found on this server.
Apache/2 Server at www.gg.com Port 80

-----------------------------------------------------------

SOMETHING in firefox is replacing the correct 'GG' with 'WWW.GG.COM' ..
it's clearly not a resolver doing that.

As an aside, I personallythink that doing this sort of thing to change the behaviour of the DNS is probably a bad thing, for the similar reasons 
to those set out re wildcards at

http://www.icann.org/en/committees/security/sac015.htm

If an A record lookup returns NXDOMAIN, that's what a browser should report, not redirect to the .COM space, by way if 'redefining' the DNS response, IMO

However, when there IS a correct A record response, FF should use it!





Nigel.

Comment 3

[Nigel Roberts]

Interestingly the behaviour MAY differ between

http://gg

and 

http://gg/

Comment 4

[Boris Zbarsky [:bzbarsky]]

> If an A record lookup returns NXDOMAIN, that's what a browser should report,

That's not the common user expectation.  This behavior _is_ user configurable.

So given that I can't reproduce this problem (in either current trunk or in Firefox 3.5), where do we go from here?  Are you willing to build a debug build and step through to see what's going on?  The relevant code that does the www/com thing is right here:  http://hg.mozilla.org/mozilla-central/file/5022d0baf80c/docshell/base/nsDocShell.cpp#l5887

Another option is that I could create a build with extra logging in the DNS code for you to run; then you could attach the log here.  That might tell us more about what's going on.  Let me know if you're willing to do that?

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Boris Zbarsky (:bz) from comment #4)
> > If an A record lookup returns NXDOMAIN, that's what a browser should report,
> 
> That's not the common user expectation.  This behavior _is_ user
> configurable.
> 
> So given that I can't reproduce this problem (in either current trunk or in
> Firefox 3.5), where do we go from here?  Are you willing to build a debug
> build and step through to see what's going on?  The relevant code that does
> the www/com thing is right here: 
> http://hg.mozilla.org/mozilla-central/file/5022d0baf80c/docshell/base/
> nsDocShell.cpp#l5887
> 
> Another option is that I could create a build with extra logging in the DNS
> code for you to run; then you could attach the log here.  That might tell us
> more about what's going on.  Let me know if you're willing to do that?