Second Advisory Concerning Equitable Allocation of Shared Registration System Resources

(10 August 2001) As previously
reported in an advisory
dated 16 July 2001, many registrars have recently been experiencing
severe difficulty in accessing the .com/.net/.org Shared Registration
System (SRS) during the hours in which expiring names are deleted. The
bandwidth and connection limitations described in that advisory have
not been successful in ensuring that every registrar enjoys equivalent
access. A few registrars continue to consume a large share of SRS resources,
making it difficult or impossible for other registrars to conduct their
normal business.

As described in the below
notice from the registry operator, batch releases of deleted .com, .net
and .org domain names will be temporarily suspended to assure continued
service quality within the SRS. They will be released once a satisfactory
plan is implemented to return them to the pool of available names under
which all registrars receive equivalent access.

ICANN's Domain Name Supporting
Organization has already been advised of the situation and has begun
to discuss possible measures for handling expiring names. Members of
the community are urged to participate in the DNSO's discussions, so
that all viewpoints can be considered in developing measures for fair
allocation of expiring names.

VeriSign Global Registry
Services (VeriSign GRS), after consultation with ICANN, will temporarily
cease batch releases of deleted .com, .net and .org domain names to
assure continued service quality within the Shared Registration System
(SRS). Batch releases are made by the registry five days after deletions
by registrars outside of grace periods.

Why We Are Doing This

This interim action was prompted
by extraordinary loads placed on the SRS arising from several registrars
attempting to register newly released domain names through abusive use
of the SRS. In recent weeks abuse of the system by a few registrars
has escalated to the point where other registrars have been seriously
impacted in their ability to transact normal business activity. The
abuse has been characterized by:

More than 400 million
check commands within a six-hour window to register a few hundred
desirable names each morning

Single registrars executing
as many as 1500 attempts per second

The same registrar sending
a check command for the same name in excess of 1000 times per minute
over extended periods of time

Registrars hoarding connections
(grabbing all connections up to their limit) and, with the exception
of the describe command, executing single-digit numbers of transactions
until they are prepared to execute pre-staged batch jobs that will
invade the system at rates noted in excess of 100,000 per minute

Registrars executing in
excess of 100,000 check commands for each name successfully registered,
compared to a typical ratio of well under 1,000 check commands for
each name successfully registered

Registrars who typically
use less than 10 connections throughout the day, then increase that
connection count to a triple-digit number

Registrars who clearly
execute an automated check process (i.e., checks for the same names
at rates in excess of 1000 per minute)

Registrars whose typical
usage patterns suggest the need for a single-digit number of connections,
and who then increase their connection count by up to 200 times without
a corresponding increase in productive activity (i.e., a registrar
who hoards connections in an apparent attempt to deny others)

Many registrars have reported
that the resulting effects on SRS availability have made it difficult
or impossible to conduct their normal business.

Implementation Details

Beginning immediately, names
targeted for the batch delete process will be held in "registry
hold" status in a special state of "Delete Pending."
These names, after the normal five-day "Delete Pending Period,"
will no longer be subject to recovery by the deleting registrar or registrant.
They will be released once a satisfactory plan is implemented to return
them to the pool of available names under which all registrars receive
equivalent access as required by Verisign GRS's registry agreement with
ICANN. VeriSign GRS will immediately begin working with ICANN and the
registrar community to review possible remedies, devise a satisfactory
plan and implement that plan to better accommodate the competition for
newly-available domain names while at the same time ensuring continued
high service quality for registrars.

It is important to note that
the current number of connections and bandwidth is sufficient to satisfy
all reasonable attempts to conduct normal registration business, both
now and in the foreseeable future. As an example, the registry is easily
capable of sustaining 6x growth in our database transactions over the
typical peak workload rates even without adding additional hardware.
Further, until the most recent increase in demand for connections, the
registry consistently had a pool of available connections that was twice
the size of anticipated demand.

If you require additional
information, please contact Customer Service at
info@verisign-grs.com.

Data Protection

A note about our privacy policies and terms of service:

We have updated our privacy policies and certain website terms of service to provide greater transparency, promote simplification, and align with recent changes in privacy laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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