ICANN ICANN Email List Archives

[At-Large Advisory Committee]


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

[alac] new domain name kiting post

  • To: alac@xxxxxxxxx
  • Subject: [alac] new domain name kiting post
  • From: Jean Armour Polly <mom@xxxxxxxxxx>
  • Date: Wed, 18 Oct 2006 08:14:05 -0400

I want to call everyone's attention to a new post over on the ICANNALAC discussion board
dfil has just posted in the Domain Name Kiting forum of ALAC Discussions under the title of 'Domain Kiting' proposals.


This thread is located at http://icannalac.org/forum/showthread.php?t=20

Here is part of the message that has just been posted:
***************
Currently, it seems like there is no common agreement on what to do against it. Perhaps the most common discussed solution is that proposed by Bob Parsons calling for deletion fees. However, there are also some additional aspects to consider.


The Domain Kiting evidence

Though the domain kiting can be quite easily recognized intuitively (when a registrar gains 10 times more domains than he actually possesses, of which over 90 percent are lost (and regained again) during one month without paying a dime); an unequivocal proof of such activity can hardly be provided. The problem is that registrars have no legal obligation to officially account for the reasons leading to delete and regain domain names repeatedly (they simply cancel the registration after 5 days and get the money back). We can still imagine a legal scenario - an incompetent registrar verbally claiming to fail to complete most of its domain name orders in due to alleged massive fraudulent order attacks being constantly made on him; and immediately rushing for new registrations for the same names. This is a pretty stupid argument but, unfortunately, legally hardly controversial.
But even if the registrars were obliged to keep traceable evidence of such deletion (/regaining) stored, there is still a possibility how to fabricate it. In fact, the only efficient way seems to prevent domain kiters from even thinking of doing so. Some ideas...


1. Redefinition of Add Grace Period

The original meaning of Add Grace Period is to allow for typo corrections as well as for cancelling fraudulent domain orders resulting in complete reimbursement of the registration fee if this comes to happen. For typo corrections we normally needn't the reimbursement as the registrant doesn't demand to cancel the registration but rather to correct the name (sure, in some cases, the corrected name can already be taken and the registrant can no longer be interested in it). In such cases

a) The registrar should explicitly ask the registry for removing the domain name and reimbursing the order, but only upon written detailed and traceable evidence sent to the registry. The registry can then decide to accept or deny such a request. This would bring more overhead on both sides but could be deterrent enough for domain speculators.

b) Other possibility is to apply the Bob Parsons' approach where the deletion can be made directly on registrar's behalf (as usual) but charged some fee. The problem here is that the fee could still be too low to avoid the speculations, although, the overall number of 'tasted' domains would certainly go down.

2. The 'Forbidden DNS Entry' approach

Surprisingly enough, there exists another way how to dramatically decrease the 'kiting' effort, which as far as I know has not been broadly discussed yet. The main idea is that during the Add Grace Period no DNS entry for a new domain name may exist in the registrar's root DNS records. In other word, unless a domain is properly registered and paid for, no DNS entry is allowed on any root TLD server for that domain.
The idea is to completely cut off the kiters from doing pay-per-click advertising, which is the core of their 'tasting' effort. Without having access to the Internet the kiters cannot measure the domain name ranking and therefore cannot taste the quality of the name.


Violation of the 'Forbidden DNS Entry' rule can be quite easily detected by comparing the registration status of the given domain name and the domain accessibility on the Internet. If the domain has not been properly registered but an existing TLD server's IP address for the name is obtainable e.g., by ping-call (or even the related website is publicly accessible), the registrar has evidently violated this rule.
In the new contract, a violation of this rule should give ICANN the right to cancel the registrar's accreditation.


3. Honestly, do we really need Add Grace Period?

In general, the two arguments mentioned above, typo corrections and fraudulent orders, constitutes the meaning and intention of Add Grace Period (AGP). Let's have a look at them more in detail...

1. For typo corrections we don't need AGP as the correction doesn't cause the order to be cancelled; it just gives registrants an opportunity to correct minor typos in their domain name during a short period after the registration. To avoid possible misuse only one such a correction should be possible. The typo change should be officially requested at registrar, accepted or rejected by registry (not registrar) and the request archived at registry for further investigation purposes. As this approach brings an additional overhead it doesn't have to be broadly accepted.

2. Refund in due to fraudulent orders sounds a bit suspicious. If this was true then the domain registration service would profit from a privilege other services can just dream of. I can't mention any service (such as ordering software online for hundreds dollars) that is protected by any such a sort of 'grace period'. It this happens to them they have to go to court and claim their money back. I don't see any reason for prefering domain registration to other services in such a way.

Getting summarized, there is not too much left for keeping on supporting the AGP approach. The pros are negligible and the cons enormous - millions of snatched domains that are not paid for and are being constantly taken out of people willing to buy and use them.

Perhaps..., we could get rid of AGP at all.

Dominik



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

Privacy Policy | Terms of Service | Cookies Policy