<<<
Chronological Index
>>> <<<
Thread Index
>>>
[gnso-pednr-dt] Re: Critical customer mistakes often blamed on domain registrars
- To: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>, PEDNR <gnso-pednr-dt@xxxxxxxxx>
- Subject: [gnso-pednr-dt] Re: Critical customer mistakes often blamed on domain registrars
- From: Marika Konings <marika.konings@xxxxxxxxx>
- Date: Tue, 20 Oct 2009 13:08:34 -0700
Paul, I did speak to Andrew Allemann and he provided me with the details of the
registrar programme that offered resellers a percentage of the auction proceeds
for an expired domain. He did indicate that he did not know whether this
programme was still in existence as there had been some changes at the
registrar in question in the last few months. As a result, I contacted the
responsible registrar about this programme and they informed me that the
programme had ended in December 2008.
With best regards,
Marika
On 20/10/09 17:11, "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx> wrote:
FYI - Any luck reaching out to Domain Name Wire's Andrew Allemann about
addressing this WG?
Domain Registrars Often Blamed for Customers' Mistakes (Domain Name Wire,
102009)
http://domainnamewire.com/2009/10/20/domain-registrars-often-blamed-for-customers-mistakes/
Critical customer mistakes often blamed on domain registrars.
When online backup service CrashPlan.com went down earlier this month, the
company was quick to blame its domain name registrar GoDaddy
<http://godaddy.com> . Code 42 Software, which runs the CrashPlan.com service,
tweeted <http://twitter.com/crashplan> about how GoDaddy
<http://www.kqzyfj.com/click-353176-10378406?sid=dnw> "mistakenly removed our
root nameserver entry", "inappropriately took over our DNS", and did a DNS
"hijack".
What Code 42 Software never tweeted was that it had mistakenly let the domain
name expire. The outage was Code 42's fault, not GoDaddy's.
None of the previous five e-mails GoDaddy sent to Code 42 Software alerting
them to the impending expiration got the company's attention.
The myth that GoDaddy was to blame then spread across the web. One commenter on
an unrelated CNET story wrote
<http://news.cnet.com/8301-13860_3-10375186-56.html> that "GoDaddy somehow
hosed their domain." (Code 42 Software did not respond to a request for comment
for this story.)
Domain registrars frequently get thrown under the bus when one of their
customers makes a mistake. In another case, a registrant of a popular web site
had their non-Go Daddy email account compromised, which allowed an attacker to
steal their domain name by transferring it away from GoDaddy. The customer
publicly blamed GoDaddy, even though the problem was with the customer's e-mail
security.
GoDaddy deals with the brunt of attacks like this, given its massive size and
mass market strategy. But other registrars feel the heat, too. Earlier this
year fingers were pointed at eNom when several high value domain names were
stolen. The real culprit? The customer used a weak password, allowing the thief
to access their account.
Companies with popular web sites have a number of added tools they should use
to protect against many of the most common domain problems. Moniker and
Fabulous offer domain locking tools
<http://domainnamewire.com/2009/01/07/companies-have-fiduciary-responsibility-to-lock-down-domain-names/>
with added security. GoDaddy offers Protected Registration
<http://www.godaddy.com/gdshop/protect/landing.asp?ci=9004> . Companies should
also subscribe to DomainTools' Registrant Alert
<http://domainnamewire.com/2009/10/12/every-domain-owner-should-subscribe-to-domaintools-registrant-alert/>
to find out about potential theft quickly. The sidebar of this story has
other tips for protecting your domain names.
The difficulty for domain registrars is how quickly misinformation spreads
across the web. It doesn't matter that it was Code 42's fault that
CrashPlan.com went down. It doesn't matter that it wasn't the registrar's fault
that a domain was stolen. Just the accusation, combined with the viral nature
of social media, can damage a registrar's reputation.
[cid:3338921314_31249719]
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|