Menu

.UK EPP Status Fields

This document outlines the EPP status field functionality detailed in RFC5731, RFC5732 & RFC5733 into the .UK EPP environment.

Details of included status fields, as well as affected system protocols and behaviours are provided below, with examples.

Status Fields

The status fields for each object type that will be used will be as per the RFC documentation, however at this time a subset will be in use based on the wider business logic of the UK platform.

Such status fields may have been set by:

  • The current registrar
  • The former registrar
  • Nominet as Registry Operator
Status Domain Host Contact Meaning
clientHold X – – Removes the domain from the zone file.
clientDeleteProhibited X – – Prevents the domain being deleted by EPP or Web Domain Manager.
The regular domain expiry process and other Nominet processes are unaffected for names that have expired or at the Registry Operators initiative.
clientRenewProhibited

 

X

 – – Prevents a RENEW request being accepted by EPP or Web Domain Manager.
clientTransferProhibited X – – Prevents a RELEASE command being accepted by EPP or Web Domain Manager.
This setting does not prevent a registrant transfer a name to a new registrar via Nominet’s online services as that is a Registry Operator action.
clientUpdateProhibited X X X Prevents an UPDATE command being accepted by EPP or Web Domain Manager, except for an UPDATE to remove the clientUpdateProhibited status alone.
This status also restricts updates to extension fields such as the auto-bill and next-bill fields.
linked – X X Identifies the host or object is linked to one or more domains.
Inactive X – – Identifies that no nameservers exist on the domain.
ok X X X Identifies that no other statuses exist on the domain.
pendingCreate – – – –
pendingDelete – – – –
pendingTransfer X X – Where a HANDSHAKE operation is required for a domain to transfer, the domain will be set to pendingTransfer if a RELEASE command is issued. If that domain has subordinate HOSTS they will also be set to pendingTransfer.
pendingUpdate – – – –
pendingRenew – – – –
serverDeleteProhibited X – – Prevents the domain being deleted by EPP, Web Domain Manager, by registrants in Online Services or by Nominet processes.

 
serverTransferProhibited X – – Prevents a RELEASE command being accepted by EPP or Web Domain Manager and prevents a Registrant from transferring the domain to a new registrar directly via Nominet.
serverUpdateProhibited X X X Prevents an UPDATE command being accepted by EPP or Web Domain Manager, or by the Registrant directly with Nominet.
This status also restricts updates to extension fields such as the auto-bill and next-bill fields.
serverRenewProhibited X – – Prevents a RENEW request being accepted by EPP, Web Domain Manager or by registrants in Online Services.
This status over-rides any existing auto-bill and next-bill fields, and prevents them being set.
serverHold X – – Removes the domain from the zone file.

Authorised Use of CLIENT Status Fields

You are permitted to use CLIENT statuses in their normal day to day management of domains, contacts and hosts.

Where the registrant of a domain requests the removal of a CLIENT status from a Domain, Registrant Contact or sub-ordinate host object, you must remove it in a timely fashion unless the status has been applied to address domain name abuse or data quality.

Commands

EPP status fields are implemented into INFO and UPDATE commands for the Domain, Host and Contact objects. Please ensure your EPP client is updated to be able to utilise status fields in UPDATE requests and parse INFO responses for each of these objects.

INFO Command

Zero or more <object:status> fields will be included in the <object:infData> entity of the INFO response, listing each of the currently active statuses in separate field entries.

For details of the available statuses for the different registry objects, see the “Status Fields” section above; examples of status fields as part of the INFO command can be found in Exhibit A – INFO Command Examples at the end of this document.

UPDATE Command

Zero or more <:status> fields can be included in any of the <:add> or <:rem> entities of the UPDATE request, noting that each individual status should be encapsulated within its own entity.

For details of the available statuses for the different registry objects, see the “Status Fields” section above; examples of status fields as part of the INFO command can be found in Exhibit A – UPDATE Command Examples at the end of this document.

System Behaviours

There are a number of system behaviours that are affected by the addition of these status fields, including:

Locks

Investigation Lock

The investigation lock is used to deal with abusive domains, and provides for a number of functions catered for by status fields. Nominet’s systems will continue to support the Investigation Lock and map visibility of the status to server statuses.

The investigation lock can be applied to either a Domain or Contact object. When the lock is applied a range of limitations are added to EPP objects; we represent these limitations as server statuses because while it is possible to amend these statuses, the existing locking functionality must be used to unlock a lock that has been applied using the Investigation Lock.

We will update the Investigation Lock so that the following applies:

  • Domain object investigation locks – If you choose to set an investigation lock on a domain object the following statuses will be added to the domain object only:
    • serverHold
    • serverUpdateProhibited (preventing the modification of the domain objects linked registrant or nameservers or statuses. Including autorenewal and notes)
    • serverTransferProhibited
    • serverDeleteProhibited
    • serverRenewProhibited
  • Contact object investigation locks – If you choose to set an investigation lock on a contact object the following statuses will apply on:
    • Contact Object
      • serverUpdateProhibited
      • The system will additionally prevent any new or existing domains being newly associated with this contact object
    • Domain Object – All domains connected to the contact will be set as per Domain object Locks above
Investigation lock vs client statuses

Nominet recognise that you may be dealing with abuse across many top level domains on a day to day basis, and differences in the technical implementation can add unneeded complexity. If you wish to use EPP client statuses to deal with abuse instead of the investigation lock, Nominet explicitly permits this. The only difference in effect would be that client* statuses do not prohibit the registrant transferring the domain via a paid transfer in Nominet online services.

Data Quality Lock (DQ Lock)

This lock is only applicable where Nominet has been unable to validate data.

The DQ lock can be applied to the Domain where the domain is on a:

  • Channel Partner and Self-Managed tag, and Nominet will apply the DQ lock
  • Accredited Channel Partner tag, and you will apply the DQ lock

When the lock is applied a range of limitations are applied to EPP objects; we represent these limitations as server statuses because while it is possible to amend these statuses, the existing locking functionality must be used to unlock a lock that has been applied using the DQ Lock.

The process will be updated so that it is visible in EPP statuses as follows:

  • serverTransferProhibited – preventing a change of registrar
  • serverHold – preventing the domain from resolving
DQ lock vs CLIENT statuses

Nominet recognise that you may be dealing with data quality issues across many top level domains on a day to day basis, and differences in the technical implementation can add unneeded complexity. If you wish to use EPP client statuses to deal with abuse instead of the DQ lock, Nominet explicitly permits this. Nominet will recognise the setting of clientTransferProhibited, ClientUpdateProhibited and clientHold on the Domain object as being equivalent to the DQ Lock. Where a registrant’s data has not been validated by Nominet and clientTransferProhibited is set it will be possible for a registrant to transfer a domain to another registrar directly with Nominet.

Domain Lock

Domain Lock is a premium locking product that allows high value domains an additional level of protection by locking a range of objects. Domain Lock will be represented in server statuses as follows:

  • Domain object
    • serverUpdateProhibited
    • serverDeleteProhibited
    • serverTransferProhibited
  • Contact object linked to a domain – serverUpdateProhibited

Domain Lock offers superior protection over the use of client statuses.

Nominet applied Locks

From time to time Nominet applies locks to domains in order to deal with abuse, these locks will be represented using server statuses in EPP.

System Business Rules

There are a number of system business rules in the .UK top level domain that apply to all names and are not a special status. In those cases we will not represent these behaviours as status fields.

For example:

  • There are limitations through the normal lifecycle of a domain on when a registrar can delete a name. This will not be represented as a server statuses
  • If a renewal would take the domain over the maximum 10 year life of a domain a renewal will be prohibited but not be represented as a server statuses on a name

Status Restrictions

  • Where an auto-renew has been set on a name, a request to set clientRenewProhibited will be rejected
  • Where clientRenewProhibited is already set, an attempt to add an auto-renew will be rejected
  • Where clientUpdateProhibited is set, an attempt to change details of an object will be rejected (including changes to auto-renewal and billing settings)

Domain Transfers

The functional process of domain transfers will not be affected by status fields, though there are some considerations that we recommend you make for the addition of status fields.

  • Incoming transfers to your TAG:
    Domains arriving on your tag will retain the same state as when they left the previous registrar’s TAG. For example, if clientUpdateProhibited has been set by the losing registrar then it will be present when it arrives on your TAG. It will therefore need to be removed before you can update the nameservers connected to that domain. Some registrars may wish to configure their systems to process these statuses at the time of domains arriving on your TAG.
  • Once domains are on your TAG:
    CLIENT statuses refer to your EPP Client or Web Domain Manager and will only be set by you as the registrar (registrants cannot make changes in online services).
    SERVER statuses can only be edited by Nominet or our system processes such as DQ Lock.
  • Domains that are pendingTransfer away from your TAG
    We understand different registry platforms treat this status differently. The introduction of pendingTransfer status for visibility does not impact any actions on the domain object.

Future Development

In the longer term we intend to introduce RFC8590 to provide notification based information as to why a status has changed to a new setting.

Exhibit A: EPP Examples

INFO Command Examples

An example Domain response object is as follows:

<domain:infData
xmlns:domain=”urn:ietf:params:xml:ns:domain-1.0″
xsi:schemaLocation=”urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd”>
<domain:name>nominet-example.co.uk</domain:name>
<domain:roid>1234567890-UK</domain:roid>
<domain:status s=”clientDeleteProhibited”/>
<domain:status s=”clientHold”/>
<domain:status s=”clientRenewProhibited”/>
<domain:status s=”serverDeleteProhibited”/>
<domain:status s=”serverHold”/>
<domain:status s=”serverRenewProhibited”/>
<domain:status s=”inactive”/>
<domain:registrant>abc1234x</domain:registrant>
<domain:clID>EXAMPLE</domain:clID>
<domain:crID>EXAMPLE</domain:crID>
<domain:crDate>2020-05-17T14:40:01</domain:crDate>
<domain:exDate>2021-05-17T14:40:01</domain:exDate>
</domain:infData>

An example Host response object is as follows:

<host:infData
xmlns:host=”urn:ietf:params:xml:ns:host-1.0″
xsi:schemaLocation=”urn:ietf:params:xml:ns:host-1.0 host-1.0.xsd”>
<host:name>ns1.nominet-example.co.uk</host:name>
<host:roid>NS1_1234567890-UK</host:roid>
<host:status s=”linked”/>
<host:status s=”clientUpdateProhibited”/>
<host:addr ip=”v4″>192.0.3.9</host:addr>
<host:addr ip=”v4″>192.0.3.42</host:addr>
<host:addr ip=”v6″>1080:0:0:0:8:800:200C:417A</host:addr>
<host:clID>ClientY</host:clID>
<host:crID>ClientX</host:crID>
<host:crDate>2019-05-07T20:00:00.0Z</host:crDate>
<host:upID>ClientX</host:upID>
<host:upDate>2019-11-04T10:00:00.0Z</host:upDate>
<host:trDate>2020-05-09T08:00:00.0Z</host:trDate>
</host:infData>

An example Contact response object is as follows:

<contact:infData
xmlns:contact=”urn:ietf:params:xml:ns:contact-1.0″
xsi:schemaLocation=”urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd”>
<contact:id>no1234</contact:id>
<contact:roid>NO1234-UK</contact:roid>
<contact:status s=”linked”/>
<contact:status s=”clientDeleteProhibited”/>
<contact:postalInfo type=”int”>
<contact:name>John Smith</contact:name>
<contact:org>Nominet UK</contact:org>
<contact:addr>
<contact:street>Minerva House</contact:street>
<contact:street>Edmund Halley Road</contact:street>
<contact:city>Oxford</contact:city>
<contact:sp>OX</contact:sp>
<contact:pc>OX4-4DQ</contact:pc>
<contact:cc>UK</contact:cc>
</contact:addr>
</contact:postalInfo>
<contact:voice x=”1234″>+44.1865332233</contact:voice>
<contact:fax>+44.1865332233</contact:fax>
<contact:email>[email protected]</contact:email>
<contact:clID>ClientY</contact:clID>
<contact:crID>ClientX</contact:crID>
<contact:crDate>2019-06-12T21:00:00.0Z</contact:crDate>
<contact:upID>ClientX</contact:upID>
<contact:upDate>2019-12-16T10:00:00.0Z</contact:upDate>
<contact:trDate>2020-06-09T13:00:00.0Z</contact:trDate>
<contact:authInfo>
<contact:pw>2fooBAR</contact:pw>
</contact:authInfo>
<contact:disclose flag=”0″>
<contact:voice/>
<contact:email/>
</contact:disclose>
</contact:infData>

UPDATE Command Examples

An example Domain request object is as follows:

<domain:update
xmlns:domain=”urn:ietf:params:xml:ns:domain-1.0″
xsi:schemaLocation=”urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd”>
<domain:name>nominet-example.co.uk</domain:name>
<domain:add>
<domain:ns>
<domain:hostObj>ns2.nominet-example.co.uk</domain:hostObj>
</domain:ns>
<domain:contact type=”tech”>no5678</domain:contact>
<domain:status s=”clientHold” lang=”en”>Payment overdue.</domain:status>
</domain:add>
<domain:rem>
<domain:ns>
<domain:hostObj>ns1.nominet-example.co.uk</domain:hostObj>
</domain:ns>
<domain:contact type=”tech”>no1234</domain:contact>
<domain:status s=”clientUpdateProhibited”/>
</domain:rem>
<domain:chg>
<domain:registrant>no1234</domain:registrant>
<domain:authInfo>
<domain:pw>2BARfoo</domain:pw>
</domain:authInfo>
</domain:chg>
</domain:update>

An example Host request object is as follows:

<host:update
xmlns:host=”urn:ietf:params:xml:ns:host-1.0″
xsi:schemaLocation=”urn:ietf:params:xml:ns:host-1.0 host-1.0.xsd”>
<host:name>ns1.nominet-example.co.uk</host:name>
<host:add>
<host:addr ip=”v4″>192.0.3.9</host:addr>
<host:status s=”clientUpdateProhibited”/>
</host:add>
<host:rem>
<host:addr ip=”v6″>1080:0:0:0:8:800:200C:417A</host:addr>
</host:rem>
<host:chg>
<host:name>ns2.nominet-example.co.uk</host:name>
</host:chg>
</host:update>

An example Contact request object is as follows:

<contact:update
xmlns:contact=”urn:ietf:params:xml:ns:contact-1.0″
xsi:schemaLocation=”urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd”>
<contact:id>no1234</contact:id>
<contact:add>
<contact:status s=”clientDeleteProhibited”/>
</contact:add>
<contact:chg>
<contact:postalInfo type=”int”>
<contact:org/>
<contact:addr>
<contact:street>Minerva House</contact:street>
<contact:street>Edmund Halley Road</contact:street>
<contact:city>Oxford</contact:city>
<contact:sp>OX</contact:sp>
<contact:pc>OX4-4DQ</contact:pc>
<contact:cc>UK</contact:cc>
</contact:addr>
</contact:postalInfo>
<contact:voice>+44.1865332233</contact:voice>
<contact:fax/>
<contact:authInfo>
<contact:pw>2fooBAR</contact:pw>
</contact:authInfo>
<contact:disclose flag=”1″>
<contact:voice/>
<contact:email/>
</contact:disclose>
</contact:chg>
</contact:update>

Minerva House, Edmund Halley Road, Oxford Science Park, OX4 4DQ, United Kingdom