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

Матеріал з DRS wiki
Перейти до: навігація, пошук
(Результат виконання команди)
 
(не показано 8 проміжних версій цього учасника)
Рядок 32: Рядок 32:
 
У доменного імені, як правило, має бути 4 типи контактів: контакт власника домену (registrant), адміністративний (admin), технічний (tech) та фінансовий (billing) контакти. Це стосується переважної більшості міжнародних доменів та доменів biz.ua, co.ua, pp.ua. Більшість українських регіональних доменів використовують три типи контактів (registrant, admin та tech), а деякі навіть ще менше.
 
У доменного імені, як правило, має бути 4 типи контактів: контакт власника домену (registrant), адміністративний (admin), технічний (tech) та фінансовий (billing) контакти. Це стосується переважної більшості міжнародних доменів та доменів biz.ua, co.ua, pp.ua. Більшість українських регіональних доменів використовують три типи контактів (registrant, admin та tech), а деякі навіть ще менше.
  
Кожен тип контакту несе у собі функціональне навантаження — особа, зазначене у тому чи іншому типі контактів виконує певні функції. Реєстрант - це власник, адміністратор займається питаннями управління доменом, дає різні підтвердження при виконанні операцій над доменами. Відповідно фінансовий та технічний контакти виконують фінансові та технічні функції.
+
Кожен тип контакту несе у собі функціональне навантаження — особа, зазначене у тому чи іншому типі контактів виконує певні функції. Реєстрант це власник, адміністратор займається питаннями управління доменом, дає різні підтвердження при виконанні операцій над доменами. Відповідно фінансовий та технічний контакти виконують фінансові та технічні функції.
  
 
=== Основні типи команд ===
 
=== Основні типи команд ===
 
*  З об'єктом domain можна виконувати наступні команди:
 
*  З об'єктом domain можна виконувати наступні команди:
  
CREATE - реєстрація нового об'єкта
+
CREATE реєстрація нового об'єкта
UPDATE – зміна властивостей об'єкта
+
<br>UPDATE – зміна властивостей об'єкта
RENEW - збільшення часу життя об'єкта
+
<br>RENEW збільшення часу життя об'єкта
TRANSFER - зміна обслуговуючого реєстратора об'єкта
+
<br>TRANSFER зміна реєстратора що обслуговує об'єкт
RESTORE – відновлення об'єкта
+
<br>RESTORE – відновлення об'єкта
DELETE – видалення об'єкта
+
<br>DELETE – видалення об'єкта
  
 
*    З об'єктом [https://wiki.drs.ua/CUNIC contact] можна виконувати такі команди:
 
*    З об'єктом [https://wiki.drs.ua/CUNIC contact] можна виконувати такі команди:
  
CREATE - реєстрація нового об'єкта
+
CREATE реєстрація нового об'єкта
UPDATE – зміна властивостей об'єкта
+
<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>
  
 
=== Результат виконання команди ===  
 
=== Результат виконання команди ===  
Кожна з відправлених на сервер команд може вимагати для виконання різну кількість часу, але за стандартом сервер зобов'язаний відповісти клієнту в строго певний проміжок часу, інакше команда не буде вважатися прийнятою. Тому результат виконання може бути "миттєвий" або "відкладений".
+
Кожна з відправлених на сервер команд може вимагати для виконання різну кількість часу, але за стандартом сервер зобов'язаний відповісти клієнту у певний проміжок часу, інакше команда не буде вважатися прийнятою. Тому результат виконання може бути "миттєвий" або "відкладений".
Якщо об'єкт вже очікує виконання відкладенної команди, то до її завершеня усі нові запити до серверу для цього об'єкта будуть відхилятись.
+
Якщо об'єкт вже очікує виконання відкладеної команди, то до її завершення усі нові запити до сервера для цього об'єкта будуть відхилятись.
  
 
=== Черга повідомлень ===
 
=== Черга повідомлень ===
Рядок 81: Рядок 97:
  
 
=== Вирішення проблем ===
 
=== Вирішення проблем ===
Якщо ви вивчили документи RFC, все зробили правильно, але з якоїсь причини відчуваєте труднощі - будь ласка, повідомте якомога більше даних нам за адресою support@drs.ua і ми обов'язково постараємося допомогти вам визначити проблему та вирішити її.
+
Якщо ви вивчили документи 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 і ми обов'язково постараємося допомогти вам визначити проблему та вирішити її.