Відмінності між версіями «EPP (en)»

Версія за 11:02, 6 травня 2025

https://wiki.drs.ua/EPP Українська версія]

EPP (Extensible Provisioning Protocol, RFC-5730) is a protocol used for interaction between a domain registry and domain registrars. The DRS EPP server enables the registration, viewing, modification, renewal, transfer, and restoration of domains (RFC-5731), as well as registration, viewing, and modification of contacts using CUNIC (RFC-5733).

Data exchange between client and server software is described in RFC-5734 and occurs in the form of data packets. Each packet consists of 4 bytes indicating the total length of the packet (body length + 4) and the command data.

Session initialization and termination

A session is initiated with the <login> command. This command must always be executed upon connection to the server, before any domain or contact operations.

To end the session and disconnect from the server, the <logout> command must be executed. This should always be done before disconnecting to avoid exceeding the limit of simultaneously open sessions. No more than three sessions may be open concurrently.

Domain contacts

A domain name typically includes four types of contacts: the domain owner (registrant), administrative (admin), technical (tech), and billing contacts. This applies to the majority of international domains (gTLD) as well as domains like biz.ua, co.ua, and pp.ua. Most Ukrainian regional domains use three contact types (registrant, admin, and tech), and some even fewer.

Each contact type has a specific function: Registrant — the domain owner; Admin — manages domain-related tasks and provides confirmations for domain operations; Billing and Tech contacts — handle financial and technical aspects respectively.

Main command types

• For the domain object, the following commands can be executed:

CREATE – register a new object
UPDATE – modify object properties
RENEW – extend the lifetime of the object
TRANSFER – change the registrar managing the object
RESTORE – restore the object
DELETE – delete the object

• For the contact object, the following commands are available:

CREATE – register a new object
UPDATE – modify object properties

Balance

To retrieve the registrar’s current balance, use the command <balance:info>.

Example:

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<balance:info xmlns:balance="http://www.verisign.com/epp/balance-1.0" />
</info>
<clTRID>XXXXX-YYYYY-0000000</clTRID>
</command>
</epp>

Command execution result

Each command sent to the server may require a different amount of time to execute. However, according to the standard, the server must respond within a certain timeframe. Otherwise, the command is considered not accepted. Therefore, results may be "instantaneous" or "delayed".

If an object is already awaiting the execution of a delayed command, any new requests for that object will be rejected until the prior command is completed.

Message queue

The results of delayed commands eventually become available. To notify the registrar, a personal message queue is used. Additionally, the DRS EPP server sends various notifications to registrars, such as domain deletions.

To receive these messages and results of delayed commands, use the <poll> command, and don't forget to mark messages as read.

drs:notify messages

These messages notify the registrar about events. The event type is specified in the drs:type element:

domainActivated – the pp.ua domain was activated via SMS code domainHeld – the domain was not renewed and was suspended based on its expiration domainPendingToDelete – the domain entered the deletion stage (for domains that use a 5-day random deletion schedule) domainCancelled – the biz.ua, co.ua, pp.ua domain was cancelled domainDeleted – the domain was deleted from the DRS database for other registries

Example:

<?xml version="1.0" encoding="UTF-8"?>
<drs:notify xmlns:drs="http://drs.ua/epp/drs-1.0" xsi:schemaLocation="drs-1.0.xsd">
	<drs:type>domainPendingToDelete</drs:type>
	<drs:object>test.pp.ua</drs:object>
	<drs:message>Domain test.pp.ua has been pending to delete</drs:message>
</drs:notify>

XML examples

To avoid redundancy, we recommend referring directly to the original RFC documents (RFC-5730, RFC-5731, RFC-5733, RFC-5734) for XML code examples and detailed explanations. The original source is always better than any secondary resource.

Troubleshooting

If you have reviewed the RFC documents, followed all steps correctly, and still experience issues, please send us as much information as possible at support@drs.ua. We will do our best to help identify and resolve the issue.