ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

[registrars] Delete Issue Update #1




Problem Statement

The procedure implemented by the VeriSign Registry to batch delete
domains is being gamed by a few registrars that have created a market
for domain names due to be deleted. I the registrars attempt to
re-register these deleted domains they have been consuming more than
normal system resources at the registry thus preventing other
registrar from performing normal business during the "landrush" for
the deleted domains.

The registry has implemented a short term policy of not deleting
domains until a new procedure has been developed to allievate the
contention for connections and lower the load of check requests to a
normal level. Until this situation is resolved all deleted domains
will be on "Delete Pending."


Below are several proposals from registrars, one from the GA, and one
from an ICANN Board member, on how to resolve the problem. I encourage
everyone to review these and post their thoughts or additional
proposals to the registrars list. I'll maintain a list of the ideas
and any other information I can gather from the registry.

We should be working on evaluation these proposals next week and have
chosen a single one for recommendation by the 29th of August.

Some guidelines for evaluating proposals:

   o The proposal MUST be fair to all ICANN Accredited Registrars
   o The proposal SHOULD work within the current RRP 1.1.0 protocol.
   o the proposal SHOULD NOT encourage the use of the CHECK DOMAIN
     command to find out available names in the pool of names to
     be deleted.
   o The proposal SHOULD NOT give a greater benefit to a registrar
     that uses more RRP Connections over a registrar with a single
     RRP Connection.

I'm sure that there are more requirements, the above were just off the
top of my head.

Since my last post on this topic the VeriSign registry has released
the list of domains to be deleted. The files are available under
password protection at ftp://ftp.verisign-grs.com/pub/

I counted over unique 64,000 names to be deleted, queued over the
first 4 days. I have not yet performed any analysis to determine the
registrars that the names belong to.


-rick

Karl Auerbach <karl@cavebear.com>

   Create an announcement mechanism in which notices of expiring
   domains are sent to interested parties.  These notices would be
   sent out some period in advance of expiration and would contain
   the name that will be expired and the date/time-of-day of the
   forthcoming expiration.

   Then there would simply be a rush at the tick of the clock to
   register the name.  (There may be methods of managing the rush, but
   here I'm mainly concerned with the means of announcing the
   expiration.)

   I figure that amortized over a year the average bit rate for this
   for a 30,000,000 TLD like .com would be about 800 bits/second
   before compression.

   Two methods strike me as appropriate - IP multicast and netnews.

   IP multicast is easy, cheap (potentially free), and effective.
   IP-over-IP tunnels allow it to be extended across non-multicast
   enabled ISP's and through firewalls.

   In addition, IP multicast allows any person, not just registrars to
   listen into the announcements - which is an important aspect of
   fairness.

   Netnews is kind of a fallback, but it's easy.  It has the drawback
   that the traffic would have a higher degree of overhead than IP
   multicast.

Larry Erlich <erlich@domainregistry.com>

   As has been mentioned, why not an auction where Registrars take
   bids for desirable names from customers?

   1) The REGISTRY gets a fee per name for developing and implementing
   the systems to allow registrars to submit bids on behalf of
   customers.

   2) The REGISTRARS get a fee for accepting the bids from potential
   customers.

   3) The registrar who is RELEASING (has deleted or about to delete)
   the name gets a % of the name sale to insure that it is in their
   best interest to release the name, and not sell it or retain it
   themselves.  This would take care of names that are within the 5
   and 45 day windows that don't even go on registry hold (by
   providing an incentive to the registrars of those names to have
   them handled in the same way). It would also take care of
   registrars monitoring expiration dates of those names trying to
   grab them by engineering abusive systems.

   3a) The other % gets split among ICANN and other ICANN accredited
   registrars according to some formula that would have to be
   developed.

   4) Bids can be submitted for any name, even if it is not
   expired. That way customers don't have to constantly monitor the
   process. The bids will remain private, only being known by the
   registrar who collects the bid and the registry.  We get many cases
   of people who would like names that haven't even expired yet, and
   I'm sure they would pay a nominal fee to be able to bid for the
   name if it ever was available.

   IANAL, but with the auction approach (unlike the "application"
   process) it's legal since the winner is not picked randomly.

   And, it is fair for consumers, since one small fee, paid to the
   registrar of your choice, covers your bid for a given name.  With
   applications, you have to submit multiple applications with no
   guarantee even if you submit the most applications, only a better
   chance.  And you lose all the application money.  (And as we know
   the legality of that system is currently being questioned.)


   One final thought. People wanting to register expired names will
   complain about the fact that they have to bid on expiring
   names. But let's face it. They don't stand a chance of getting the
   desirable names right now, unless they buy them from the person who
   knows how to work the current system.


A proposal from the GA by Russ Smith

  The solution is rather straighforward.  You isolate the "grabbing"
  system from the rest of registry system so normal business is not
  affected.  Then you implement a landrush system similar to what is
  being used for some of the new TLD's.  Of course it would have been
  much cheaper to implement this at the start of the shared registry
  system.  To go back and try to fix it now will be much more
  expensive.

  Among most of the average domain buyers I believe a "consensus"
  existed years ago that the system should be corrected.  However, the
  people at Verisign are only concerned with the "consensus" of their
  shareholders.  Since there was no profit motive for doing this it
  never was done.

Kevin C. Ranck <kcr@addresscreation.com>

   One possible implementation:

   On Sunday, Verisign GRS would randomize the pool of expired names
   from the previous week and distribute a list to each accredited
   registrar (number of names registrar would receive = pool
   total/accredited registrars).

   The registrar has until the following Saturday to claim (and pay
   for) those domains they want.  All unclaimed names go into a 'Once
   rejected' pool.  Those names are then returned to the pool to be
   redistributed on Sunday.  Once a name is rejected two times it is
   deemed not be valuable and is simply released according to the drop
   procedures that are in place now.


Chris Moore [mailto:seymour@itsyourdomain.com]

   1. Offer a 'grab bag' (for lack a better term) for the expiring
   domains.  The registry should publish the list of domains to be
   released. Then the registrars should put in requests based upon
   their client's desires. The names should then be randomly handed
   out amongst the registrars who put in requests.

   2. Maintain the ability to have all registrars hitting the registry
   full-force with the maximum number of connections simultaneously.

   3. Offer an isolated rrp server that only offers registration of
   expired domains (which stay taken in the regular registry until an
   hour or so after drop time).



Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au>

   There is a relatively simple solution to this, and that is to
   separate out the market for expired domains from the normal market
   for new domains.

   This can be done in a similar manner to that for ".biz" and ".info"
   to handle landrush.

   (1) Registry queue up expired domains for a period (e.g 1
   month) and advertise a list of expired domains available

   (2) Registry accepts pre-registrations for these expired domains
   for a period (e.g 1 week)

   (3) Registry executes a random selection from the pre-registrations

   (4) Repeat cycle for ever

   There definitely needs to be a fairer system for allocating expired
   domains.

Rob Hall <rob@momentous.ca>

   Most of the discussion so far has been how to fix HOW the "drops"
   are implemented.  I haven't seen any discussion on WHY there are
   these "drops".  Any fix should take into the account the reason for
   these drops.

   "Drops" occur when domains are put on REGISTRY-DELETE-NOTIFY status
   by the Registry.  Domains changed to this status are removed from
   the root zone files and are scheduled to be batch deleted after a 5
   calendar day waiting period.

   Domains are only changed to this status if a Registrar deletes a
   domain name outside of the 5 and 45 day grace periods.  The 5 day
   grace period applies to new, transferred and explicitly renewed
   registrations and the 45 day grace period applies to auto-renewed
   registrations.

   For most Registrars, expired domains never go to
   REGISTRY-DELETE-NOTIFY status.  We want to make sure that we don't
   lose an extra $6 to VeriSign, so we delete an expired domain name
   within the 45 day grace period.  When this occurs, the domain is
   available IMMEDIATELY for re-registration.  These names are not
   part of the "land rush" that occurs at 6:30 Eastern US time.

   Now the vast majority of the expiring domains reside in the legacy
   Registrar -- Network Solutions -- which as we know is part of
   VeriSign.  For reasons unique to Network Solutions, they as a
   Registrar have decided not to delete unpaid domains within 45 days
   of expiration.  Hence the "land rush".

   My suggestion is that we eliminate the "land rush" by asking
   Network Solutions to play by the rules that the rest of us
   Registrars are financially constrained to follow.  If 45 days is
   not a large enough grace period for Network Solutions to delete
   expired domains from their database, I (personally as I do not
   speak for the employer) would be willing to support a request for
   VeriSign to extend the 45 day grace for all Registrars.


Tucows Inc. Memo
08/10/2001
Re: Verisign Registry Performance, Connection Limits and Domain
Expiration Policy Recommendations
To: General Distribution
Status: Public

   Recent events have made it clear that Accredited CNO Registrars and
   Verisign Global Registry Services must modify their procedures and
   policies in order to more effectively deal with the expiration and
   release of domain names.

   A determined examination of not only the root problems, but also
   the existing policy must be undertaken in order to properly resolve
   the service issues that the community faces. This can only be
   achieved through concerted cooperation and discourse between the
   registry and the registrars.

   VGRS has a number of options at their disposal that would
   streamline their processes and allow them to operate more
   efficiently. This would not only benefit their operations, but also
   accredited Registrars and their users.

   Executive Summary
   -----------------

   The General Proposals allow Registrars to explore new ways to
   streamline their operation and provide additional offerings and
   enhanced customer service to their clientele. It also provides the
   Registry with a number of effective mechanisms for managing the
   resource and load allocation issues internal to their systems.

   The Domain Expiration and Release Improvement Proposals allow
   Registrars and the Registry to more effectively manage the deletion
   and re-registration process while ensuring that this valuable
   resource is appropriately exploited.

   General Registry Improvement Proposals
   --------------------------------------

   1. Replicate key Registry data to Registrar systems. This solution
   has the merit of carrying a broad range of benefits for the
   Registry and Registrars and closely plays into the points presented
   further in this memo. Replicating key data will not only distribute
   the load to individual Registrar systems, but also put the
   Registrar in a position to determine their own resource allocation
   policies rather than relying on the current system of centralized
   control and enforcement.

   The number of changes to this data are minimal in comparison to the
   number of records in the database. Appropriate replication
   mechanisms will ensure that the Registry is not overly burdened
   with data transport overhead and completely minimize the current
   problem of check commands, connection grabbing and the other
   symptoms displayed by the rush to grab expired domains.

   2. Provide Registrars access to data associated with the STATUS
   command via the RRP. Currently Registrars can only retrieve
   information on domain names that the Registrar owns. While this
   information is freely available out-of-band via the CRSNIC whois
   data output, VGRS restricts the availability of this information
   via the RRP. The reason for this restriction is not documented.

   If Registrars had access to this data in bulk format, it would be a
   trivial exercise for them to populate a database local to the
   Registrar with the data and use it as a semi-authoritative source
   for lookups.  Updates to this dataset could be retrieved via the
   RRP to ensure reasonable synchronization with the Registry
   data. Going forward, as domains are checked that are not in the
   Registrars local database, the Registrar could perform a status
   command to determine when the Registrar might need to check the
   domain name record again base on the expiration date of the record.

   This arrangement also has the collateral benefit of minimizing the
   number of whois lookups that a registrar is required to undertake
   during inter-registrar domain transfers and other administrative
   processes.

   This is a very important recommendation. There should be no reason
   why a Registrar should have to lookup domain names against the
   Registry on a regular basis if the Registrar is provided with the
   basic data required to know when a domain name is expiring. Under
   the current system, if a Registrar receives 10,000 lookup requests
   from potential Registrant concerning a domain name, the Registrar
   is forced to undertake 10,000 unique lookup requests on the name
   because its actual status is unknown to the Registrar.

   3. Publish ON HOLD data. According to our estimates, there are at
   least 1 million domain names that are currently on hold. It is not
   currently possible to authoritatively determine which names are on
   hold unless the registry is queried directly via the RRP. This
   generates a great deal of unecessary traffic at the protocol level
   that could easily be handled through other out-of-band means. For
   instance, ON HOLD status could be distributed within the Zone Files
   themselves, either as a standalone file, or as comments within the
   operational zone file.

   4. Separate the 'check' and 'status' commands from those which
   actually make changes (like add or modify) into separate databases
   and/or servers. Registrars should connect to one system for checks
   and one for action items which modify the database.  System
   modifications to Registrar systems would be trivial and isolate the
   impact of any abuse that may occur through either of these systems.

   Domain Expiration and Release Improvement Proposals
   ---------------------------------------------------

   There are a number of areas that the Registry need seriously
   examine in order to better serve the needs of their Registrar
   clientele. The Registry needs to consider these, and all other
   serious proposals, very carefully to ensure that the long-term
   solution and the ramifications of that solution are beneficial to
   the DNS community.

   1. Schedule and publish the domain name expiration and deletion
   schedules.  Various entities have implemented a variety of bizarre
   and questionable processes to determine which domains are scheduled
   to be released and when. The system-wide overhead (including
   Registrar and Registry systems) is excessive.

   If expirations were scheduled and published, the "expiration
   land-rush" could effectively be managed to occur at times deemed
   appropriate by the registry instead of occurring over a 12 to 14
   hour period currently determined by speculators. Further, if the
   Registry included domain name registration and expiry data as the
   response to a "check" and "add" commannd, it would be trivial for a
   Registrar to determine that a deleted name had been re-registered
   and stop checking the status of the domain or attempting to
   register it. Currently the behavior is such that speculators will
   continue issuing check commands until they feel that the window for
   the expiration and release of the domain has reasonably passed and
   assume that domain has been registered by someone else. Only at
   this point will they cease their efforts to procure the domain
   name.

   2. Create a separate subsystem within the Registry to specifically
   handle re-registration requests. Even if the association processes
   did not change, segregating re-registration requests from standard
   registration requests would eliminate the resource constraints and
   arbitrary restrictions currently experienced by Registrars.

   3. Create a randomized landrush queue for re-registration requests.
   Queuing the re-registration requests for specific domains from
   Registrars (one request per domain name per Registrar) in a
   randomized round-robin queue will completely eliminate the
   re-registration rush as we know it. Any names that are not
   re-registered by a Registrar could easily go back into the general
   pool of available names with limited/non-existant impact to the
   Registry at a later date.

   Summary
   -------

   A balanced approach that includes improvements to operational and
   technical processes at both the registry and the various registrars
   will provide a reasonable and efficient solution to the problems
   currently faced by VGRS and CNO Registrars. Specifically dealing
   solely with the technical hurdles posed by the "drop-landrush" will
   not conclusively deal with the root problems that the community is
   now facing. Open and responsible dialog combined with decisive and
   measured application of revised policy will be key to ensuring that
   the Registry resources are appropriately and responsibly utilized.




<<< Chronological Index >>>    <<< Thread Index >>>