Domain objects and commands
An EPP domain object is defined in IETF defined in STD69 by RFC5731 and is one of the three primary objects utilised in EPP.
Managing Domain objects:
- Domain object data.
- Domain:Check command.
- Domain:Create command.
- Domain:Renew command.
- Domain:Info command.
- Domain:Update command.
- Domain:Transfer command.
- Domain:Delete command.
Domain Object Data
A host object is made up of the following data points, further details can be found in RFC5731, RFC5910 and RFC3915:
| Field | Description | Visible to non-sponsoring registrar without Transfer Authorisation code? |
|---|---|---|
| domain:name | The registered domain. | Yes |
| domain:roid | The unique repository object identifier for the domain object. This is unique over time for this instance of the domain. | Yes |
| domain:registrant | The contact object EPP ID that defines the registrant of the domain – only one registrant contact can exist. For registries which support the minimal data set only this will not be present or settable. | No |
| domain:contact | Any contact object EPP IDs that define any Administrative, Technical or Billing contacts. It is important to note that it is possible to set multiple of each type of contact and you may need to support incoming transfers with multiple of the same type of contact. For registries which support the minimal data set only these will not be present or settable. | No |
| domain:status | An RFC5731 status value. | Yes |
| domain:ns | The names of any host objects to link as nameservers for the domains. | Yes |
| domain:host | A list of any sub-ordinate host objects to the domain. If any sub-ordinate host objects exist within the registry they will be in the control of the same registrar as the parent domain and must be deleted or renamed to allow the parent domain to be deleted. | No |
| domain:crID | The EPP client login ID for the registrar that created the domain. | Yes |
| domain:clID | The EPP client login ID for the registrar that currently manages the domain. | Yes |
| domain:upID | The EPP client login ID for the registrar that last updated the domain. | Yes |
| domain:crDate | The timestamp in UTC that this instance of the domain was created. | Yes |
| domain:upDate | The timestamp in UTC that this instance of the domain was last updated. | Yes |
| domain:exDate | The timestamp in UTC that this instance of the domain expires. | Yes |
| domain:trDate | The timestamp in UTC that the domain last transferred between registrars. | Yes |
| domain:authinfo | The Transfer Authorisation Code for the domain. | No |
| rgp:rgpstatus | The RFC3915 status values for the domain. It is important to note that there is different meaning between RFC5731 pendingDelete and RFC3915 pendingDelete and they co-exist. | Yes |
| secDNS:dsData | Contains the Delegation Signer (DS) record data for DNSSEC signed domains. | Yes |
| It should be noted that a non-sponsoring registrar submitting a domain:info request with the valid Transfer Authorisation Code will obtain the same response as the sponsoring registrar. | ||
domain:check command
The domain:check command can check for availability of one or more domains at the same time. For registries with non-standard domain pricing using the EPP Fee extension will ensure that you have the correct current pricing for any domain you are looking to create or renew. Further information on How to check domain availability is published here.
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<check>
<domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
</domain:check>
</check>
<extension>
<fee:check xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:command name="create">
<fee:period unit="y">2</fee:period>
</fee:command>
<fee:command name="renew"/>
<fee:command name="transfer"/>
<fee:command name="restore"/>
</fee:check>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>An example domain:check response with create, renew, transfer, restore pricing.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:cd>
<domain:name avail="true">example.co.uk</domain:name>
</domain:cd>
</domain:chkData>
</resData>
<extension>
<fee:chkData xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:cd avail="true">
<fee:objID>example.co.uk</fee:objID>
<fee:command name="create">
<fee:period unit="y">2</fee:period>
<fee:fee description="Registration Fee">7.80</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
<fee:command name="renew">
<fee:period unit="y">1</fee:period>
<fee:fee description="Renewal Fee">3.90</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
<fee:command name="transfer">
<fee:period unit="y">1</fee:period>
<fee:fee description="Transfer Fee">3.90</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
<fee:command name="restore">
<fee:fee description="Redemption Fee">0.00</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
</fee:cd>
</fee:chkData>
</extension>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>1848625649065924537</svTRID>
</trID>
</response>
</epp>An example response where the domain is not currently available for registration because it is registered:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:cd>
<domain:name avail="false">example.co.uk</domain:name>
<domain:reason>Registered</domain:reason>
</domain:cd>
</domain:chkData>
</resData>
<extension>
<fee:chkData xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:cd avail="true">
<fee:objID>apep.co.uk</fee:objID>
<fee:command name="create">
<fee:period unit="y">1</fee:period>
<fee:fee description="Registration Fee">3.90</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
<fee:command name="renew">
<fee:period unit="y">1</fee:period>
<fee:fee description="Renewal Fee">3.90</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
<fee:command name="transfer">
<fee:period unit="y">1</fee:period>
<fee:fee description="Transfer Fee">3.90</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
<fee:command name="restore">
<fee:fee description="Redemption Fee">0.00</fee:fee>
<fee:class>standard</fee:class>
</fee:command>
</fee:cd>
</fee:chkData>
</extension>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>1848636231450104903</svTRID>
</trID>
</response>
</epp>Where a domain is unavailable, a domain:check command will show the reason in the following cases:
| Domain Status | EPP response |
|---|---|
| The domain is registered. | <domain:reason>Registered</domain:reason> |
| The domain is pending delete but in the RFC3915 redemption period. | <domain:reason>May Drop YYYY-MM-DDTHH:MI:SSZ</domain:reason> |
| The domain is pending delete and the RFC3915 pending delete period. | <domain:reason>Drop YYYY-MM-DDTHH:MI:SSZ</domain:reason> |
| The domain is reserved across multiple TLDs. | <domain:reason>Reserved A</domain:reason> |
| The domain is reserved. | <domain:reason>Reserved</domain:reason> |
domain:create command
We recommend the usage of the EPP Fee extension as part of the domain:create command whether a registry supports non-standard pricing or not, as it will allow you to track your available balance.
If a registry mandates compliance with RFC9154 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer, then it is compulsory not to provide a <domain:pw> and providing one will cause an error.
An example domain create where the Transfer Authorisation Code must not be set:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<create>
<domain:create 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>example.co.uk</domain:name>
<domain:period unit="y">1</domain:period>
<domain:registrant>EXAMPLECONTACT</domain:registrant>
<domain:authInfo>
<domain:pw/>
</domain:authInfo>
</domain:create>
</create>
<extension>
<fee:create xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:fee>3.90</fee:fee>
</fee:create>
</extension>
<clTRID>EXAMPLE-CREATE-12345</clTRID>
</command>
</epp>An example response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
<domain:crDate>2025-07-09T12:41:42.247Z</domain:crDate>
<domain:exDate>2026-07-09T12:41:42.247Z</domain:exDate>
</domain:creData>
</resData>
<extension>
<fee:creData xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:fee description="Registration Fee">3.90</fee:fee>
<fee:balance>-22934.82</fee:balance>
<fee:creditLimit>70000.00</fee:creditLimit>
</fee:creData>
</extension>
<trID>
<clTRID>EXAMPLE-CREATE-12345</clTRID>
<svTRID>1861654422023577083</svTRID>
</trID>
</response>
</epp>Some registries require the use of an EPP token either for all domain registrations or a selection of domain registrations.
domain:renew command
We recommend the usage of the EPP Fee extension as part of the domain:renew command whether a registry supports non-standard pricing or not as it will allow you to track your available balance and credit limit.
In order to renew a domain, a registrar’s system must include the domain, the expiry date from which that renewal should be started and the period for which it should be renewed in the EPP command. Note the expiry date in this scenario may be one of two options:
- the current expiry returned by the EPP info command and shown on RDAP; or
- if the domain is in the auto-renew period you can choose to use the previous expiry date to back-date the transaction. (If a registrar’s accreditation is set to auto-delete if a domain is not renewed within the auto-renew grace period, this feature can be utilised to have a resulting one year renewal.)
An example renewal command:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<renew>
<domain:renew 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>example.co.uk</domain:name>
<domain:curExpDate>2026-07-03</domain:curExpDate>
<domain:period unit="y">1</domain:period>
</domain:renew>
</renew>
<extension>
<fee:renew xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:fee>3.90</fee:fee>
</fee:renew>
</extension>
<clTRID>EXAMPLE-renew-12345</clTRID>
</command>
</epp>An example renewal response to a command using the fee extension returns a confirmation of the fee, the balance and the credit limit. Note that your balance will be negative if you are using a line of credit available to you:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:renData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
<domain:exDate>2027-07-03T12:42:39.420Z</domain:exDate>
</domain:renData>
</resData>
<extension>
<fee:renData xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:fee description="Renewal Fee">3.90</fee:fee>
<fee:balance>-40026.54</fee:balance>
<fee:creditLimit>70000.00</fee:creditLimit>
</fee:renData>
</extension>
<trID>
<clTRID>EXAMPLE-renew-12345</clTRID>
<svTRID>1859504346769660605</svTRID>
</trID>
</response>
</epp>domain:unrenew command
Some registries support the unrenew command, if policy allows, whilst the domain is in the RFC3915 renewPeriod, in order to cancel any renewal request. This enables the cancellation of a manual renewal without requiring the deletion of the domain.
An example unrenew command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<update>
<u:unrenew xmlns:u="http://www.nominet.org.uk/epp/xml/std-unrenew-1.0" xsi:schemaLocation="http://www.nominet.org.uk/epp/xml/std-unrenew-1.0 std-unrenew-1.0.xsd">
<u:domainName>example.co.uk</u:domainName>
</u:unrenew>
</update>
<clTRID>EXAMPLE-UNRENEW-12345</clTRID>
</command>
</epp>An example un-renew response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:renData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
<domain:exDate>2027-07-07T15:32:01.680Z</domain:exDate>
</domain:renData>
</resData>
<trID>
<clTRID>EXAMPLE-UNRENEW-12345</clTRID>
<svTRID>1860979786382318513</svTRID>
</trID>
</response>
</epp>domain:info command
A registrar can utilise domain:info on any domain in the registry, but the level of information it returns will be dependant on whether they care the current sponsoring registrar or not.
An example domain info command:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">example.co.uk</domain:name>
</domain:info>
</info>
<clTRID>EXAMPLE-DOMAIN-INFO-12345</clTRID>
</command>
</epp>An example response for a Sponsoring registrar, showing a domain in an RGP period:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
<domain:roid>D41338932-UK</domain:roid>
<domain:status s="inactive"/>
<domain:registrant>AT200525</domain:registrant>
<domain:clID>REGISTRAR1</domain:clID>
<domain:crID>REGISTRAR1</domain:crID>
<domain:crDate>2025-05-20T22:31:57.343Z</domain:crDate>
<domain:exDate>2026-05-20T22:31:57.343Z</domain:exDate>
</domain:infData>
</resData>
<extension>
<rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsd">
<rgp:rgpStatus s="addPeriod"/>
</rgp:infData>
</extension>
<trID>
<clTRID>EXAMPLE-DOMAIN-INFO-12345</clTRID>
<svTRID>1843688108600595389</svTRID>
</trID>
</response>
</epp>An example response for the same domain requested by a non-sponsoring registrar:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
<domain:roid>D41338932-UK</domain:roid>
<domain:status s="inactive"/>
<domain:clID>REGISTRAR1</domain:clID>
<domain:crID>REGISTRAR1</domain:crID>
<domain:crDate>2025-05-20T22:31:57.343Z</domain:crDate>
<domain:exDate>2026-05-20T22:31:57.343Z</domain:exDate>
</domain:infData>
</resData>
<extension>
<rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsd">
<rgp:rgpStatus s="addPeriod"/>
</rgp:infData>
</extension>
<trID>
<clTRID>EXAMPLE-DOMAIN-INFO-12345</clTRID>
<svTRID>1843688108600595389</svTRID>
</trID>
</response>
</epp>domain:update command
A domain update command remove a lock to allow a transfer:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<update>
<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>example.co.uk</domain:name>
<domain:rem>
<domain:status s="clientTransferProhibited"/>
</domain:rem>
</domain:update>
</update>
<clTRID>DOMAIN-UPDATE-1234</clTRID>
</command>
</epp>An example response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<trID>
<clTRID>DOMAIN-UPDATE-1234</clTRID>
<svTRID>1861639945723058063</svTRID>
</trID>
</response>
</epp>Domain:Update set Transfer Authorisation code.
There are two different implementation for transfer authorisation codes (TACs) on the platform:
- Registries which require secure auth codes also implement a maximum 15-day time-to-live from the time a TAC is set.
- All other registries allow for the permanent setting of TACs.
An example update to set the Transfer authorisation code for either type on a domain is:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<update>
<domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
<domain:chg>
<domain:authInfo>
<domain:pw>5d41402abc4b2a76b9719d911017c592</domain:pw>
</domain:authInfo>
</domain:chg>
</domain:update>
</update>
<clTRID>SET-TAC-12345</clTRID>
</command>
</epp>And the example response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<trID>
<clTRID>SET-TAC-12345</clTRID>
<svTRID>1860968585019530753</svTRID>
</trID>
</response>
</epp>Domain:update DS record
A domain update command to add a delegation signer (DS) record for a domain:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<update>
<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>example.co.uk</domain:name>
</domain:update>
</update>
<extension>
<secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.1.xsd">
<secDNS:add>
<secDNS:dsData>
<secDNS:keyTag>2563</secDNS:keyTag>
<secDNS:alg>13</secDNS:alg>
<secDNS:digestType>2</secDNS:digestType> <secDNS:digest>85886ABA8D15D28804ACDB6A4DFDAE5CF93107299D494BA05E5A1DACB2AB8824</secDNS:digest>
</secDNS:dsData>
</secDNS:add>
</secDNS:update>
</extension>
<clTRID>DNSSEC-UPDATE-1234</clTRID>
</command>
</epp>The example response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<trID>
<clTRID>DNSSEC-UPDATE-1234</clTRID>
<svTRID>1860966971244288327</svTRID>
</trID>
</response>
</epp>Restore command
The restore process is an extension to the EPP update command.
A domain that is within its redemptionPeriod can be restored if it is still required by the original registrant. There are two operational implementations available to a registry on the Nominet Dragon platform, unless documented in the registry information the ‘Standard’ approach applies:
- Standard – which requires the submission of a restore request followed by a restore report.
- Simplified – which only requires a restore request.
It is important to note that restoring a domain that any transactions that were cancelled at the time of delete will also be restored as if the domain delete request had not been received.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd">
<command>
<update>
<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>example.co.uk</domain:name>
</domain:update>
</update>
<extension>
<rgp:update xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
rgp-1.0.xsd">
<rgp:restore op="request"/>
</rgp:update>
</extension>
<clTRID>EXAMPLE-RESTORE-12345</clTRID>
</command>
</epp>An example response on a simplified restore process, which results in the domain being fully restored:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<trID>
<clTRID>EXAMPLE-RESTORE-12345</clTRID>
<svTRID>1861333742828658526</svTRID>
</trID>
</response>
</epp>An example response response on a standard restore, taking the domain to pendingRestore status:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<extension>
<rgp:upData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsd">
<rgp:rgpStatus s="pendingRestore"/>
</rgp:upData>
</extension>
<trID>
<clTRID>EXAMPLE-RESTORE-12345</clTRID>
<svTRID>1860988484597060425</svTRID>
</trID>
</response>
</epp>domain:transfer command
If a domain has clientTransferProhibited or serverTransferProhibited requesting a transfer will result in an error.
A domain transfer command is submitted by the gaining registrar; to prepare for a transfer the losing registrar must both unlock the domain to allow it to transfer and set the Transfer Authorisation Code (TAC) via a domain:update command.
There are various potential transfer process configurations for registries on the Nominet Dragon platform:
- Transfer speed
- Standard transfer – on receipt of a transfer request the result code provided is 1001, the domain enters a pendingTransfer period in which the losing registrar can either accept or reject the request. If no response is provided in a defined time period the request is then auto-accepted or auto-rejected. (Current ICANN policies mean that gTLDs follow the standard transfer process.)
- Rapid transfer – on receipt of a transfer request the result code provided is 1000 and the domain transfer is completed instantly. We only operate Rapid Transfer in registries which are not subject to policies which would prohibit it. All Rapid transfer registries mandate compliance with RFC9154 – Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer.
- A registry has a default transfer period of either 0-year or 1-year annual increment on expiry date on completion of a transfer. If a transfer request is submitted without a period stated the default for the registry will apply.
Note for domains which are in the auto-renew grace period:
- they cannot be transferred without a requesting a renewal as part of the transfer; and
- the auto-renew will be credited and not charged to the losing registrar if the transfer completes before the end of the auto-renew grace period. The gaining registrar will instead be charged the requested increment. A default transfer of 0-year increment will fail.
We recommend the usage of the EPP Fee extension as part of your transfer command to ensure an understanding of the cost to your account at the time of the operation.
An example transfer request with a 1 year renewal (to use the default period remove the line with domain:period) :
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<command>
<transfer op="request">
<domain:transfer 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>example.co.uk</domain:name>
<domain:period unit="y">1</domain:period>
<domain:authInfo>
<domain:pw>5d41402abc4b2a76b9719d911017c592</domain:pw>
</domain:authInfo>
</domain:transfer>
</transfer>
<extension>
<fee:transfer xmlns:fee="urn:ietf:params:xml:ns:fee-0.23"
xsi:schemaLocation="urn:ietf:params:xml:ns:fee-0.23 fee-0.23.xsd">
<fee:currency>GBP</fee:currency>
<fee:fee>3.90</fee:fee>
</fee:transfer>
</extension>
<trID>
<clTRID>EXAMPLE-transfer-12345</clTRID>
</trID>
</command>
</epp>An example transfer response, in the scenario of an instant rapid transfer:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.co.uk</domain:name>
<domain:trStatus>serverApproved</domain:trStatus>
<domain:reID>REGISTRAR1</domain:reID>
<domain:reDate>2025-07-07T16:52:18.372Z</domain:reDate>
<domain:acID>REGISTRAR2</domain:acID>
<domain:acDate>2025-07-07T16:52:18.372Z</domain:acDate>
<domain:exDate>2028-07-07T15:00:35.433Z</domain:exDate>
</domain:trnData>
</resData>
<extension>
<fee:trnData xmlns:fee="urn:ietf:params:xml:ns:fee-0.23">
<fee:currency>GBP</fee:currency>
<fee:fee description="Transfer Fee">3.90</fee:fee>
<fee:balance>-22934.82</fee:balance>
<fee:creditLimit>70000.00</fee:creditLimit>
</fee:trnData>
</extension>
<trID>
<clTRID>EXAMPLE-transfer-12345</clTRID>
<svTRID>1860992712648433338</svTRID>
</trID>
</response>
</epp>An example transfer response for a standard transfer:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1001">
<msg>Command completed successfully; action pending</msg>
</result>
<resData>
<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.wales</domain:name>
<domain:trStatus>pending</domain:trStatus>
<domain:reID>REGISTRAR1</domain:reID>
<domain:reDate>2025-07-09T12:02:59.877Z</domain:reDate>
<domain:acID>REGISTRAR2</domain:acID>
<domain:acDate>2025-07-14T12:02:59.877Z</domain:acDate>
<domain:exDate>2027-06-04T19:12:38.663Z</domain:exDate>
</domain:trnData>
</resData>
<trID>
<clTRID>EXAMPLE-transfer-12345</clTRID>
<svTRID>1861644681960494004</svTRID>
</trID>
</response>
</epp>domain:delete command
If a domain has clientDeleteProhibited or serverDeleteProhibited requesting a domain:delete will result in an error.
A registrar can, on the request of a registrant, cancel the contract for a domain through the submission a domain:delete command. On receipt of a delete the domain will enter an RFC5731 pending delete status and an RFC3915 redemption period as required by the registry’s policy unless it was in the RGP3915 addPeriod at the time of the delete command, in which case it will drop and be available for re-registration immediately.
An example domain:delete command:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<delete>
<domain:delete xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>tiamat.co.uk</domain:name>
</domain:delete>
</delete>
<clTRID>EXAMPLE-DELETE-12345</clTRID>
</command>
</epp>DNSSEC Delegation Signer (DS) records
We support RFC5910 to set Delegation Signer records in all registries we operate.
- We support a maximum of 8 Delegation Signer (DS) records per domain.
- The following Algorithm’s are supported:
- DSA
- RSASHA1
- DSA-NSEC3-SHA1
- RSASHA1-NSEC3-SHA1
- RSASHA256
- RSASHA512
- ECC-GOST
- ECDSA Curve P-256 with SHA-256
- ECDSA Curve P-384 with SHA-384
- Ed25519
- ED448
- The following digests are supported:
- SHA-1
- SHA-256
- SHA-384
- We do not support the setting of maxSigLife.
The Nominet DNSSEC Practice Statement is published here.
RFC3915 – RGP status Errata
Please note an errata was issued to RFC3915 on 2025-03-28. Our systems at this point in time have not been updated to take that errata into account.
Minerva House, Edmund Halley Road, Oxford Science Park, OX4 4DQ, United Kingdom