EPP status reason product paper
Background
In our .uk consultation in 2024, we made 3 key proposals in relation to EPP statuses on our Registry Services Provider (RSP) platform:
- Extending our EPP implementation to use the full functionality available within standard EPP to communicate why particular locks have been applied.
- Allowing all registrars to have full visibility of the standard EPP statuses set, on objects that they can read.
- Extending our Registration Data Directory Services (RDDS) implementation in Registration Data Directory Protocol (RDAP) to publish the statuses.
In parallel, there have been discussions forming within the wider industry on the usage of EPP statuses to confirm information publicly in relation to domain name abuse. Most recently at ICANN82 Seattle in the contracted parties house TechOps group, CleanDNS presented some proposed status reasons that would help in managing DNS abuse mitigation feedback to reporters if it were published via RDAP. The session is recorded and available here, the topic starts around 8minutes 19seconds in.
Our proposals received strong support, and we plan to update our implementation of EPP status in the RSP platform to support clearer information. 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. When it comes to proposals for the publication of the same status information via the RDAP service, there is a need for some further work before we are ready to progress to that stage.
We therefore plan to move forward as follows:
- Implement EPP statuses in EPP for all registrars as proposed in the paper and documented below.
- Work alongside other community members to refine a more widely adoptable RDAP standard for the publication of status reasons openly – this will be on a longer timescale.
- We recognise and note that in the future the list of possible status reasons implemented in step 1 above may be amended to bring them into line with an agreed position.
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. |
Today, any one of the registry set statuses would show in EPP with the form:
<domain:status s=”serverUpdateProhibited” /> This indicates which lock status is set, but provides no further context as to why it may be 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 will make the EPP server status lock type(s) visible in EPP which would be done by means of a comma separated list within EPP structure so that an object locked only with Registry Lock would display 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 was both locked with Registry Lock and by the Dispute Resolution Process Lock it would show:
<domain:status s=”serverUpdateProhibited”>Registry Lock, DRS Lock</domain:status> The list of locks will match 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. |
Today, any registrar set statuses would show in EPP with the form:
<domain:status s=”clientUpdateProhibited” /> This indicates which lock status is set, but provides no further context as to why it may be 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 will make the EPP client status lock type(s) set-able in EPP which would be done by means of a comma separated list within EPP structure so that an object locked only with [****INSERT LOCK NAME] would display 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 would show:
<domain:status s=”clientUpdateProhibited”>Security,Investigation</domain:status> The initial list of registrar set locks that we propose are 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 will remain 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 plan to gracefully support them.
Summary implementiation 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.The proposed list of locks a registrar will be limited and initially to the client locks above subject to the feedback from registrars.
Feedback request
The base proposal had widespread support; we are now seeking any direct feedback on the locks that we will make available to registrars at this time. We expect this will evolve as the wider industry looks at this area and therefore consider this an enabling step which can be amended over time to provide functionality registrars need.
Please respond by the 9th July 2025.
Minerva House, Edmund Halley Road, Oxford Science Park, OX4 4DQ, United Kingdom