Slashdot Mirror


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.

21 of 449 comments (clear)

  1. The Message by beldraen · · Score: 5, Informative

    3 October 2003

    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 .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.

    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 .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.

    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 .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.

    In addition, our review of the .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.

    Given these conclusions, please consider this a formal demand to return the operation of the .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

    --
    Bel, the mostly sane.. "Of course I can't see anything! I'm standing on the shoulders of idiots." -- Me
  2. Re:The big question is by dissy · · Score: 4, Informative

    > 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.

  3. Re:Ya gotta read the article ... by SheldonYoung · · Score: 4, Informative

    ICANN is saying that if VeriSign can prove Sitefinder doesn't have any negative impacts then it can be reinstated and they'll be glad to help. However, paragraphs 3 and 4 in the linked letter make it clear it would be an extremely unlikely event.

  4. Re:Now we wait and see... by EricTheGreen · · Score: 5, Informative
    IANAL, but this would most likely be the scenario:

    1. ICANN presents a tort complaint to the Federal bench after the deadline, claiming breach of contract, per the language in their letter. They could start with a local one, but there would be immediate issues regarding diversity of jursidiction, so they'd probably best just start with the Feds
    2. They also request an expedited decision on the issue (unlikely) and/or an immediate injunction granting relief of the breach, pending delayed decision.
    3. If the judge is so inclined, requested injunction is granted, with Verisign enjoined to restore the pre 9/15 operational environment "with all due speed".
    4. Verisign hopefully complies, but I'd expect lots of legal wrangling, covering every base from "claim lacks merit on it's face" through "court does not have appropriate jurisdiction", probably an appeal or two, although I think the only level up from Federal would be the Supreme Court. Whether they'd grant the appropriate writ of certiorari to hear the appeal would be questionable, but that's my opinion, not a legal one.
    5. Assuming Verisign's legal tactics fail them, they're under legal requirement to comply. Failure to comply, in the court's view, would be a serious mistake with potentially significant consequences for the Verisign officers. Operational question here would be what constitutes "all due speed" in applying a remedy.

    Stay tuned folks, some interesting viewing coming up regarding this.
  5. Revoke Not Sue by toupsie · · Score: 3, Informative

    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.
    1. Re:Revoke Not Sue by NormalVisual · · Score: 2, Informative

      PIR (Public Interest Registry) operates the .org domain, not Verisign.

      --
      Please stand clear of the doors, por favor mantenganse alejado de las puertas
  6. Re:For what it's worth... by interiot · · Score: 5, Informative
    This has been covered thousands of times before. Quick summary:
    • wacky DNS when using WWW/HTTP: some could argue it's useful
    • wacky DNS when taking into account everything else: several examples of protocols that break.
  7. Re:Nice by Col.+Klink+(retired) · · Score: 3, Informative
    I'd be interested to see what those obligations were.

    Read the entire letter, not just the last sentence:

    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.
    --

    -- Don't Tase me, bro!

  8. If I Recall Correctly... by StringBlade · · Score: 3, Informative

    they did lose the .org management already. It's just .com and .net now.

    --
    ...and that's the way the cookie crumbles.
  9. Re:For what it's worth... by Anonymous Coward · · Score: 1, Informative
    It does? Then how come any domain I make up and email to will bounce instantly?

    b/c verisign has changed its approach and implemented a mail server which bounces mail. also note that you are dependant on them for this behaviour now. currently if they wanted they could change this behaviour, and that's one of the reasons their action has undermined the stability of the net.

  10. Sitefinder rejects mail by Simon · · Score: 2, Informative
    VeriSign are running a (dummy) smtp daemon that just rejects all mail. Things should be bouncing still.

    --
    Simon

    1. Re:Sitefinder rejects mail by Russ+Steffen · · Score: 3, Informative

      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.

  11. Re:For what it's worth... by Trepalium · · Score: 5, Informative
    Yes, it does bounce, and (currently) the body of the message never makes it to verisign. The broken MTA running on sitefinder rejects any and all recipients with a 550 error. However, Verisign can change this at any time, so it's not exactly conforting (but it's still no reason to state things that aren't currently true). One thing you CAN complain about is it increases the amount of traffic to successfully bounce an e-mail. Verisign could also use it to harvest email addresses if they ever wanted to break into the spamming business (wouldn't put it past them).

    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.
  12. Re:Nice by __past__ · · Score: 4, Informative
    You have to remember what allows verisign todo wildcarding, the fact that they still manage the root servers.
    They only operate A and J, leaving 11 others. Although it would cause some hassle if they were to move somewhere else away from Verisign (somewhere outside the US would be a good idea...), it isn't as if the net would immediatly implode if Verisign would try do play dirty.

    And anyway, why did they need root servers for that stunt? They didn't wildcard ".", after all.

  13. But that's just it.. by mindstrm · · Score: 5, Informative

    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.

  14. Re:Verisign Sucks by SteveJohnson · · Score: 2, Informative
    You don't need to wait to transfer your domain. Just yesterday I transfered one from Verisign to PairNIC. It cost $18, went very smoothly, and added a year added to the expiration date. BTW, I'm not affiliated w/ PairNIC in any way. I'm just a satisified customer.

    Everyone should transfer their registrations NOW. It's easy and you are making a stand that might actually be noticed. At least you won't be sending any more dollars to a corrupt company that doesn't give a rip about Internet standards.

  15. Re:Nice by Zocalo · · Score: 2, Informative
    I'd be interested to see what those obligations were.

    Probably should have RTFA then, huh? Both the .COM and .NET contracts were linked from Dr. Twomey's letter. Verisign's lawyers are probably pouring over section "Y" as you read this. ;)

    --
    UNIX? They're not even circumcised! Savages!
  16. Verisign relents by kindbud · · Score: 5, Informative

    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
  17. Re:For what it's worth... by bheerssen · · Score: 5, Informative

    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)
  18. No: sitefinder: no MX records = VRSN gets no mail by Anonymous Coward · · Score: 0, Informative

    Oh, boy. Here come the mis-informed paranoids again.

    Web browsers use A and CNAME records:

    $ host nosuchtypoaddrdom.com
    nosuchtypoaddrdom.com has address 64.94.110.11
    $ nslookup 64.94.110.11
    Server: localhost
    Address: 127.0.0.1

    Name: sitefinder-idn.verisign.com
    Address: 64.94.110.11

    $

    But mail apps only send messages to MX hosts
    $ dig verisign.com mx | grep -v '^;' | grep MX
    verisign.com. 5m44s IN MX 400 verisign.com.mail8.psmtp.com.
    verisign.com. 5m44s IN MX 500 pigeon.verisign.com.
    verisign.com. 5m44s IN MX 500 peacock.verisign.com.
    verisign.com. 5m44s IN MX 100 verisign.com.mail5.psmtp.com.
    verisign.com. 5m44s IN MX 200 verisign.com.mail6.psmtp.com.
    verisign.com. 5m44s IN MX 300 verisign.com.mail7.psmtp.com.
    $ dig nosuchtypoaddrdom.com mx | grep -v '^;' | grep MX
    $

    Mail sent to a mis-typed domain will not be sent to a sitefinder mail server. That's not how their DNS typo hijacking works.

    Sitefinder has caused trouble with email delivery, but not at all what you're claiming.

  19. Re:Revoke Verisign's accredidation by jdunlevy · · Score: 2, Informative
    I, too, had been wondering whether ICANN could do this, and I've finally found the answer in The Washington Post's online article "VeriSign Freezes Search Service" (Friday, October 3, 2003; 2:56 PM EDT):
    Under its contracts with VeriSign ICANN can impose up to $100,000 in fines or strip the company of its authority to operate the registries that handle dot-com and dot-net Internet addresses.
    (italics mine).