Locks: EPP Status Reasons

Nominet makes use of the full functionality available within standard EPP to communicate why particular locks have been applied. Allowing all registrars to have visibility of why the standard EPP statuses set, on objects that they can read.  

Please note the EPP elements are not an extension of EPP but an enablement of aspects contained within the RFC5731, RFC5732 and RFC5733 standards and available on some other platforms.

EPP Server Statuses

EPP Domain, Host or Contact objects can have a variety of different lock statuses attached to them.  The service status can indicate what is not permitted to be done to that object.  It is important to note that server statuses are read only via EPP.  

Registry set status	Meaning
serverDeleteProhibited	Requests to delete the object MUST be rejected.
serverHold	DNS delegation information MUST NOT be published in the zone for the object.
serverRenewProhibited	Requests to renew the object MUST be rejected.  This has no impact on auto-renew.
serverTransferProhibited	Requests to transfer the object MUST be rejected.
serverUpdateProhibited	Requests to update the object (other than to remove this status) MUST be rejected.

Previously, any one of the registry set statuses would show in EPP with the form:   

<domain:status s=”serverUpdateProhibited” />

This indicated which lock status was set, but provided no further context as to why it may have been set. Our internal systems have a range of different locks that can be set individually or together.

For example, serverUpdateProhibited may be set as part of a paid-for ‘Registry Lock’ service purchased by the customer; or alternatively it may be set in response to a law enforcement takedown action related to the domain or another policy reason.

We have now made the EPP server status lock type(s) visible in EPP by means of a comma separated list within EPP structure so that an object locked only with Registry Lock displays as follows:

<domain:status s=”serverUpdateProhibited”>Registry Lock</domain:status>  
<host:status s=”serverUpdateProhibited”>Registry Lock</host:status>  
<contact:status s=”serverUpdateProhibited”>Registry Lock</contact:status>  

Whereas if a domain is both locked with Registry Lock and by the Dispute Resolution Process Lock it now shows: 

<domain:status s=”serverUpdateProhibited”>Registry Lock, DRS Lock</domain:status>  

The list of locks matches our internal lock names, which are currently:

Lock name	Registries	Lock usage
Registry Lock	All	A premium service; managed by registrars to prevent EPP based updates.
Trusted Notifier	All	When a registry receives a takedown request compliant with registry policy.    In .UK, .CYMRU and .WALES this will be utilised, for Law Enforcement takedowns.
Policy	All	When a registry applies restrictions based upon their policy.
Local Law Compliance	All	When a registry must comply with special locking requirements under a particular law.   For example, to meet MIIT regulations in China.
Legal	All	Utilised when a court order has been received requiring restrictions.
ICANN – URS Lock	gTLD only	Applied subject to ICANN’s URS policy.
ICANN – URS Suspension	gTLD only	Applied subject to ICANN’s URS policy.
Policy – Data Quality	All	Applied subject to a Data Quality policy.
Policy – Domain Watch	All	Applied subject to a Domain Watch policy.
Secure	All	Applied to add registry operator provided security to the domain.
Security Threat	All	When a registry has applied a lock subject to a DNS abuse mitigation or security threat policy.
DRS Lock	.UK only	Utilised for Nominet’s Dispute Resolution Service which applies to .UK domains only.

Note: Any implementation should also cater for a lock that has no reason specified, as it is today. Additionally graceful support for new or changed names should be used.

EPP Client statuses 

EPP Domain, Host or Contact objects can have a similar variety of different lock statuses attached to them set by the EPP client (aka the registrar).  The status can indicate what is or is not permitted to be done to that object. 

Registrar Set Status	Meaning
clientDeleteProhibited	Requests to delete the object MUST be rejected.
clientHold	DNS delegation information MUST NOT be published in the zone file for the object.
clientRenewProhibited	Requests to renew the object MUST be rejected. This has no impact on auto-renew.
clientTransferProhibited	Requests to transfer the object MUST be rejected.
clientUpdateProhibited	Requests to update the object (other than to remove this status) MUST be rejected.

Previously, any registrar set statuses would show in EPP with the form:   

<domain:status s=”clientUpdateProhibited” />  

This indicated which lock status was set, but provided no further context as to why it may have been set.  A registrar may have a range of different reasons that they may wish to note individually or together.  

For example, clientUpdateProhibited may be set as part of abuse mitigation; alternatively it may be set as part of securing the domain configuration as the registrant’s request or as part of an order by law enforcement or another policy reason. 

We have now made the EPP client status lock type(s) set-able in EPP by means of a comma separated list within EPP structure so that an object locked only with Security lock displays as follows: 

<domain:status s=”clientUpdateProhibited”>Security</domain:status>
<host:status s=”clientUpdateProhibited”>Security</host:status>  
<contact:status s=”clientUpdateProhibited”>Security</contact:status>

Whereas if a domain was both locked with Security and by Investigation it now shows: 

<domain:status s=”clientUpdateProhibited”>Security,Investigation</domain:status>  

The list of registrar set locks is as follows: 

Client Lock	Intended meaning
Security	The lock is in place to enhance the security of the object.
Investigation	An ongoing investigation exists in relation to the object.
Concluded Investigation	An investigation has concluded and the registrar considers the lock appropriate mitigation for the thing they were investigating.

Note: It remains possible to use client locks without setting any of these locks.

Even where a registrar chooses not to utilise a client status lock; they may experience one on domains, hosts or contacts that have transferred in and should gracefully support them.

Summary implementation requirement.

Registrars should ensure that their EPP client can handle each of these formats for server statuses, it is for the registrar to decide if they wish to make use of the lock name information in their own systems or processes and any implementation should not hard code in the existing server lock names but remain flexible.

<domain:status s=”serverUpdateProhibited” />  
<domain:status s=”serverUpdateProhibited”>[LOCK NAME]</domain:status>  
<domain:status s=”serverUpdateProhibited”>[LOCK NAME 1],[LOCK NAME 2]</domain:status>  where [LOCK NAME 1] and [LOCK NAME 2] are different locks separated by a comma.

Registrars should also ensure that they can handle status values of similar formats on info commands as incoming transfers may contain them.

<domain:status s=”clientUpdateProhibited” />  
<domain:status s=”clientUpdateProhibited”>[LOCK NAME]</domain:status>  
<domain:status s=”clientUpdateProhibited”>[LOCK NAME 1],[LOCK NAME 2]</domain:status>  where [LOCK NAME 1] and [LOCK NAME 2] are different locks separated by a comma.