Slashdot Mirror


Study Reveals How ISPs Responded to SiteFinder

penciling_in writes "During the 2+ weeks for which Site Finder was operational, a number of ISPs took steps to disable the service. A study just released reveals the details and analysis, including specific networks disabling Site Finder during its operational period. For example, the study reports China blocked the traffic at its backbone, and Taiwan's Chunghwa Telecom and Korea's DACOM also disabled the service. US ISPs have been slower to act, but US ISP Adelphia disabled the service September 20-22 before re-enabling it on September 23." That link is a summary; or cut straight to the study itself.

11 of 172 comments (clear)

  1. Intresting preup? story by Sir+Haxalot · · Score: 5, Informative
    --
    I have over 70 freaks, do you?
  2. good to see someone doing something by intermodal · · Score: 5, Insightful

    while I'm not a general fan of censorship, I don't see this as censorship. This was simply sitefinder's overlords abusing their position. Freedom of speech does not mean that you're free to make everyone listen. Same goes for network traffic. This is no different from me adding doubleclick.net in my /etc/hosts pointing to 127.0.0.1 in that I don't want to hear what they have to say, same goes for sitefinder.

    --
    In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
  3. So it comes down to this by The+One+KEA · · Score: 4, Interesting

    Most major ISPs and institutions successfully blocked a "service" which only resulted in widespread disruption in the way the Internet works. It didn't necessarily stay blocked, as in the case of Adelphia, but it was blocked rather quickly. I like the graphs showing SiteFinder traffic; they're very easy to read and they show the drops quite clearly.

    Looking through the study, I found something interesting: most of the blockages of SiteFinder were outside the U.S. Interesting.....

    --
    SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
  4. Denmark by pointwood · · Score: 4, Interesting

    I know the biggest Danish ISP (TDC) blocked it pretty quickly. TDC have >80% of all DSL connections in DK.

  5. More useful by jolyonr · · Score: 4, Funny

    My 404 page redirects people to www.mavisbeacon.com if they mistype a URL.

    --


    Please read my Canon EOS tech blog at http://www.everyothershot.com
  6. Wasted some of my time by Anonymous Coward · · Score: 5, Interesting

    Sitefinder did not seem to redirect images. I was trying to debug an image server I set up and keep getting a 404 when trying to load a test image. After spending about an hour looking at httpd.conf, I realized that I had mistyped the url. The 404s were coming from sitefinder. My server was set up correctly from the very start.

  7. Sad News, Sitefinder dead at 2 weeks by Anonymous Coward · · Score: 5, Funny

    I just heard some sad news on talk radio. The Verisign SiteFinder service was found dead this morning in its 64.94.110.11 IP home. The cause of death was from an ICANN beatdown. Even if you did not admire its work, there is no denying its contributions to the speed and ease of use of the Internet. Truly an Internet icon.

  8. Re:It never "worked" for me... by gregmac · · Score: 4, Informative
    I guess my provider didn't use verisign in the first place?

    No, everyone "uses" verisign. They control the database for the gTLDs .com and .net, so all nameservers everywhere on the internet listen to them. When a nameserver tries to resolve a name, it first goes to the root nameservers (A.ROOT-SERVERS.NET, B.ROOT-SERVERS.NET, etc. There's 13 of them. I believe verisign runs two of those, ISC (people that make BIND) run one, I'm not sure who else does). Verisign basically controls what those servers do. They added a wildcard entry for *.com - anything that's not specifically picked up by a registered domain will be connected to their sitefinder server.

    We are an Educational Institution though, so that could be the reason.

    Likely they just blocked it very quickly.

    --
    Speak before you think
  9. Re:AAARRRGGG!!! by Xerithane · · Score: 4, Insightful

    I don't get the big deal with this. OK, Verisign isn't the best company on the planet (I can think of one Utah based one that's much worse, and don't get me started on Redmond...), but this is insane.

    They, in effect, registered every unregistered domain and pointed it towards their SiteFinder service. If you take into account the cost of registering all those domains, and how many there are (several trillion combinations, I would assume) they just "stole" service from every other .com register.

    That's one argument.

    Another argument is this. And this is real world, and it happened to me. I was setting up a host for a friends wife. She has two domain names, and needed DNS and email. I setup DNS, email, and verify that it works by doing a quick "ping" even though the host was down. So, I ping her domain, expecting it to resolve and have the icmp packets timeout. Well, it resolved, and with a different IP address. So, forgetting about this SiteFinder nonsense, I go back in and try to figure out how in the hell that was happening. It dawned on me 30 minutes later that my resolv.conf wasn't pointing at my DNS server, but my upstream, and the registrar hadn't refreshed. Verisign was reporting that domain belonged to the SiteFinder IP because it didn't clear registration yet.

    People that are not like use geeks here (we know what a 404 means when we see it). I mean the other users.

    You obviously don't know what a 404 means. 404 means that the server exists, but the document isn't found. This is replacing non-existent domains. Two totally different things.

    --
    Dacels Jewelers can't be trusted.
  10. Re:AAARRRGGG!!! by dissy · · Score: 5, Interesting

    > I don't get the big deal with this.

    Well, when people code DNS clients and librarys, they generally do so by following the RFC.

    The RFC states that when a domain does not exist, the name server returns the code NXDOMAIN.

    So, logically, if you get a NXDOMAIN code back, the domain does not exist.
    Verisign changed this RFC defined rule, and every single DNS using application is now broken, as they assume the information in the RFC spec is correct, and it is not so any longer.

    There are many different things that broke because of this, which as an end-user of the internet you probably wont notice much of.
    People that run service on the internet however do need to know how such servers are suppost to act. Verisign changed the rules without so much as telling anyone.

    RFC stands for request for comments. You submit one, and _request comments_
    Only after that phase is the RFC out of draft and so people start concidering to use it. This is how a standard is born via RFC. Verisign did not submit a new RFC requeting a change to the original one.

    It would be like a web server chaning the numerical error codes.
    404 means page not found. 900 is not defined.
    Sending a 900 code when page isnt found would break every existing client.
    This is what verisign did for DNS

  11. Criminal Skills by g051051 · · Score: 5, Interesting

    My company uses SmartFilter. One day, it started blocking access to Site Finder. The reason code it returned indicated that sitefinder.verisign.com had been classified as "Criminal Skills". That sure seems appropriate to me.

    My personal solution was to add it to my junkbuster config, so it would never show, and never register as a hit on their web page.