[ga] Inconsistent Registrar WHOIS output of Registry Lock settings

[George Kirikos <gkirikos@xxxxxxxxx>]

Hi folks,

For several years, registries have been offering domain registry locking 
programs in order to protect high profile domain names. Registry lock typically 
requires out-of-band communications (e.g. a telephone call) between the 
registrar and the registry in order to make changes to a domain name. For 
example, VeriSign offers its VeriSign Registry Lock Service:

https://www.verisigninc.com/en_US/channel-resources/domain-registry-products/registry-lock/index.xhtml
http://www.circleid.com/posts/domain_registry_locking_why_not_use_it/

One can tell that the registry lock is enabled, by looking for the 
serverDeleteProhibited, serverTransferProhibited, and serverUpdateProhibited 
statuses in the WHOIS output. 

However, it appears that some registrars are not displaying the full registry 
lock information in their WHOIS output:

For example, if you look at the authoritative registry WHOIS for Google.com at 
Internic:

http://reports.internic.net/cgi/whois?whois_nic=google.com&type=domain

it shows that the VeriSign registry lock is in effect:

 Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Status: serverDeleteProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited

i.e. the server serverDeleteProhibited, serverTransferProhibited, and
serverUpdateProhibited settings are all visible.

However, if you look at the registrar WHOIS output, either from the MarkMonitor 
website:

https://www.markmonitor.com/cgi-bin/affsearch.cgi?dn=google.com

or from DomainTools.com:

https://whois.domaintools.com/google.com

it only shows the "client" lines (i.e. locks at the registrar level, not 
the "server" lines of the status related to registry locks) in the registrar 
WHOIS output for Google.com:

Domain Status: clientUpdateProhibited
Domain Status: clientTransferProhibited
Domain Status: clientDeleteProhibited

Other registrars are showing the VeriSign registry lock properly settings 
in the registrar WHOIS output, e.g. for Tucows.com at Tucows:

https://whois.domaintools.com/tucows.com

Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Domain Status: serverDeleteProhibited
Domain Status: serverTransferProhibited
Domain Status: serverUpdateProhibited

it lists the "server" lock settings in the WHOIS output. MarkMonitor's 
biggest competitor CSC is also showing the VeriSign registry lock settings, see 
the WHOIS for FedEx.com:

https://whois.domaintools.com/fedex.com

Domain Status: serverTransferProhibited
Domain Status: serverDeleteProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited

It appears that GoDaddy has the same problem, as they're not showing the server 
lock statuses in their registrar WHOIS output, e.g. compare:

https://whois.domaintools.com/godaddy.com

Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Domain Status: clientRenewProhibited
Domain Status: clientDeleteProhibited

with the authoritative registry WHOIS at Internic:

http://reports.internic.net/cgi/whois?whois_nic=godaddy.com&type=domain

Status: clientDeleteProhibited
   Status: clientRenewProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Status: serverDeleteProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited

I think that all the registrars should follow the example of Tucows and CSC, to 
make sure that the registry lock settings are displayed in the registrar WHOIS 
output. With the high profile domain theft of Porn.com, I expect more owners of 
valuable domains will consider these registry lock programs. Although, the 
registries need to make the pricing more affordable and reasonable -- I've 
provided input before on how that could be accomplished, e.g see my 2 comments 
to Elisa Cooper's followup article at:

http://www.circleid.com/posts/20130911_more_than_85_of_top_500_most_highly_trafficked_websites_vulnerable/

where I suggested fees be charged only when an "unlocking" event takes place 
(without ongoing monthly fees), and also allowing for "bulk" unlock 
transactions, where the cost of an "unlocking" event (which causes the 
out-of-band communications thereby generating the real costs) can be spread 
amongst several domain names.

Sincerely,

George Kirikos
http://www.leap.com/