Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Block VeriSign's attempt at internet domination Internet
Here's an ipfw command to block VeriSign's site finder internet domination plan:
sudo ipfw add deny log all from sitefinder.verisign.com to any in via en0
[robg adds: I'm not sure this is the ideal way to prevent the sitefinder takeover, but it works. If you enter an unclaimed URL, your browser will time out instead of loading VeriSign's page. To remove the rule, use sudo ipfw zero 00100, where 00100 is the rule number that appeared when you entered the rule (you may then have to toggle the firewall on/off to get things back to normal). For more on the Verisign takeover of unused domain names, see the news.com article VeriSign redirects error pages, or visit /. for a couple of additional stories...]
    •    
  • Currently 3.00 / 5
  You rated: 5 / 5 (4 votes cast)
 
[10,822 views]  

Block VeriSign's attempt at internet domination | 17 comments | Create New Account
Click here to return to the 'Block VeriSign's attempt at internet domination' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Block VeriSign's attempt at internet domination
Authored by: Anonymous on Sep 19, '03 11:22:41AM
It's indeed nice to know how to block http://sitefinder.verisign.com on our Macs, but turning it from SiteFinder into a timeout doesn't strike me as an ideal situation. A more comprehensive community discussion as to why, and on further reasons why this matter is near-catastrophic for the 'Net, can be found in association with the corresponding Slashdot story and stories on further developments.

[ Reply to This | # ]
Block VeriSign's attempt at internet domination
Authored by: Anonymous on Sep 19, '03 11:24:11AM

'Ideal situation' should be 'ideal solution.' Ah, were we able to edit comments ...



[ Reply to This | # ]
Block VeriSign's attempt at internet domination
Authored by: viscaria on Dec 03, '03 11:22:12AM

try replacing 'deny' with 'unreach protocol' to avoid waiting for timeout



[ Reply to This | # ]
Block VeriSign's attempt at internet domination
Authored by: oregondean on Sep 19, '03 11:52:50AM

I'm not sure what is worse ... timing out 60 seconds later with an annoying Safari pop-up menu, or just letting the Verisign page load in a second or two.

I'm pretty immune to advertising on the web these days so I tune that out - but Verisign did have the proper web URL (spelled properly) on the page that loaded for me.

Dean



[ Reply to This | # ]
Lower-tech solution
Authored by: Chas. Schoenfeld on Sep 19, '03 11:53:07AM

For those who don't like to mess with the command-line firewall for whatever reason: if you're using Safari, you can also block sitefinder.verisign.com with PithHelmet.



[ Reply to This | # ]
Re: Lower-tech solution
Authored by: sjk on Sep 20, '03 12:26:23AM

Ahh, good suggestion... thanks. Sometimes I forget PithHelmet's there because it works so well. :-)



[ Reply to This | # ]
Use the hosts file
Authored by: tc_nyc on Sep 19, '03 12:12:41PM

Or change your hosts file (in /etc/hosts) to block it by adding this line:

0.0.0.0 sitefinder.verisign.com

Because as we know, in order to add that line to your firewall you have to do it manually every time you start up, or create a StartupItem. Then that firewall entry will interfere with Jaguar's firewall functionality in the Sharing panel.



[ Reply to This | # ]
Use the hosts file
Authored by: Jay on Sep 19, '03 01:55:47PM

This is a better solution, because it happens instantly. There's no need to wait for a browser timeout.



[ Reply to This | # ]
More "Correct" Way
Authored by: iRideSnow on Sep 19, '03 05:30:13PM

Rather than modifying the hosts file, the preferred way to make this kind of change is to use NetInfo Manager (/Applications/Utilities):

1. Start NetInfo Manager.
2. Click the lock button in order to make changes.
3. Go to machines.
4. Duplicate the entry for localhost.
5. Double-Click the 127.0.0.1 value and change to 0.0.0.0 (unless you want to redirect to you local machine, of course).
6. Double-Click the localhost value and change to sitefinder.verisign.com.
7. Save, cmd-S.
8. You may need to restart (or maybe just logout/login) before the changes take effect.

Rob



[ Reply to This | # ]
More "Correct" Way
Authored by: veshman on Sep 24, '03 08:08:06PM

Hmmm...this isn't working for me!

I've tried it both as user and root, and it still doesn't work.

In fact, even the timeout method is not working...
did verisign change their setup?

Bhavesh/veshman
http://www.veshman.com



[ Reply to This | # ]
More "Correct" Way
Authored by: veshman on Sep 24, '03 08:16:37PM

Ok, success! but I had to also block sitefinder-idn.verisign.com

and i deleted the stupid cookie.

bhavesh



[ Reply to This | # ]
More "Correct" Way
Authored by: veshman on Sep 24, '03 08:20:20PM

now it's not working!!!!!

arghhh!!

help, please!



[ Reply to This | # ]
Block VeriSign's attempt at internet domination
Authored by: kerbaugh on Sep 20, '03 01:52:52AM

I agree that a sixty second timeout is intolerable. The problem as I see it is that this hint blocks the wrong site with the wrong rule. The Verisign process is a two step process. When you type an incorrect URL, the Verisign DNS server actually returns an IP address, which is that of sitefinder-idn.verisign.com, not the server listed in this hint. When the browser attempts to contact this server, it sends a redirect to the sitefinder.verisign.com server. This is done so that the Verisign address correctly appears in the browser address bar. This is slightly more polite than a one step process which would result in the incorrect URL appearing in the address bar, although the whole thing violates every account that I've read of the DNS rules.

Blocking the sitefinder-idn.verisign.com server in the manner recommended in this hint would save a fraction of a second but the main problem with this hint is that it suggests blocking the response when a far more efficient method would be to block the outgoing request. The system tells the browser that permission is denied for this request and the browser passes that information along immediately. Thus, the rule I use is:

sudo ipfw add 1170 deny tcp from any to 64.94.110.11 setup

I include a number with the rule because if you already have a well-constructed firewall, you need to make sure this rule precedes the rule allowing outgoing connections.



[ Reply to This | # ]
Umm, no.
Authored by: sebastienb on Sep 22, '03 05:00:06PM
Here's the complete 'transcript' of my trying to get a non-exitant domain:
+++GET 7258+++
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Avant Browser [avantbrowser.com]; .NET CLR 1.1.4322)
Host: adsfasdfkjhdflkjaslfkj.com
Connection: keep-alive

+++RESP 7258+++
HTTP/1.1 302 Found
Date: Mon, 22 Sep 2003 20:55:52 GMT
Server: Apache
Location: http://sitefinder.verisign.com/lpc?url=adsfasdfkjhdflkjaslfkj.com&host=adsfasdfkjhdflkjaslfkj.com
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
+++CLOSE 7258+++

+++GET 7259+++
GET /lpc?url=adsfasdfkjhdflkjaslfkj.com&host=adsfasdfkjhdflkjaslfkj.com HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Avant Browser [avantbrowser.com]; .NET CLR 1.1.4322)
Host: sitefinder.verisign.com
Connection: keep-alive

+++RESP 7259+++
HTTP/1.1 200 OK
Date: Mon, 22 Sep 2003 20:55:52 GMT
Content-Encoding: gzip
Content-Type: text/html;  charset=UTF-8
Transfer-Encoding: Chunked
Connection: Close
+++CLOSE 7259+++

+++GET 7260+++
GET /b/ss/verisignwildcard/1/G.2-Verisign-S/s2266934808526?[AQB]&ndh=1&t=22/8/2003%2016%3A55%3A51%201%20240&pageName=Landing%20Page&ch=landing&server=US%20West&c1=adsfasdfkjhdflkjaslfkj.com&c2=adsfasdfkjhdflkjaslfkj.com%20%2800/00%29&c3=adsfasdfkjhdflkjaslfkj.com%20%28DYM%29&c12=No&c13=00&c14=No&c15=00&c16=Yes&c17=15&c22=NOT%26%2332%3BSET&g=http%3A//sitefinder.verisign.com/lpc%3Furl%3Dadsfasdfkjhdflkjaslfkj.com%26host%3Dadsfasdfkjhdflkjaslfkj.com&s=1024x768&c=24&j=1.3&v=Y&k=Y&bw=1016&bh=581&ct=lan&hp=N&[AQE] HTTP/1.1
Accept: */*
Referer: http://sitefinder.verisign.com/lpc?url=adsfasdfkjhdflkjaslfkj.com&host=adsfasdfkjhdflkjaslfkj.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Avant Browser [avantbrowser.com]; .NET CLR 1.1.4322)
Host: verisignwildcard.112.2o7.net
Cookie: s_vi_fubycywx7Egyx7Ctsqbt=[CS]v4|3F6F606000007A5E-A000A9400000001|3F6F6060[CE]
Connection: keep-alive

+++RESP 7260+++
HTTP/1.1 200 OK
Date: Mon, 22 Sep 2003 20:55:53 GMT
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.10 OpenSSL/0.9.6e
Set-Cookie: s_vi_fubycywx7Egyx7Ctsqbt=[CS]v4|3F6F606000007A5E-A000A9400000001|3F6F6060[CE]; Expires=Sat, 20 Sep 2008 20:55:53 GMT; Domain=.2o7.net; Path=/
Expires: Sun, 21 Sep 2003 20:55:53 GMT
Last-Modified: Tue, 23 Sep 2003 20:55:53 GMT
Cache-Control: no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform, pre-check=0, post-check=0, private
Pragma: no-cache
ETag: 3F6F61D9-78E3-77E919DF
P3P: policyref="/w3c/p3p.xml",CP="NOI DSP LAW NID PSA OUR IND NAV STA COM"
xserver: www136
Content-Length: 43
Connection: close
Content-Type: image/gif
+++CLOSE 7260+++
I don't see that other domain you mentioned. It's also interesting to see the cookies these guys try to set on a browser.

[ Reply to This | # ]
Re: Umm, no.
Authored by: gschueler on Sep 22, '03 09:52:13PM

No, there is no extra redirect, but the reverse DNS lookup on 64.94.110.11 returns "sitefinder-idn.verisign.com"

$ dig -x 64.94.110.11
...
;; ANSWER SECTION:
11.110.94.64.in-addr.arpa. 2m14s IN PTR sitefinder-idn.verisign.com.

which is probably what he meant.



[ Reply to This | # ]
Block VeriSign's attempt at internet domination
Authored by: gsdali on Sep 25, '03 01:39:47PM

This works perfectly, thanks. It restores the functionality of the internet.

Now, any idea of how to block this on my conexant router?

---
--
Ed Lynch-Bell
dali@zerointegrity.co.uk



[ Reply to This | # ]
voice your anger on ICANNs website
Authored by: voldenuit on Oct 03, '03 06:49:21PM
ICANN is to hold a meeting on the 7th of October 2003 where Verisigns incredibly provocative hijacking of .com and .net will be discussed.

http://www.icann.org/announcements/announcement-30sep03.htm

Background information about the issue :

http://www.icann.org/general/wildcard-history.htm

ICANN has set up a website

http://forum.icann.org/wildcard-comments/

where the interested public elaborates on the disgust this standard-breaking hostile takeover of DNS inspires us and how we are not willing to tolerate this.

mailing to

wildcard-comments@icann.org

will get your comments there.

You should keep in mind that anything short from reverting things to as they were before, does not solve the issue and lots of extremely useful functionalities are broken by this commercially inspired hijack of the DNS.

If you want your contribution to count, try to keep it on the point in a way that the slightly bureaucratic people on the committee will be able to relate to your wording.

There are around 135 comments by now with an average of 20 postings per day, so you can really make the difference !

It is probably a Good Thing™ to

  • say why you are an elder statesman of the internet and as such deserve even more credit for the point you make
  • mention how it breaks things for your own professional activity
  • insist that if ICANN is useful at all, that +right now+ is probably a good time to prove it. Stopping sitefinder today, take away registrar accreditation from them tomorrow and set up operations for .com and .net rootservers by some trusted not-for-profit foundation as soon as technically possible is what I feel needs to be done.
  • point out that the internet will only be as useful as it was in the past, when steps are taken to make sure that no private interest of any corporation or nation, USA included, prevent root-DNS-service to be run "by the RFC".
  • Whenever unsure how to handle a situation, the honest answer to the question "How would Jon Postel have handled it ?" will, more probably than not, be the way to go.
It is quite impressing how much better results a clued single human being with an extremely sophisticated net.culture is able to achieve compared to the mess ICANN has stirred up recently.

[ Reply to This | # ]