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

Версія за 18:37, 19 жовтня 2022

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 – зміна властивостей об'єкта

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

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

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

Результат обробки відкладених команд рано чи пізно стане відомим, тому для оповіщення реєстратора використовується особиста черга повідомлень реєстратора. Також 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 і ми обов'язково постараємося допомогти вам визначити проблему та вирішити її.