Skip to main content

Third Advisory Concerning Register.com v. Verio Litigation

As previously reported in advisories dated 24 September 2000 and 26 December 2000, on 3 August 2000 Register.com, Inc. filed a lawsuit (No. 00-Civ-5747 (BSJ)) against Verio Inc. in the United States District Court for the Southern District of New York. The lawsuit concerned Verio's use of information obtained from Register.com's Whois service to contact Register.com customers by telephone and otherwise to solicit them to become Verio customers. Among other things, Register.com asserted that Verio's solicitations violated a restrictive legend displayed on the output of Register.com's Whois service.

During the litigation, facts came to light suggesting that Verio is using zone files obtained from VeriSign Global Registry Services to initiate robot-implemented, repetitive queries of Register.com's Whois service. On 21 September 2000, ICANN requested VeriSign to investigate the circumstances under which Verio is obtaining the zone-file data.

On 22 September 2000 ICANN submitted to the Court an amicus curiae memorandum, which stated (in summary):

  • It appears that the process used by Verio to enable it to gather the Whois information is contrary to the zone-file access agreement specified in the Registry Agreement between ICANN and VeriSign;
  • Register.com's legend, if applied in response to Whois queries made through proper means, exceeds the restrictions permitted by section II.F.5 of its Registrar Accreditation Agreement with ICANN; and
  • The exclusive means of legally enforcing these restrictions are through ICANN's invocation of the remedies stated in sections II.N and II.P of the Registrar Accreditation Agreement, not by a third party raising them as a defense to a claim brought by a registrar.

On 8 December 2000, the Court issued an Order enjoining Verio from, among other things, using automated methods to access Register.com's Whois service, other than in compliance with Register.com's restrictive legend. The Court's decision rejected Verio's defense that the restrictive legend violated section II.F.5 of Register.com's Registrar Accreditation Agreement with ICANN, suggesting that Verio should present any complaints about Register.com's compliance with that Agreement to ICANN. After the Court's decision, on 21 December 2000, Verio submitted to ICANN a "Petition for Termination of Registrar Accreditation Agreement with Register.com." To assist it in determining how to proceed, ICANN has requested that Register.com submit a response to that petition.

Two documents, which can be viewed at the links below, have recently been submitted to ICANN in this matter:

1. On 26 January 2001, Register.com submitted its response to Verio's petition to terminate Register.com's accreditation. Among other things, the response states that "in light of its past discussions with ICANN" on the topic, Register.com has re-evaluated its position and "has recently licensed its bulk WHOIS data to one licensee . . . , and has made its bulk WHOIS data available to seven other potential licensees on identical terms."

2. On 30 January 2001, VeriSign Global Registry Services submitted the report on its investigation. The report finds that Verio is continuing to download zone files from the registry, and that it appears these files have been used to initiate mining of the registry's Whois database and those of registrars. VeriSign's report recommends various "corrective actions" and states that "Verio has been notified by the Registry that any further use of the Registry's TLD Zone files or high volume, automated electronic queries against the Registry's WHOIS database will be considered a violation of Verio's current bulk access Agreements between the parties and will result in termination of those Agreements."

ICANN expects to invite Verio to submit a response to these two documents.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."