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

Матеріал з DRS wiki
Перейти до: навігація, пошук
(Новая страница: «<br/> {| align="left" class="wikitable" width="35%" style="float:right; margin-left:2em" |- ! style="background:#AFD6FF;" | Характеристики ! style=…»)
 
(→‎Результат виконання команди)
 
(не показано одну проміжну версію цього учасника)
Рядок 1: Рядок 1:
−
<br/>
+
[[Файл:Epp.png|center]]
 +
 
  
 
{| align="left" class="wikitable" width="35%" style="float:right; margin-left:2em"
 
{| align="left" class="wikitable" width="35%" style="float:right; margin-left:2em"
 
|-
 
|-
−
! style="background:#AFD6FF;" | Характеристики
+
! style="background:#AFD6FF;" | Документація
−
! style="background:#AFD6FF;" | Описание
+
! style="background:#AFD6FF;" | Посилання
 
|-
 
|-
−
|'''Домен содержит'''  
+
|'''Extensible Provisioning Protocol (EPP)'''  
−
| буквы латинского алфавита (a-z), цифры (0-9), дефис («-»)
+
|[https://tools.ietf.org/html/rfc5730 RFC-5730]
 
|-
 
|-
−
|'''Длина домена'''
+
|'''EPP Domain Name Mapping'''
−
|от 2 до 63 символов
+
|[https://tools.ietf.org/html/rfc5731 RFC-5731]
 
|-
 
|-
−
|'''«-»'''  
+
|'''EPP Contact Mapping'''  
−
|не может начинаться или заканчиваться дефисом, содержать два дефиса подряд
+
|[https://tools.ietf.org/html/rfc5733 RFC-5733]
 
|-
 
|-
−
|'''IDN'''
+
|'''EPP Transport over TCP'''  
−
| нет
+
|[https://tools.ietf.org/html/rfc5734 RFC-5734]
−
|-
+
−
|'''Auth-code'''
+
−
| нет
+
−
|-
+
−
|'''Nic-handle'''
+
−
| [[CUNIC]]
+
−
|-
+
−
|'''Поддерживается интерфейсом'''
+
−
| EPP
+
−
|-
+
−
|'''Правила'''
+
−
| http://..
+
−
|-
+
−
|'''Политика регистрации'''
+
−
| http://...
+
−
|-
+
−
|'''Технический администратор'''
+
−
| ...
+
 
|}
 
|}
  
−
'''EPP''' — протокол ....
+
'''EPP''' (Extensible Provisioning Protocol, RFC-5730) – це протокол взаємодії реєстру доменної зони та реєстраторів доменів. EPP-сервер DRS дозволяє здійснювати реєстрацію, перегляд, зміну, продовження, трансфер та відновлення доменів ([https://tools.ietf.org/html/rfc5731 RFC-5731]), а також реєстрацію, перегляд та зміну контактів [[CUNIC]] ([https://tools.ietf.org/html/rfc5733 RFC-5733]).
 +
 
 +
Обмін даними між клієнтськими та серверними програмами описаний у документі [https://tools.ietf.org/html/rfc5734 RFC-5734] і подається у вигляді пакетів даних. Кожен пакет даних складається з 4 байт, що містять довжину всього пакета (довжина тіла пакета + 4) та даних команди.
 +
 
 +
=== Початок та кінець сесії ===
 +
Сесія ініціалізується командою <login>, ця команда завжди виконується при підключенні до сервера перед виконанням будь-яких операцій із доменами та контактами.
 +
 
 +
Для завершення сесії перед відключенням від сервера необхідно виконати команду <logout>, яка повинна виконуватися завжди перед відключенням від сервера, щоб уникнути перевищення ліміту одночасно відкритих сесій. Тобто не більше трьох одночасних сесій.
 +
 
 +
=== Контакти доменів ===
 +
У доменного імені, як правило, має бути 4 типи контактів: контакт власника домену (registrant), адміністративний (admin), технічний (tech) та фінансовий (billing) контакти. Це стосується переважної більшості міжнародних доменів та доменів biz.ua, co.ua, pp.ua. Більшість українських регіональних доменів використовують три типи контактів (registrant, admin та tech), а деякі навіть ще менше.
 +
 
 +
Кожен тип контакту несе у собі функціональне навантаження — особа, зазначене у тому чи іншому типі контактів виконує певні функції. Реєстрант — це власник, адміністратор займається питаннями управління доменом, дає різні підтвердження при виконанні операцій над доменами. Відповідно фінансовий та технічний контакти виконують фінансові та технічні функції.
 +
 
 +
=== Основні типи команд ===
 +
*  З об'єктом domain можна виконувати наступні команди:
 +
 
 +
CREATE – реєстрація нового об'єкта
 +
<br>UPDATE – зміна властивостей об'єкта
 +
<br>RENEW – збільшення часу життя об'єкта
 +
<br>TRANSFER – зміна реєстратора що обслуговує об'єкт
 +
<br>RESTORE – відновлення об'єкта
 +
<br>DELETE – видалення об'єкта
 +
 
 +
*    З об'єктом [https://wiki.drs.ua/CUNIC contact] можна виконувати такі команди:
 +
 
 +
CREATE – реєстрація нового об'єкта
 +
<br>UPDATE – зміна властивостей об'єкта
 +
 
 +
==== Balance ====
 +
Для отримання поточного балансу реєстратора необхідно виконати команду <code><balance:info></code>.
 +
 
 +
''Приклад:''
 +
 
 +
<syntaxhighlight lang="xml" enclose="pre">
 +
<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>
 +
</syntaxhighlight>
 +
 
 +
=== Результат виконання команди ===
 +
Кожна з відправлених на сервер команд може вимагати для виконання різну кількість часу, але за стандартом сервер зобов'язаний відповісти клієнту у певний проміжок часу, інакше команда не буде вважатися прийнятою. Тому результат виконання може бути "миттєвий" або "відкладений".
 +
Якщо об'єкт вже очікує виконання відкладеної команди, то до її завершення усі нові запити до сервера для цього об'єкта будуть відхилятись.
  
 +
=== Черга повідомлень ===
 +
Результат обробки відкладених команд рано чи пізно стане відомим, тому для оповіщення реєстратора використовується особиста черга повідомлень реєстратора. Також EPP сервер DRS надсилає кожному з реєстраторів різні повідомлення, наприклад, про видалення домену.
  
−
=== Меню 3 ===
+
Для отримання повідомлень та результатів відкладених команд використовуйте команду [https://tools.ietf.org/html/rfc5730#section-2.9.2.3 <poll>] і не забувайте відзначати повідомлення як прочитані.
  
−
=== Меню 4 ===
+
=== Повідомлення drs:notify ===
 +
Це повідомлення використовується для сповіщення реєстратора про події. Тип події вказується в елементі drs:type:
  
−
=== Меню 5 ===
+
domainActivated — домен pp.ua активований кодом з sms
−
... <ref> тут сноска </ref>:
+
domainHeld — домен не був продовжений та заблокований згідно з терміном дії
 +
domainPendingToDelete — домен перейшов у стадію видалення (для доменів, які використовують термінацію за схемою випадкового видалення протягом 5 діб)
 +
domainCancelled — домен biz.ua, co.ua, pp.ua видалено
 +
domainDeleted — домен видалений з бази даних DRS для доменів інших реєстрів
  
−
== Примечания ==
+
''Наприклад:''
 +
<syntaxhighlight lang="xml" enclose="pre">
 +
<?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>
 +
</syntaxhighlight>
  
−
<font color=red>Обратите внимание!</font> ...
+
=== Приклади XML ===
 +
Ми не будемо зайвий раз дублювати інформацію, першоджерело завжди краще за будь-який підручник, тому приклади XML коду і докладний опис ми рекомендуємо брати безпосередньо з документів RFC-5730, RFC-5731, RFC-5733, RFC-5734.
  
−
<references/>
+
=== Вирішення проблем ===
 +
Якщо ви вивчили документи RFC, все зробили правильно, але з якоїсь причини відчуваєте труднощі — будь ласка, повідомте якомога більше даних нам за адресою support@drs.ua і ми обов'язково постараємося допомогти вам визначити проблему та вирішити її.

Поточна версія на 11:43, 19 листопада 2024

Epp.png


Документація Посилання
Extensible Provisioning Protocol (EPP) RFC-5730
EPP Domain Name Mapping RFC-5731
EPP Contact Mapping RFC-5733
EPP Transport over TCP RFC-5734

EPP (Extensible Provisioning Protocol, RFC-5730) – це протокол взаємодії реєстру доменної зони та реєстраторів доменів. EPP-сервер DRS дозволяє здійснювати реєстрацію, перегляд, зміну, продовження, трансфер та відновлення доменів (RFC-5731), а також реєстрацію, перегляд та зміну контактів CUNIC (RFC-5733).

Обмін даними між клієнтськими та серверними програмами описаний у документі RFC-5734 і подається у вигляді пакетів даних. Кожен пакет даних складається з 4 байт, що містять довжину всього пакета (довжина тіла пакета + 4) та даних команди.

Початок та кінець сесії

Сесія ініціалізується командою <login>, ця команда завжди виконується при підключенні до сервера перед виконанням будь-яких операцій із доменами та контактами.

Для завершення сесії перед відключенням від сервера необхідно виконати команду <logout>, яка повинна виконуватися завжди перед відключенням від сервера, щоб уникнути перевищення ліміту одночасно відкритих сесій. Тобто не більше трьох одночасних сесій.

Контакти доменів

У доменного імені, як правило, має бути 4 типи контактів: контакт власника домену (registrant), адміністративний (admin), технічний (tech) та фінансовий (billing) контакти. Це стосується переважної більшості міжнародних доменів та доменів biz.ua, co.ua, pp.ua. Більшість українських регіональних доменів використовують три типи контактів (registrant, admin та tech), а деякі навіть ще менше.

Кожен тип контакту несе у собі функціональне навантаження — особа, зазначене у тому чи іншому типі контактів виконує певні функції. Реєстрант — це власник, адміністратор займається питаннями управління доменом, дає різні підтвердження при виконанні операцій над доменами. Відповідно фінансовий та технічний контакти виконують фінансові та технічні функції.

Основні типи команд

  • З об'єктом domain можна виконувати наступні команди:

CREATE – реєстрація нового об'єкта
UPDATE – зміна властивостей об'єкта
RENEW – збільшення часу життя об'єкта
TRANSFER – зміна реєстратора що обслуговує об'єкт
RESTORE – відновлення об'єкта
DELETE – видалення об'єкта

  • З об'єктом contact можна виконувати такі команди:

CREATE – реєстрація нового об'єкта
UPDATE – зміна властивостей об'єкта

Balance

Для отримання поточного балансу реєстратора необхідно виконати команду <balance:info>.

Приклад: 

<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>

Результат виконання команди

Кожна з відправлених на сервер команд може вимагати для виконання різну кількість часу, але за стандартом сервер зобов'язаний відповісти клієнту у певний проміжок часу, інакше команда не буде вважатися прийнятою. Тому результат виконання може бути "миттєвий" або "відкладений". Якщо об'єкт вже очікує виконання відкладеної команди, то до її завершення усі нові запити до сервера для цього об'єкта будуть відхилятись.

Черга повідомлень

Результат обробки відкладених команд рано чи пізно стане відомим, тому для оповіщення реєстратора використовується особиста черга повідомлень реєстратора. Також EPP сервер DRS надсилає кожному з реєстраторів різні повідомлення, наприклад, про видалення домену.

Для отримання повідомлень та результатів відкладених команд використовуйте команду <poll> і не забувайте відзначати повідомлення як прочитані.

Повідомлення drs:notify

Це повідомлення використовується для сповіщення реєстратора про події. Тип події вказується в елементі drs:type:

domainActivated — домен pp.ua активований кодом з sms domainHeld — домен не був продовжений та заблокований згідно з терміном дії domainPendingToDelete — домен перейшов у стадію видалення (для доменів, які використовують термінацію за схемою випадкового видалення протягом 5 діб) domainCancelled — домен biz.ua, co.ua, pp.ua видалено domainDeleted — домен видалений з бази даних DRS для доменів інших реєстрів

Наприклад: 

<?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

Ми не будемо зайвий раз дублювати інформацію, першоджерело завжди краще за будь-який підручник, тому приклади XML коду і докладний опис ми рекомендуємо брати безпосередньо з документів RFC-5730, RFC-5731, RFC-5733, RFC-5734.

Вирішення проблем

Якщо ви вивчили документи RFC, все зробили правильно, але з якоїсь причини відчуваєте труднощі — будь ласка, повідомте якомога більше даних нам за адресою support@drs.ua і ми обов'язково постараємося допомогти вам визначити проблему та вирішити її.

Отримано з https://wiki.drs.ua/index.php?title=EPP&oldid=1652