ICANN ICANN Email List Archives


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

New Transfer Policy facilitates domain thefts

  • To: transfer-comments-a@xxxxxxxxx
  • Subject: New Transfer Policy facilitates domain thefts
  • From: George Kirikos <George@xxxxxxxxx>
  • Date: Sun, 16 Jan 2005 17:23:00 -0500


There were MORE stolen domains than just panix.com. On an adult
webmaster forum (I won't link there, as this is a family-list,
presumably), someone revealed his Easy-Dater.com domain was hijacked
this weekend from Dotster, going to DirectI.com. After some further
research, I found that AEM.com and F3.com were likely stolen by the
same person (i.e. have the same ns1/2.xybererotica.com nameservers, and
repointed to the same IP). If someone can grep the zonefiles for all
other *.xybererotica.com nameserver domain names, that would likely
reveal a list of other stolen domains.

Even though the new WHOIS was fake, Bhavin of DirectI wasn't really
helpful. The nameservers of Easy-Dater.com have been put into a
"suspended" state, instead of pointing back to the prior nameservers.
We're talking about enormous lost traffic, too (an Alexa top 2000
site). The thief left his counter public and not password protected
(disovered browsing through a text browser -- don't use IE or FireFox,
or you fax popup hell visiting the hijacked domains), and you can view
the stats (browser safe) at:


Almost 500,000 unique visitors were diverted yesterday to spyware. Going through the referrer logs can help discover some stolen domains, but basically DirectI and others need to be more forthcoming with the list of names that went to them. They are not proactive, they are reactive.

I have to disagree strongly with Ross regarding the state of the
transfer system. The old system was premised on the idea that there
were  rogue registrars gaming the system, to block transfers. The new
system DID NOT ELIMINATE ROGUE REGISTRARS (or Registrars with inept
systems that hackers can abuse)! I hate to say "I told you so", but the
new system's weakness is that it ASSUMES the gaining registrar has
proper authentication of the transfer. What are the penalties for
registrars that don't properly do it? A Canadian registrant is supposed
to "trust" a registrar equally to do authentication, even if they've
never done business with it before, and are in India, Korea, etc??

Steps that should be taken:

1) I think Tucows (and other security conscious registrars) should
immediately LOCK all their customer domain names, just like NSI did, as
a measure to make it harder for the current wave of thefts to continue.
A lot of high profile domains are unlocked right now, and ripe to be
stolen by rogue registrars or individuals. I am willing to bet that at
least some of the folks rushing to get accredited are doing so in order
to be able to steal domains that have bad contact info (a lot of
domains were stolen because the owners are entirely unreachable, and
thus hard to make a claim against the thief without reaching the prior
owner). Those names should rightfully have been deleted, going into the
drop cycle after expiry, but are systematically being stolen prior to

2) I think security conscious registrars should implement "soft and
sticky unlocks", as I suggested to ICANN and others already.  What
would happen is that when a domain name is unlocked, the registrant
would be able to specify a specific registrar that they would permit
transfers to. A transfer request from any other registrar would be
auto-rejected (either by the existing registrar, or the registry,
depending on how it is implemented), and if a transfer wasn't initiated
within a given time window (e.g. a day or two) from the permitted
gaining registrar, the domain would automatically go back to a normal
locked (that's the "sticky" part).

This would prevent the problem that some are having, where high-value
domain names are being monitored continuously for changes in their lock
status -- once they are unlocked, a wave of fraudulent transfer
requests arrive from some of the minor registrars (e.g. ones in China
or Korea), trying to steal the domain.

It might be difficult to implement the above at a Registry level, but
it shouldn't be hard for a registrar to do it. While not a "Consensus
Policy" suggestion, perhaps it can be a part of a separate "Best
Practices" document that security-conscious registrars can implement?
Such "Best Practices" would help prevent undermining and balkanization
of the system, as folks interpret the new transfer policy different
(e.g. some registrars, eg. Moniker, will auto-NAK transfers unless a
second confirmation is received, which I think should be allowed, IF
and ONLY IF it's something the registrant opted-in to -- registrants of
very valuable domains should be able to opt-in to higher security).

3) Double-confirmation (i.e. confirmation of a tranfer by the
registrant via a mechanism of the losing registrar) should be permitted
on an opt-in basis explicitly in the Transfer Policy.

4) "NameServer Sticky Unlock" that only permits changes in the
nameservers, but autorejects transfers, and returns to regular lock
status after a fixed period (e.g. 1 day) can be implemented by
registrars too.

5) There needs to be a public audit trail over how domain name
transfers took place (so that we don't need to rely on
begging/subpoenaing registrars to provide the info to us). Then, buyers
can have confidence that the valuable domains that they are purchasing
have good provenance, and registrants are better able to show (without
the huge expense of lawyers) that the names were hijacked (e.g. via
fraudulent faxes, etc. -- one would think NSI would have learned given
what happened with Sex.com, but they have not). We're talking about
very high profile names too (e.g. yy.com, IRAQ.com, Wifi.com,
secretary.com, and many others -- not all have been recovered, as
sometimes it's hard to find the original
registrants, in order to trace the chain of ownership -- e.g. the
registrant dies, and then the name is stolen, before it can be properly
deleted and made open to a fresh owner).


George Kirikos

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

Privacy Policy | Terms of Service | Cookies Policy