Study Reveals How ISPs Responded to SiteFinder 172
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.
wonder of wonders (Score:1, Insightful)
list a link to networksolutions.com (a verisign company). we also note that searching for the same word at google does not result in that site being present in at least the first four pages of results.
yeah - thats a real useful search tool verisign has there - thanks so much.
good to see someone doing something (Score:5, Insightful)
Re:AAARRRGGG!!! (Score:4, Insightful)
That is not the point (Score:4, Insightful)
Re:AAARRRGGG!!! (Score:4, Insightful)
For example, if you sent an email and mistyped the address, your MTA would attempt to send that email to verisign's sitefinder servers. That means that verisign had the opportunity to read a large percentage of the misaddressed email on the internet. Do you want to give them that opportunity? Would you let the publishers of a phone book (very often not the phone company) automatically listen to every call that you misdialed?
There may be room for a service like this, but it can't break existing expectations.
shared ".com" is the problem (Score:2, Insightful)
Re:AAARRRGGG!!! (Score:5, Insightful)
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
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.
I see a bit of a problem... (Score:3, Insightful)
Correct me if I'm wrong, though.
Re:Wasted some of my time (Score:3, Insightful)
Let's just hope that VeriSign is prevented from ever breaking DNS like this again.
I second that: you can tell that was guesswork (Score:3, Insightful)
I think the argument that it brings up an English page only is reason enough to implement such a block, an insult added to injury of VeriSign abusing it's position.
Bandwidth may have been a factor too, but for a different reason: a negative response is preferable to a positive response because you have the same number of DNS packets either way, but the nasty part is the browser goes ahead and opens subsequently two HTTP connections (one for a location redirect, and one for the sitefinder page) into the US, which could be slower than the DNS error message timeout across a latent or slow link.
The guys in the study were parroting the 404 argument (without saying it explicitly), which is untrue. But they've got the right idea.
I was thinking about how the study could be improved, and I started wondering if there's some other way besides Alexa to get relevant data to analyze. It seemed a little sparse, which they acknowledged. Some ideas:
Perhaps google might be nice enough to provide sample data mined from google toolbar, which I think more people would voluntarily install than Alexa.
Or here's idea: contact owners of websites that are commonly accessed by name (slashdot, cnn, localized googles, weblogs, forums, etc.) and kindly request access_log data filtered by referer coming FROM sitefinder, along with requesting IP.
This way, you get inferential proof of when certain IP addresses hit sitefinder accidentally (and how they mispelled the site name), compatible with all but the most paranoid of webbrowser settings. I wonder if site destination correlates with number of sitefinder redirects vs. total traffic. (For example, slashdot might be quite low due to informed users taking local control of their machines via host files, etc.. while many CNN visitors are at the mercy of their ISP)
China... (Score:2, Insightful)
China blocks everything outside of it unless it feels there is a good reason to let it's people access it. Having a site show up on it's block list doesn't really say much.
Re:good to see someone doing something (Score:3, Insightful)
It's like you stopping me from spray painting your car as "censorship"...
Tom
Re:good to see someone doing something (Score:2, Insightful)
Let's assume that you watch Television. Would you like it if someone hijacked all of the unassigned channels and displayed whatever they wanted on those channels instead of what is normally on them (nothing)? Would you complain to your cable company if they rectified the situation by removing the hijacking and suing the hijacker?
Re:So it comes down to this (Score:3, Insightful)