Question on a safari symptom that implies dns wierdness

Question

This question is posted here because to problem shows up best in Safari. However, as I understand the process, I do not believe the core of the problem is specifically Safari.
When I try to browse to a nonexistant domain (for example, typing in xyzzy.apple.com into Safari's browser), I am shown a Network Solutions page which reads among other things:
This Site Is Under Construction and Coming Soon.
This Domain Is Registered with Network Solutions
It's not as robust as the usual Network Solutions Under construction page.
A screen shot of this can be seen at
http://www.notnap.com/browsing/UnderConstruction.png
I also get this when I type in partial urls. For example, if I simply type in ford to the address bar in Safari, I get the same page. Once upon a time, the browser would assume I meant to add a .com to the end of the url if I did not do so. While showing as a sign of laziness, I must admit I like this "feature."
I NEVER see the standard Safari page saying "Safari can't find the page you are looking for."
Some details:
- Network consists of a DSL connection to Verizon.
DSL modem - Linksys router = iMac G5, iMac G3
Router is connecting to modem via PPPoE
Router is configuring local network (192.168.1.x) via DHCP
- I see the same results from IE5 on the OS9 Imac G3
- I know I did not have these results until recently. Recent changes include:
- upgrading firmware on linksys
- changing internal network range from 192.0.1.x (wsa a typo) to 192.168.1.x
Here is my thinking:
There are two "problems" going on here.
1) I'd like the browser address bar to assume I mean .com when I do not include a standard TLD
2) I'd like to know how Network Solutions is rerouting my browser when my dns resolver falis to find an ip when searching on behalf of my browser.
(1) is admitedly a behavioral preference.
(2) is getting me worried. Doesn't this mean some local process is doing this?
Here's a simplification of the entire process as I understand how dns and web browsing works...
1) In Safari, I enter a bogus url domain, like "xyzzy.apple.com"
2) the Safari process realizes I have not entered an IP number, and goes to the network stack in search of my dns resolver
3) I've entered no custom host information, so the dns resolver on my system must go to whatever dns servers I have configured for use on my ethernet connection. (The only active connection, by the way). There are two dns servers, both in Verizon's space (they are my ISP)
4) My system makes a query on port 53 to their first server. Let's assume they are playing by the rules and not proxying without my knowledge. Let's also assume there is nothing in their dns server cache for xyzzy.apple.com. After all, why should there be? Finally, let's assume their dns servers are recursive.
5) Their dns server checks it's cache and realizes it has nothing for xyzzy.apple.com. It also quickly realizes it has no zone for apple.com, so it goes out on the quest. It hits the root servers, gets directed to the GTLD-SERVERS, gets directed to nserver.apple.com, which finally answers no such host.
6) Verizon's dns server tells my computer's dns resolver no such host
7) My computers dns resolver tells Safari no such host
8) Safari should display the typical site not found page.
As far as I can tell, when I do the search from a purely dns query standpoint, I get the expected results. Here's a clip from the terminal. Comments in italics:
xxxxx:~ xxxxx$ cat /etc/resolv.conf
domain xxx.com
search xxx.com
nameserver 141.154.0.68
nameserver 151.203.0.84
........these are the correct names servers as provided by my isp........
xxxxxx:~ xxxxxx$ dig @141.154.0.68 xyzzy.apple.com +trace
; <<>> DiG 9.2.2 <<>> @141.154.0.68 xyzzy.apple.com +trace
;; global options: printcmd
. 197789 IN NS C.ROOT-SERVERS.NET.
.........skipping a bit.........
. 197789 IN NS B.ROOT-SERVERS.NET.
;; Received 436 bytes from 141.154.0.68#53(141.154.0.68) in 55 ms
com. 172800 IN NS A.GTLD-SERVERS.NET.
.........skipping a bit.........
com. 172800 IN NS M.GTLD-SERVERS.NET.
;; Received 493 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 40 ms
apple.com. 172800 IN NS nserver.apple.com.
apple.com. 172800 IN NS nserver.asia.apple.com.
apple.com. 172800 IN NS nserver.euro.apple.com.
apple.com. 172800 IN NS nserver2.apple.com.
apple.com. 172800 IN NS nserver3.apple.com.
apple.com. 172800 IN NS nserver4.apple.com.
;; Received 274 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 34 ms
apple.com. 86400 IN SOA nserver.apple.com. hostmaster.apple.com. 2006032800 1800 900 2016000 86500
;; Received 88 bytes from 17.254.0.50#53(nserver.apple.com) in 94 ms
In other words, it got what you'd expect - the host does not exist.
So what I want to know is, how is it that Safari is set to shown a Network Solutions page instead of the default Server not Found page? As far as I can tell, that page is not on my system, so Safari must be retrieving it from elsewhere.
But how? When the local process trying to resolve the bogus host xyzzy.apple.com is dig, host, nslookup or the like, I get the correct host not found. How then is that information being changed between my local dig process and the safari process, so that Safari then shows the Network Solutions page? Remember that the only processes which "know" this query was originated by a browser and not by a dns utility like dig are local to my box. So, how can this substitution be done without local access?
Wouldn't this imply a local security problem?
I've tried (although I cannot imagine how some of these would affect a resolution):
- Reset Safari
- emptying cache and history
- manually entering the dns information in system prefs (allowing the system to be configured via dhcp does work - according to network utils, the dns info is there - but they do not show up in the network prefs panel.
- adding ".com" "com" or a few other variations to the default domain in the network prefs.
- Deleting Safari's prefs (~/Library/Safari/)
I did find some discussion about something similar from back around 2002 complaining that similar action could potentially cause host verification problems for email servers and the like. Though, I'd guess most of these kinds of verifications would be for the reverse lookups. Still, I dould not find an exmplanation of how it was done, or more importantly, how to stop it, short of petitioning the ISP's to upgrade their version of BIND.
I'd love to be able to stop this annoying free ad for Network Solutions from appearing whenever I'm wither lazy or sloppy typing in the url. But more importantly, I want to know how this process works. The fact I see similar results on my OS9 ImacG3 strongly implies I'm not looking at a security issue - it's unlikely my conclusion there is a local process intercepting the dns results between my resolver process and my safari process is correct, as the same thing seems to be happening there as well. But I gotta know. How is this happening? How did Network Solutions do this?

Answer 1

What you're describing sounds suspiciously like
VeriSign's SiteFinder from ... the
fall of 2003, which is when it was up and running.
That's one thing I did find from my searches. What I didn't find was an understanding of how they did it then, and by inference how they're doing it now, assuming we're seeing a recurrance.
I find thousands of similar hits by searching on the text in the page, though it's unclear how many of these are legit - some of these pages are truthful. Hitting xyzzy.apple.com and being told "This Domain Is Registered with Network Solutions" is another matter entirely.
This looks like your page doesn't it:
http://underconstruction.networksolutions.com/
You know what would be interesting? The output of
this Terminal command:
curl -I
http://xyzzy.apple.comSee what headers get
returned from whatever server is answering the
call...
I'll do you one better... from terminal:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
notnAP:~ notnap$ curl -Iv http://www.apple.com
* About to connect() to www.apple.com port 80
* Trying 17.112.152.32... * connected
* Connected to www.apple.com (17.112.152.32) port 80
HEAD / HTTP/1.1
User-Agent: curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 OpenSSL/0.9.7i zlib/1.2.3
Host: www.apple.com
Pragma: no-cache
Accept: /
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Age: 7
Age: 7
< Date: Fri, 31 Mar 2006 03:13:09 GMT
Date: Fri, 31 Mar 2006 03:13:09 GMT
< Content-Length: 30692
Content-Length: 30692
< Content-Type: text/html
Content-Type: text/html
< Expires: Fri, 31 Mar 2006 03:18:09 GMT
Expires: Fri, 31 Mar 2006 03:18:09 GMT
< Cache-Control: max-age=300
Cache-Control: max-age=300
< nnCoection: close
nnCoection: close
< Server: Apache/1.3.33 (Darwin) PHP/4.3.10
Server: Apache/1.3.33 (Darwin) PHP/4.3.10
* Connection #0 to host www.apple.com left intact
* Closing connection #0
notnAP:~ notnap$ curl -Iv http://xyzzy.apple.com
* About to connect() to xyzzy.apple.com port 80
* Trying 216.168.224.70... * connected
* Connected to xyzzy.apple.com (216.168.224.70) port 80
HEAD / HTTP/1.1
User-Agent: curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 OpenSSL/0.9.7i zlib/1.2.3
Host: xyzzy.apple.com
Pragma: no-cache
Accept: /
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: Sun-ONE-Web-Server/6.1
Server: Sun-ONE-Web-Server/6.1
< Date: Fri, 31 Mar 2006 02:59:12 GMT
Date: Fri, 31 Mar 2006 02:59:12 GMT
< Content-type: text/html
Content-type: text/html
* Connection #0 to host xyzzy.apple.com left intact
* Closing connection #0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'll save you the trouble:
VeriSign Infrastructure & Operations NSI-NETBLK1 (NET-216-168-224-0-1)
216.168.224.0 - 216.168.255.255
Network Solutions, Inc. NETSOL-SWIP-216-168-224 NET-216-168-224-0-2)
216.168.224.0 - 216.168.224.255
So what does it mean, and can anyone tell me how they're doing this? I hate not understanding how this is being done, and it directly proves my understanding of dns and the network stack on my iMacs is wrong, or at least incomplete. Inconceivable!