ICANN Gives VeriSign 36 Hours to Pull Sitefinder
Froomkin writes "ICANN this morning announced that it sent VeriSign an ultimatum: pull sitefinder by tomorrow evening or we'll sue. Details and links to discussion of the contractual and legal issues in ICANN Throws Down the Gauntlet to VeriSign on Sitefinder at ICANNWatch." Update: 10/03 19:29 GMT by M : Verisign blinked.
Go ICANN? Wow, now I am really confused... who are the good guys again?
It's good to know that ICANN has at least a little backbone left. I for one welcome our ICANN overlords
Snowden and Manning are heroes.
My name is ICCANa MOntoya, you killa my DNS, prepare to die!
I think ICANN should basically tell VeriSign, "If you pull this crap again you're through." VeriSign doesn't deserve to be in the position they are in, IMO. This pretty much proves it.
What will happen when VeriSign doesn't do anything tomorrow? Is this just another "scare tactic"?
Just when you make it idiotproof, some idiot builds a better idiot.
Do you ever visit a domain with .com or .net TLD? If so then you use Verisign yourself. You're relying on the root DNS servers that they manage.
3 October 2003
.com and .net Top Level Domains announced by VeriSign on 15 September 2003, and in response to your letter of 21 September 2003. These changes involved the introduction (for the first time in the .com and .net domains) of a so-called "wildcard" mechanism that changes the expected error response for Internet traffic that would otherwise have resulted in a "no domain" response, and redirects that traffic to a VeriSign-operated webpage with links to alternative choices and to a search engine.
.com and .net, until more information could be gathered on the impact of these changes. On 21 September 2003, VeriSign refused to honor that request. In the time since then, ICANN has had further opportunity to consider the technical and practical consequences of these changes, and to evaluate whether these unilateral actions by VeriSign were consistent with its contractual obligations to ICANN.
.com and .net domains. Under these circumstances, the only prudent course of action consistent with ICANN's coordination mission is to insist that VeriSign suspend these changes pending further evaluation and study, including (but certainly not limited to) the public meeting already scheduled by ICANN's Security and Stability Advisory Committee on 7 October in Washington, D.C.
.com and .net registry agreements between ICANN and VeriSign leads us to the conclusion that VeriSign's unilateral and unannounced changes to the operation of the .com and .net Top Level Domains are not consistent with material provisions of both agreements. These inconsistencies include violation of the Code of Conduct and equal access provisions, failure to comply with the obligation to act as a neutral registry service provider, failure to comply with the Registry Registrar Protocol, failure to comply with domain registration provisions, and provision of an unauthorized Registry Service. These inconsistencies with VeriSign's obligations under the .com and .net registry agreements are additional reasons why the changes in question must be suspended pending further evaluation and discussion between ICANN and VeriSign.
.com and .net domains to their state before the 15 September changes, pending further technical, operational and legal evaluation. A failure to comply with this demand will require ICANN
Via E-mail and U.S. Mail
Russell Lewis
Executive Vice President, General Manager
VeriSign Naming and Directory Services
21345 Ridgetop Circle LS2-3-2
Dulles, VA 20166-6503
Re: Deployment of SiteFinder Service
Dear Rusty:
This letter is further to the advisory posted by ICANN on 19 September 2003 regarding the changes to the operation of the
Because of numerous indications that these unannounced changes have had very significant impacts on a wide range of Internet users and applications, ICANN on 19 September 2003 asked VeriSign to voluntarily suspend these changes, and return to the previous behavior of
Based on the information currently available to us, it appears that these changes have had a substantial adverse effect on the core operation of the DNS, on the stability of the Internet, and on the relevant domains, and may have additional adverse effects in the future. These effects appear to be significant, including effects on web browsing, certain email services and applications, sequenced lookup services and a pervasive problem of incompatibility with other established protocols. In addition, the responses of various persons and entities to the changes made by VeriSign may themselves adversely affect the continued effective functioning of the Internet, the DNS and the
In addition, our review of the
Given these conclusions, please consider this a formal demand to return the operation of the
Bel, the mostly sane.. "Of course I can't see anything! I'm standing on the shoulders of idiots." -- Me
I'd be interested to see what those obligations were. If it is as bad as that sounds, I wonder if VeriSign could lose their Registrar priviledges as a result. This could have huge implications, and could help small(er) registrars get a leg up (finally) in the .com and .net domains. I guess only time will tell.
today is spelling optional day.
You have 36 hours to pull sitefinder or we will bring in the Mallard Ducks.
So, basically, if I read this right
ICANN doesn't per se have a problem with the Sitefinder service, but rather, the manner in which VeriSign implemented it?
Ugh.
So basically, they're asking VeriSign to stop until they can take a look at it, give it a green light, and rubber-stamp it
ICANN shouldn't have to sue anyone over a technical aspect of the Internet. They should have the tools to simply tell Verisign to do it and have it done quickly. And they should also have the means to simply cut Verisign out of the loop if push comes to shove (and let Verisign sue if they are unhappy).
Do we hate icann on fridays? :-)
I always thought we we supposed to hate icann, but this story leaves me with such mixed emotions. Can I hate verisign and icann today?
Some one tell me how to feel please.
Wang 33
"Your breath smells like dead bunnies"
PAGERANK++ Robsell.com
I do, because when I signed up it was 'Network Solutions' and back then it was a breeze doing business with that company. Now, though, is a different story. I get spammed by them, I get the run-around if I want to tranfer my domain name, and I now have a horrible customer web interface I *have* to use since calling them on the phone gives me an unintelligent and impatient customer service. I can't risk losing the domain name because of some bureaucratic "limbo" caused by Verisign's inability to do their job. I get to try to transfer my domain to another registrar this december. Let's hope I get lucky and it happens smoothly.
Do I use them? Yes, unfortunately I do at the moment.
What will happen when VeriSign doesn't do anything tomorrow?
SCO will pull their UNIX licenses.
Wow! This is almost like that gunfight between the Earps and the Clantons at the OK Corral.
Pass the popcorn!
!@#$% whole-grain cereal. When I want fiber, I eat some wicker furniture. - G. Carlin
VeriSlime t-shirt "No Values to Trust"
VeriSlime t-shirt "The Abuse of Trust"
SPF support for most open source mail servers can be found at libspf2.
So what exactly is ICANN going to do if they do not comply? The threat of legal action doesn't mean too much, as it can take years to resolve and based on the legal system's understanding of current technology, the outcome is completely up in the air.
Could ICANN actually transfer everything to another company? How long would this take? Is anybody set up to handle this? Think of all the little registrars which exist today, would this be a huge job?
As much as I want them to stop, this response makes a lot of sense, unfortunately: "So the key question now is, 'what will Verisign do?'... My gut reaction is to guess that they're not going to comply. Why should they? They're making mumble-mumble dollars per day on this 'feature,' which is multiples of what it will cost them to fight ICANN's demand, even if it goes to court. Every day that they drag it out is money in the bank... I predict that Verisign will very politely decline ICANN's "request," and state that the issue requires more study before coming to a conclusion. Much like any controversial aspect of ICANN's operation needs 'more study' before moving forward. It's worked in the past; I suspect it'll work now."
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
SCO today acquired Verisign Corporation. SCO CEO Darl McBride said of the acquisition; "We saw a real opportunity for litigation when ICAAN announced they might sue. We feel it would be irresponsible to our investors to pass up such an opportunity and we bought them out."
SCO is presently awaiting ICAAN's law suit at which time it plans to file massive countersuits. Additionally, SCO has begun sending invoices to internet users for the use of thier "Patented DNS system". SCO representatives said the planed to mail the first million invoices on Monday and that the invoices were for ammounts of $699 to $699,000,000.
In other news SCO stock(SCOX) soared on the announcement of the Verisign acquisition.
No, I don't have a solution. Just pointing out that this is just a symptom of a larger problem.
Bush: He's Liberal in all the wrong ways.
> What if Verisign ignores this just like they ignored everything else? They are
> in a position to seariously mess up the DNS system.
ICANN can always instruct the root DNS servers to point elsewhere for com. and net. instead of verisigns gTLD servers. That would effectivly remove verisign from the game totally.
At this point verisign is legally bound to hand over their database of customer info so that the new registrar can pickup where they left off, and verisign would be held accountable for all damages caused if they dont (Which would easily be in the tens of millions a day)
ICANN being the primary board, if anyone at verisign said 'no' they most likely would be held personally accountable.
Its like if the admin of a company gets put on another project and refuses to give his boss the root passwords. He will be personally held responsible. And one way or another, the problem will get fixed.
When you say HTTP/302, you're saying the resource they're looking for exists somewhere else, in this case sitefinder.verisign.com. That is a lie. It is a gigantic, automated lie perpetrated automatically on the entire world. It's a class action suit waiting to happen.
LIARS
It's fraud.
Verisign received trusteeship of the COM and NET TLDs by ICANN, the government and the rest of the Internet standards bodies. They are free to promote the domains but are obligated to act in a neutral fashion and keep the DNS running. They are required to act as a neutral third-party with regard to providing a network service much in the same way it did when DNS was run as a government funded, non-profit organization (InterNIC).
ICANN's pissed and rightly so. The average Internet user has no idea how the net really works with regard to DNS. To them, www.google.com is the Internet. To the techies, we know the names are just thin veneers over the IP addresses that really control and make things happen. Until this affects the average user, only the geeks and techies of the world will care about this.
Verisign has gone and broken THE CORE PROTOCOL of what makes the Internet work! Without DNS, we would have to use and memorize IP addresses. DNS is supposed to work by returned an answer as to whether or not a name is mapped to an IP address and provide that address.
By building SiteFinder, they have waived their right as a neutral third party and are now trying to co-opt the largest domain registries in the world for their own personal profit and use. In doing so, they have also broken the software contract between DNS and its users. They've changed the interface that people expect to work a certain and broken or severely damaged the functionality of software around the world. When mail servers can't figure out if an e-mail is forged or not, it's only going to be a matter of time before the spammers clue in and increase bandwidth usage across the board until things change.
What Verisign fails to acknowledge is that registry is not theirs to do that with. It was paid for by taxpayer dollars and grants over many years from countless communities and can be considered a public utility. There cannot be preferential treatment in this. Or they can claim that the COM/NET TLDs are their intellectual property and they can do with it as they please. They want to do that? Fine, they can push for a new TLD to be added to the hierarchy for private use which they can manage. Turn over COM/NET to a neutral non-profit and let them run it as a public trust.
Verisign should have its right to manage the .com, .net and .org TLDs revoked permanently. No ands, ifs or buts. They have stepped over the line. They have had the opportunity to down sitefinder weeks ago and they thumbed their nose at all of us.
Strange women lying in ponds distributing swords is no basis for a system of government.
Yeah, well a lot of mail software relies on that, and one of the worst things about this is that Verisign is actually receiving a lot of mail that wasn't for them in the first place; they get to read, analyse and keep and it never, ever arrives where it was intended and doesn't bounce either.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"How can the first post be redundant?
My future's determined by Thieves, thugs, and vermin -- The Offspring
Network solutions shouldn't have been allowed to get into any business besides selling domain names and providing DNS. Anything else (like selling ads on their sitefinder) and there is a risk they will do something to DNS to promote their other products rather than improve usability (as they did). They shouldn't even be allowed to send unlimited e-mails to domain name owners.
TLD registrars and DNS providers should be small companies, run by people who are content to do a job and make a small profit, but not have unlimited freedom/growth potential of a private company that doesn't provide any exclusive service to the public.
I hope ICANN moves in that direction right away and not even bother with separate lawsuits for various small points.
Just 2 days after I finally get Cox Communications to install the DNS patch...
Couldn't ICANN have let me stay a hero for just a few more days?
What happens when ICANN fully realizes this power and makes changes to the obligated behavior of TLDs and uses their power to force change that may not be in the best interest of everyone concerned (read: ISPs and end users).
Of all the lawsuits flying around this year, this one is actually valid and should occur with extreme prejudice.
...and that's the way the cookie crumbles.
they did lose the .org management already. It's just .com and .net now.
...and that's the way the cookie crumbles.
To paraphrase a little
...
Dear Rusty,
Blah blah blah
Do it or it your ass!
Best Regards
Paul
It's like watching two Englishmen having a civilized cup of tea while trading insults.
Life is like a web application. Sometime you need cookies just to get by.
220 sitefinder.verisign.com VeriSign mail rejector (Postfix)
HELO dsnjkas
250 OK
MAIL FROM: <sdnjkas@com.com>
250 Ok
RCPT TO: <sdnjkasd@sdnfjkasd.com>
550 <unknown[xxx.xxx.xxx.xxx]>: Client host rejected: The domain you are trying to send mail to does not exist.
I used up all my sick days, so I'm calling in dead.
That's the trouble with protocols... once they're set good luck ever getting rid of them.
The $64,000 question is, can the domain not found response be modified at all without breaking the protocol? For instance, to have older programs recognize the error, but next generation programs (web browsers mainly) be able to return useful information like possible alternatives? This would allow for smarter, more functional programs without breaking legacy apps.
---If you can't trust a nerd, who can you trust?
You are SUPPOSED to be able to count on getting "DOMAIN NOT FOUND" errors.... DNS isn't google.. it's a precise, distributed database, that has served us well so far.
I have been hit by this problem already, where typos went unnoticed in scripts because a connection was made, and html returned.
I've had mail problems as well, where secondary MX was never tried, because of verisign's new trick.
It's handy for when you mistype.. unfortuntaely, looking up web pages is just one of many uses for the DNS.... and not at all what it was intended for.
They already kind of do this, trying different combinations of appending .com, prepending www., and that could be expanded into a wider search. Invalid domains can be turned into search terms.
This is a UI issue, not a protocol issue. It can best solved in the UI, i.e., in the browser. And the browsers, while not always acting in good faith, have done exactly this.
I don't know if it's changed, but when Sitefinder first went up the smtp daemon was bouncing the mail after accepting the entire message. You'd get a bounce but they (could) have a copy of the mail.
You mean like how Mozilla -used to- do a google search for me if the domain didn't exist?
That's something I specifically wanted, and configured Mozilla to do. Google is rather good at guessing what I wanted when I mistype stuff.
And it's a feature that VeriSlime have now broken for me. Sitefinder is almost completely useless at guessing my typos, and the only way to get the old behaviour back is patching DNS to return NXDOMAIN like it used to.
Many ISP's in New Zealand are already running a patched DNS that ignores VeriSlime. My current ISP is one of them, but I still keep seeing sitefinder in places like the ODP editor.
Hell, that brings up another point. The ODP editor interface has various tools for checking that sites still exist, so that editors don't have to go through the tedious task of checking them all periodically. Guess how SiteSquatter affects those tools?
455fe10422ca29c4933f95052b792ab2
The $64,000 question is, can the domain not found response be modified at all without breaking the protocol? For instance, to have older programs recognize the error, but next generation programs (web browsers mainly) be able to return useful information like possible alternatives?
There is NO NEED to ABUSE the DNS PROTOCOL. If you feel an APPLICATION needs to behave a certain way when an NXDOMAIN response is appropriate, rewrite the application to do that.
LOOK:
Browser/options/network (or something):
When server does not exist
[.] Display modal error message
[.] Display non-modal error message
[X] Redirect to:
[.] Domain search site A
[.] Domain search site B
[.] Domain search site C
[X] Custom search:
[ http://www.indiesearchguys.net?host=%h ]
Hey, I added value to one application without BREAKING ANYTHING ELSE! I must be some kind of GENIUS in the field of the OBVIOUS!
- User-agent: *
thus causing archive.org to reject all requests for old sites.Disallow: /
VeriSign Will Temporarily Suspend Web Navigation Service in Order to Continue To Work With Internet Community Towards a Long-Term Implementation
Good for them. Even better for us.
It's a press release from VRSN, so naturally it is full of half-truths and lies, but the bottom line is that they are getting in line. I doubt SiteFinder or wildcards will be resurrected after this debacle.
Edith Keeler Must Die
It's neither. It's a DNS issue. Full stop.
Here, have a loot at the IAB's point of view. They make a powerful case against the use of wildcarding in top level zones. The big thing is that it breaks a whole lot of protocols. HTTP isn't really that big a deal. ISPs could easily handle that in their DNS systems. Currently there are so many public and private protocols being used that nobody, not even Verisign, can properly provide for them using a wildcarding sytem, yet that is what Verisign is actually doing. And they are doing it very badly.
It increases network traffic, incurring more cost to ISPs and consumers. It makes it very difficult to present proper error codes for protocols that Verisign did not anticipate such as IRC. It breaks old protocols for which clients are not being developed but still provide a valuable function. For protocols that are still supported, it incurs higher costs for those users since the developers will need to update their software. There are so many problems with wildcarding that even the IAB gave up listing them after a dozen or so.
(Score: -1, Stupid)