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.
here
I have over 70 freaks, do you?
The markets reacted as expected. I'm breathless.
Healthcare article at Kuro5hin
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!
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
US ISP Adelphia disabled the service September 20-22
No, they did not, at least not nationwide. I was checking it literally everyday. It kept screwing with my DNS requests. Unless they mean those 4 hours I was offline on the 22nd, they did not disable sitefinder on my dns servers.
As of 10/06/03, I hate COBOL developers.
I know the biggest Danish ISP (TDC) blocked it pretty quickly. TDC have >80% of all DSL connections in DK.
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
Why can't you believe that? Verisign is not a NPO, they're a company that exists to make money. Seems pretty straightforward to me.
My sig is blank, I typed this by hand.
2. That Site Finder pages are larger than ordinary error messages and therefore slower and more costly to transmit. "Cannot find server or DNS Error" is not a page that a server sends back since there is no server in the loop. Its clientside generated page.
Have you ever been to a turkish prison?
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.
Verisign can provide this service if they want. But they mustn't try and force me to use it. They could easily offer a browser plug-in that will do the same thing, that people can download and install if they find it usefull. But don't go trying to force everyone to use your service, and break the way the internet functions in the process, without even consulting anyone first.
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.
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
It breaks infrastructure solutions that people have been using for years and work very well. That is reason enough for it to die, all other considerations aside.
What we call folk wisdom is often no more than a kind of expedient stupidity.-Edward Abbey
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.
the problem here is the idea of a shared public asset in ".com" with VeriSign as the maintainer. This is a broken idea from the start. Instead there should be ".vs" for VeriSign and ".gd" for GoDaddy. Then it is clear that these companies wholly own these root domains and they can do anything they want with them.
--Brian
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.
.com register.
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.
Dacels Jewelers can't be trusted.
As far as I know, Alexa doesn't monitor for 'dns lookup failures.' If that's the case then I think this number is way off. About the 22nd or so a lot of people were deploying BIND patches to block this nonsense, and I'm not sure Alexa is registering that. I think their numbers reflect only the ISPs which actually null-routed the sitefinder IP, not ISPs that patched their nameservers.
Correct me if I'm wrong, though.
you can take the road that takes you to the stars...
This is a company that isn't exactly the most liked in Norway, but I was very pleased with their handling of the problem and the responses.
And it shows that most admins are not willing to tolerate absurd changes like this.
> 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
The study was trying it's best to explain why networks outside the US were blocking.
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)
Fuck Beta. Fuck Dice
I don't work for an ISP but I do have about 1500 staff users, plus another 9-10 thousand K-12 students who use the network too. The day this happened, I added some IP-based blocks to our web proxies to deny all access to sitefinder, then made the deny info throw back something that essentially said "That domain does not exist. Check the spelling and try again". Then I filtered outgoing packets on the mail servers to prevent leakage there.
.com and .net, and my old deny page was no longer necessary.
When the first BIND patch with delegation-only rolled out, that went on our resolvers and the real problem went away. Now the spammers couldn't make up arbitrary crap in
Anyone in the organization who heard about the fuss and tried to play with sitefinder had a window of about 12 hours before the changes took effect. Since then, it's been walled off.
Chances are, the bigger the organization is, the slower they move on changes like this. There's just too much bureaucracy to go through before you can do something like replacing your resolvers with new code.
China blocked the traffic at its backbone
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.
6. To be obscene, material must meet a three-prong test...
I always figured by the time you got to three prongs, you'd gone way past "obscene" and were in hardcore country!
GTRacer
- Belgium? There's no need for such language!
Defending IP by destroying access to it? That makes sense, RIAA/MPAA. Go to the corner until you can play nice!
Copied from here
n dex.html?sl=060104
But there is(was) a solution, perhaps mail servers should check to see if the sender domain for a particular piece of email resolves to the Ip above.If it does, forward the email toVerisign, any of the email addresses on this page should do :
http://www.verisign.com/corporate/about/contact/i
If the email sender domain resolves to the bogus Verisign wildcard entry, then its only fair that the email gets forwarded back to them, as it?s obviously spam and it resolves to their address.
Just in case Verisign turns it back on, be ready.
I mean, what's the point of living...if you don't have a dick?
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.
They are a for profit corporation, but they are also responsible for managing the .com and .net domains and if they want to continue doing so they will have to consider all the implications that making decisions like this will have. I don't think that anyone will argue that there was a blatant disregard for the rest of the internet community. Is that who you want managing the root DNS server for the .com and .net domains?
Anyone notice that while the sitefinder service was up, typos were beginning to get into the browser history since they didn't error out? And the next time you wanted to goto the same site, autocomplete would pick up the typo instead.
*mumble*
I'm just glad that was the worst that happened to me before this "service" got blocked here. I feel for the grandparent.
>While it may be very unfair business practice for Verisign to do this, we didn't see any reason to disable it.
I can give you one reason:
All your mail with mistyped domains has been "rejected" (probably read by a marketing bot) by verisign.
That's gotta be worth at _least_ blacklisting the IP, never mind messing with the DNS servers.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
I'm not arguing that they were wrong, I think it was an obvious misuse of their power. But I'm also not surprised.
.com and .net domains as possible, and push the envelope at every turn. Thankfully they're being met with some resistance.
When you have a company in that position... with the ability to easily use a position for an obvious gain, and with a grey area of what's right and wrong (grey to them, not to us.) I think that it's very likely they will try to get as much out of their investment into the
I'm sure trying this was seen as a measured risk for them, and now it's not paying off, much to their displeasure.
My sig is blank, I typed this by hand.
Adelphia did block the service, meaning the site would not load when bonus addresses were entered into the browser, but when pinging bogus internet addresses, A pong came back from the numerical IP of the sitefinder. When going to sitefinder.verisign.com, it was not blocked.
The Television Wiki
... no-one knows you're a lamb.
I pay Verisign to register a .com domain. Sitefinder comes along and points people trying to find my domain to a variety of businesses, some of which are my competitors. I don't have access to their rankings, so I can't redirect people unless I buy the potential misspelled sites from Verisign; otherwise, they have effectively built a bypass around my domain (which I paid them for). Verisign took money from domain holders and then devalued what it sold for its own benefit. As a bonus, the means it used to devalue their property it also didn't own - the unregistered domain names are community property. Essentially, it charged domain holders for advertising, then put up signs on public property advertising competitors.
Had Verisign wanted to help users, it could have done so in other ways, some of which would not have broken a working RFC standard or the servers of lots of people. In addition, as stated in previous threads, the searcher is not even as good as Microsoft's similar feature; thus Verisign's "help" is worse than that most users were already receiving. That seems to indicate that help for users was not a priority for SiteFinder - rather the opportunity for free advertising (and the lack of tangible worth of the trust they violated) led Verisign to conclude that this was a good idea.
Instead of an unknown host error, you get a 302 + text/html redirect that leads to a 200 + text/html page.
.net). Either way, the errors were not at all intuitive.
This plays havoc with Web Services, that expect 200+text/xml on a successful response. The SOAP Stacks either died on the 302 error code (Apache Axis), or the HTML body (MS
Like I said, we're a really small ISP, but it appears we caught 281 typo's (excluding anything that was referred from Slashdot).
It's pretty amazing to look at the common sites that folks typo.
"To be obscene, material must meet a three-prong test... "
Who approaches the Bridge of Death
Must answer me
These questions three!
Ere the other side he see.
Please join VeriSign for a one-hour, informative Web seminar -- "Internet Security Intelligence Briefing--Evolving Trends in Internet Usage" on Tuesday, October 14, 2003, 11 AM PT, 1 PM CT, 2 PM ET.
I couldn't stop laughing for ages!