Closed Bug 12748 Opened 25 years ago Closed 25 years ago

DNS: IPv4 dotted quad URL's fail b/c we reverse lookup (PTR)

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sidr, Assigned: jud)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(2 files)

A test program using only plain Winsock functions, no NSPR.
1.47 KB, text/plain
Details
proposed patch to remove reverse-lookup of ip addrs
802 bytes, patch
Details | Diff | Splinter Review 
In Mozilla M9, build 1999082412, dotted quad IP addresses do
not work in URLs (eg., http://888.888.888.888)

The URLs http://127.0.0.1/ and http://999.999.999.999,
where the 999s stand for the real IP address of the local
or any machine, do not fetch a page from a local or networked
webserver as expected. http://localhost and
http://anyname.in.a.dns.server do work as expected.

The throbber activates for a moment, but webserver logs show that
nothing has been requested.

Occurs in:

M9 only, possibly on multiple platforms, definitely on Windows NT.

For M8.5, M7, NN4.61, and any other browser I've ever tried,
the URLs http://127.0.0.1/ fetches the same page as http://localhost ,
http://999.999.999.999 fetches the same page as
http://name.in.dns.server where the latter is a DNS name the local machine is known by
and the 999s stand for the "real" IP address of the local machine,
and http://888.888.888.888 fetches something from a webserver at 888.888.888.888.

How to replicate:

1.  Ensure local webserver is answering.
2.  Open a log for that webserver; note last line number.
3.  Type http://127.0.0.1 into the location bar, hit enter.
4.  Reopen/refresh view of log file. Note same last line number.
5.  Type http://localhost into location bar, hit enter.
6.  Reopen/refresh view of log file. Note new last line number, fetches
	.
7.  Type http://999.999.999.999 (subsitute real addr) into the location bar, 		hit enter.
8.  Reopen/refresh view of log file. Note same last line number.
9.  Type http://dns.name.here into location bar, hit enter.
10. Reopen/refresh view of log file. Note new last line number.

Or you can view the logs of any other webserver, instead.
Target Milestone: M10
*** Bug 12871 has been marked as a duplicate of this bug. ***
Assignee: gagan → valeski
jud you wanna take a look at this. I had checked in your patch but for some
reason this doesn't seem to be working.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
try a newer build. works for me on NT.
URL: http://207.200.73.38 or any other dot... → http://207.200.73.38
Status: RESOLVED → REOPENED
Summary: Dotted quad addresses embeded in URLs do not work → some Dotted quad addresses embeded in URLs do not work
http://207.200.73.38
http://207.46.131.13/
http://209.207.224.222/topics/topicapple.gif
all work in 4.x, but don't work in apprunner
however, http://192.9.49.30 which is www.sun.com, does work.
Component: Necko → Localization
Very interesting. Our dns lookups for IP address boil down to the following
code in nsSocketTransport.cpp:

      PRNetAddr *netAddr = (PRNetAddr*)nsAllocator::Alloc(sizeof(PRNetAddr));
      status = PR_StringToNetAddr(mHostName, netAddr);
      if (PR_SUCCESS != status) {
          rv = NS_ERROR_UNKNOWN_HOST; // check this!
      }
      status = PR_GetHostByAddr(netAddr, dbbuf, sizeof(dbbuf), &hostEnt);

PR_GetHostByAddr() is failing some ip addrs, and not others.
The attached test program does a hostname lookup
on the specified hostname, then does a reverse
lookup on the IP address.

Compile the attached test program on Win32 as follows:
    cl gethost.c wsock32.lib

Try the following:
    gethost www.netscape.com    # this works
    gethost www.mozilla.org     # this fails
    gethost www.microsoft.com   # this also fails

So I suspect that our local (Netscape) DNS setup
has some problem.
Resolution: WORKSFORME → ---
Clearing WorksForMe resolution due to reopen.
After some discussion with Wan-Teh, we've resolved this to be a DNS issue. I'm
not an expert on DNS (someone who is I'm sure could clear this up), but what's
happening is that some IP addresses are able to resolve via a reverse lookup,
and some are not. This is most likely attributable to the way the DNS records
are setup (some can be looked up in reverse, and some cannot). What's confusing
about this is that I thought IP addresses didn't need to do a reverse lookup,
but that looks like what's happening. I'm cc'd Dan Mosedale as he can tell us a
little more about how our DNS records are setup wrt the following cases:

www.netscape.com -> 207.200.75.200 : IP lookup works
www.mozilla.org -> 207.200.73.41   : IP lookup doesn't work

Dan, how do these two IP addresses differ in the lookup tables?
*** Bug 13138 has been marked as a duplicate of this bug. ***
Two comments:

1. I hate to say this, but if this is an issue with proper setup of DNS records,
IMHO there is still a bug in Mozilla: if there is any reason to do a reverse
lookup on a dotted quad, it should be an asynch call, NOT a blocking call before
the page is fetched. In other words, the lack of a reverse DNS record for an IP
address given in a URL should not on its own hinder the normal flow of an HTTP
request.

The only reason I can think of for doing a reverse lookup would be to ensure a
DNS match for authentication of the website to help prevent man in the middle
attacks with websites that authenticate the agent. In that case, it should be a
double reverse lookup.  Note that for any HTTP 1.1 DNS-only virtual webserver a
double reverse would be guaranteed not to match.

2. FWIW, at the time I submitted this bug (M9), I can *guarantee* that both the
forward and reverse DNS were working for the IP address of the webserver I
tested against, at 206.51.27.219 (krytyn88.angular.com, apache 1.3.9 on home
lan, link not always up, primary DNS at 206.51.22.1). Sorry, the nightly builds
I have downloaded since have bombed at startup...
cc'ing dmose
Many records in the DNS are misconfigured in such a way that PTR records either
don't exist, or don't map to the same thing as the corresponding A records.  In
part because of this, almost no client applications attempt to reverse-lookup an
IP address before using it.  I'm pretty sure none of the old versions of the
browser do this.  Another reason not to do this is that it makes it hard to test
machines that you've just spun up but haven't yet put in the DNS.

Note that the default semantics of gethostbyaddr() should deal with IP addresses
just fine.  From the Red Hat 6 man page:

       The gethostbyname() function returns a structure  of  type
       hostent  for  the  given host name.  Here name is either a
       host name, or an IPv4 address in standard dot notation, or
       an IPv6 address in colon (and possibly dot) notation. (See
       RFC 1884 for the description of IPv6 addresses.)  If  name
       is  an  IPv4  or  IPv6 address, no lookup is performed and
       gethostbyname() simply copies name into the  h_name  field
       and  its struct in_addr equivalent into the h_addr_list[0]
       field of the returned hostent structure.

Assuming that PR_GetHostByName() has the same semantics, I'm attaching a patch
that I think is the right thing to do.

One other thing: although my proposed patch removes the heuristic which tries to
figure out whether something is a DNS name or IP addr, if you know of any
another code which uses a similar heuristic, you'll probably want to check it
out: Looking for a first character of a digit is insufficient, because it breaks
on valid DNS names such as 3com.com and 412.com.  I suspect that using something
like inet_aton() would be the right thing to do.
As I recall the default symantics of gethostbyname() should suffice as well
(thus this bug threw me for a loop initially). However, it seems someone
(gee, guess who) has changed these symantics on us. The following excerpt is
from the docs in the Microsoft Dev Library wrt gethostbyname() on windows.

    The gethostbyname function cannot resolve IP address strings passed to it.
    Such a request is treated exactly as if an unknown host name were passed.
    Use inet_addr to convert an IP address string the string to an actual IP
    address, then use another function, gethostbyaddr, to obtain the contents of
    the HOSTENT structure.

Following the logic laid out in the above comment, I use gethostbyaddr() to do
the IP addr lookup, which subsequently causes the reverse lookup.

Isn't this nice.

Thanks for confirming that a first char check on the "hostname" isn't valid for
numeric host determiniation.

Anyone have any suggestions from here?
One interesting difference in semantics between PR_GetHostByName() (and the PR
equivalents to inet_XtoY?) and gethostbyname() is this: certain kinds of numeric
shortcuts that generally work in most Unix applications (including Communicator)
don't seem to be supported in Mozilla: http://127.1/ as a shortcut for
http://127.0.0.1, for example.  Another example is that in fact a single
(network-byte-order?) decimal number can be used instead of a dotted-quad to
represent an IP address.  I don't think we particularly care about these things,
though.
It seems like the elegant fix for this would be for the windows-specific
PR_GetHostByName() code to internally implement the unix gethostbyname()
semantics by calling inet_addr (or even better, inet_aton) before calling the
windows-local gethostbyname().
(and then the windows piece of PR_GetHostByName would fill in the hostent
struct itself rather than calling gethostbyaddr).
see bug 13219 for the bug on hostnames that start with a number
Reverse lookup was being caused by a Microsoft implementation of gethostbyaddr()? Hmm, is it possible that http://3486010312 will fetch the same page as http://207.200.75.200 (www.netscape.com)? Yes, it does. Is this behaviour wanted?
sidr: strictly speaking it's probably a violation, because in theory that number
could be a valid top-level domain with an A record.
Assignee: valeski → rpotts
Status: ASSIGNED → NEW
reassigning to potts as he mucking w/ this now.
Assignee: rpotts → valeski
Severity: normal → minor
*** Bug 11204 has been marked as a duplicate of this bug. ***
I don't think this is a minor one. There is now a whole tree of dups on this
bug, some of them are marked blockers or major.
Status: NEW → ASSIGNED
Whiteboard: Jud's wrapping up his fix for this.
Whiteboard: Jud's wrapping up his fix for this. → Estimated time to checkin: 1 day (max)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
fix checked in 9/27/99 2pm PAC time. That should do it.
Status: RESOLVED → REOPENED
I believe this is the wrong fix.  I can think of multiple cases where it will
cause problems:

1) if someone has their nameserver records configured so that a reverse record
returns an inconsistent or non-existent name, all attempts to click on links in
the page in question are likely to fail.  A current example is that
212.41.132.206 (one of the A records for ftp.redhat.com) will stop working.
There are many instances of this sort of lossage on the net.  Why break them
unnecessarily?

2) extra, unexpected slowness where someone is attempting to test in a
disconnected or otherwise pre-production environment

As far as I'm aware, doing gethostbyaddr() is extremely unusual among internet
client applications; non-servers generally just aren't written that way, so
users don't expect this behavior.  Is there a specific rationale behind doing it
here that I'm missing?
Component: Localization → Necko
Target Milestone: M10 → M11
moving this off the m10 radar. I can pull the reverse lookup logic very easily
if/when we decide to do that. I sent an email to andreas for his opinion (I seem
to recall, I could be wrong, that he had some reasoning for doing it).
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen of this bug.
I was verifying 11204, which is marked as a dup of this bug, and I still cannot
connect to the server in an isolated LAN using the IP address.  I can reach the
server with communicatior 4.7, I can ping the server using the IP address as
well as the hostname but I cannot connect to the server through seamonkey either
with the IP address or hostname.  I'm not sure if this bug has not been
completely fixed or 11204 is not a dup.
paw: what build are you using? date?
It's a Win32 build (1999092909) running on Windows 95.
Whiteboard: Estimated time to checkin: 1 day (max)
gethostbyaddr is gone! waiting for tree opening for checkin.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
fixed checked in 10/1/99 6:41am PAC time.
As far as the isolated lan problems goes, it's much better.  What happens now is that  the first time you load a page ( http://
208.12.38.99/aol )  the page is displayed in about 4 1/2 minutes.  All subsequent page loads are normal, 3 or 4 secs.  Not sure what
is going on here.
not sure what the lag is due to. the ip address slamming code is indeed in
there. if it's an IP, we skip *all* lookups and whack the ip into the hostaddr
directly.
Status: RESOLVED → VERIFIED
marking this bug verified with m11 builds. paw, you probably need a new bug on
the lag at start-up
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
QA Reviewed:
added to Necko DNS testing.
Keywords: testcase
Summary: some Dotted quad addresses embeded in URLs do not work → DNS: IPv4 dotted quad URL's fail b/c we reverse lookup (PTR)
Depends on: 11204
*** Bug 14246 has been marked as a duplicate of this bug. ***
*** Bug 13103 has been marked as a duplicate of this bug. ***
*** Bug 11394 has been marked as a duplicate of this bug. ***
*** Bug 10326 has been marked as a duplicate of this bug. ***
Blocks: 13219
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: