Jump to content

Расширяемый протокол обеспечения

Расширяемый протокол обеспечения
Протокол связи
Аббревиатура ЕПП
Цель Автоматизированные транзакции с доменными именами, такие как регистрация и продление
Разработчик(и) Скотт Холленбек, Рабочая группа по разработке Интернета (IETF)
Введение 2009 год ; 15 лет назад ( 2009 )
Уровень OSI Прикладной уровень
Порт(ы) 700
RFC(ы) RFC   5730 , 5731 , 5732 , 5733 , 5734

Extensible Provisioning Protocol ( EPP ) — это гибкий протокол, предназначенный для размещения объектов внутри реестров через Интернет . Мотивом создания EPP было создание надежного и гибкого протокола, который мог бы обеспечить связь между реестрами доменных имен и регистраторами доменных имен . Эти транзакции необходимы всякий раз, когда доменное имя регистрируется или продлевается, что также предотвращает захват домена . До его внедрения у реестров не было единого подхода, и существовало множество различных собственных интерфейсов. Хотя его использование для доменных имен было первоначальным стимулом, протокол разработан так, чтобы его можно было использовать в любой системе заказов и выполнения. [ 1 ]

EPP основан на XML – структурированном текстовом формате. Базовый сетевой транспорт не фиксирован, хотя в настоящее время указан единственный метод — через TCP . Протокол был разработан с учетом гибкости, позволяющей использовать другие транспортные средства, такие как BEEP , SMTP , SOAP или HTTPS . [ 1 ] Однако некоторое распространение получил только HTTPS, тогда как подавляющее большинство использует TCP.

Первые проекты протоколов были опубликованы черновых документов IETF в качестве индивидуальных в Интернете Скоттом Холленбеком из Verisign в ноябре 2000 года. [ 2 ] Индивидуальные документы для подачи были приняты IETF Provisioning Registry ( provreg ) рабочей группой , которая была создана после BoF на IETF-49 в декабре 2000 года. проведения сессии [ 3 ] Предлагаемые стандартные документы (RFC 3730–3734) были опубликованы редактором RFC в марте 2004 г. [ 4 ] Проекты стандартных документов (RFC 4930–4934) были опубликованы в мае 2007 года. [ 5 ]

В августе 2009 года IETF предоставил EPP статус полного стандарта STD 69. [ 6 ]

Первым расширением EPP, которое стало предложенным стандартом, было продление льготного периода погашения из RFC 3915 в сентябре 2004 года. [ 7 ] С тех пор последовал ряд различных предложенных стандартных расширений. [ 8 ]

Принятие

[ редактировать ]

Протокол был принят рядом реестров доменных имен ccTLD, таких как: .ac , .ag , .ai , .as , .ar , .at , .au , .be , .br , .bz , .ca , .cat , .cc , .ch , .cl , .cn , .co , .cr , .cx , .cz , .dk , .dm , .ee , .es (через HTTPS), .eu , .fi , .fm , .fr , .gg , .gr (через HTTPS), .gs , .hn , .ht , .il , .im , .in , .io , .it (через HTTPS), .je , .ke , .ki , .ky , .kz , .la , .lc , .li , .lt , .lu , .lv , .md , .me , .mk , .mn , .ms , .mu , . mx , .na , .nf , .ng , .nl , .no , .nu , .nz , .pe , .pk , .pl (через HTTPS), .ps , .pt , .ru , .ro , .sc , .se , .sh , .si , .su , .tl , .tm .tv , .tw , .ua , .uk , .us , .vc , .ve ​​и .za, а также реестры ENUM , например те, которые используют коды стран +31, +41, +43, +44 и +48. [ 9 ]

ICANN включила в свой базовый договор о реестре условие предоставления услуги EPP, поэтому каждый gTLD принял этот протокол. [ 10 ]

Существует множество с открытым исходным кодом реализаций серверного программного обеспечения EPP . Совет администраторов национальных кодов (CoCCA) поддерживает серверное программное обеспечение EPP, которое используется примерно 59 ccTLD и 6 gTLD. [ 11 ] Еще одно программное обеспечение с открытым исходным кодом — FRED (поддерживается CZ.NIC ), пользователями которого являются 11 ccTLD. [ 12 ]

Команды протокола

[ редактировать ]

Существует 3 класса команд: управление сеансом, запрос и преобразование объекта. Эти команды затем можно сопоставить с объектами, что более точно определяет их точную функциональность. [ 1 ] Наиболее распространенными стандартизированными объектами являются хосты, [ 13 ] контакты [ 14 ] и домены. [ 15 ] Существуют также другие стандартизированные объекты, такие как организации, [ 16 ] однако они используются редко.

Когда клиент подключается к серверу, сервер немедленно отправляет клиенту «приветственное» сообщение. Это сообщение содержит информацию о сервере, к которому необходимо подключиться клиенту. Он содержит имя сервера, текущую дату и время сервера в формате UTC, поддерживаемые функции и политику конфиденциальности. Поддерживаемые функции включают версии EPP, языки, объекты и расширения. [ 1 ]

Команды управления сеансом: [ 1 ]

Команда Использование
привет Запросите еще один ответ «приветствия» от сервера.
авторизоваться Запустите новый сеанс, который будет оставаться открытым до тех пор, пока не будет использован выход из системы или сервер не выйдет из системы пользователя. Также используется для смены пароля. Клиент должен выбрать одну версию EPP и один язык из «приветственного» сообщения при входе в систему. Ему также необходимо выбрать все объекты и расширения, которые поддерживаются сервером и которые он хочет использовать в этом сеансе.
выход из системы Завершить текущий сеанс.

Команды запроса: [ 1 ]

Команда Использование
проверять Проверьте, доступен ли объект для создания.
информация Получите всю актуальную информацию об объекте.
голосование Прочтите сообщение с сервера для пользователя или подтвердите получение сообщения и тем самым удалит его для получения следующего сообщения. ( Очередь сообщений )
передача Получите текущий статус запущенного процесса передачи объекта.

Команды преобразования объекта: [ 1 ]

Команда Использование
создавать Создайте новый объект.
удалить Удалить объект. Хосты и контакты удаляются немедленно, а для доменов чаще всего наступает льготный период погашения .
возобновлять Увеличьте время регистрации доменного имени. Недоступно для объектов, отличных от доменов, поскольку у них нет времени жизни.
передача Сменить регистратора/владельца объекта. Может использоваться для запуска процесса входящего перевода или его отмены, а также для одобрения или отклонения исходящего перевода.
обновлять Обновите объект. Обычно это включает в себя смену владельца домена, хотя она также часто реализуется через расширения EPP из-за более сложного рабочего процесса для этих операций в зависимости от TLD.

Пример команды для создания домена может выглядеть так:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.net</domain:hostObj>
          <domain:hostObj>ns2.example.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>REG-1738</domain:registrant>
        <domain:contact type="admin">ADM-9374</domain:contact>
        <domain:contact type="tech">OTH-2567</domain:contact>
        <domain:contact type="billing">OTH-2567</domain:contact>
        <domain:authInfo>
          <domain:pw>y85NS%FJ4zeKuHXo</domain:pw>
        </domain:authInfo>
      </domain:create>
    </create>
    <clTRID>uu28qbb2wo6o5bpk</clTRID>
  </command>
</epp>

Обратите внимание, что для их использования необходимо было заранее создать два объекта-хоста и три разных объекта-контакта, а клиент уже должен был войти в систему. authInfo pw — это секрет, который необходим при передаче между регистраторами. clTRID — это уникальный идентификатор транзакции для каждой команды, сгенерированной клиентом. Ответ сервера на приведенную выше команду может выглядеть следующим образом:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <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.com</domain:name>
        <domain:crDate>2023-03-12T12:00:00.0Z</domain:crDate>
        <domain:exDate>2024-03-12T12:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <trID>
      <clTRID>uu28qbb2wo6o5bpk</clTRID>
      <svTRID>ma3fuaeuh7bzpgv9</svTRID>
    </trID>
  </response>
</epp>

ClTRID совпадает с отправленным клиентом, а svTRID — это уникальный идентификатор транзакции, сгенерированный сервером. Сервер возвращает код результата, сообщение и дополнительные данные результата, такие как дата истечения срока действия вновь созданного домена.

Расширения

[ редактировать ]

Протокол предлагает возможность отправлять объект расширения практически для каждой возможной команды, что позволяет реестрам добавлять новые функции без изменения базовых команд. [ 1 ]

Существует несколько стандартизированных расширений, которые используются многими реестрами. К ним относятся расширения для DNSSEC , [ 17 ] ИДН , [ 18 ] доменные имена премиум-класса, [ 19 ] восстановление домена ( РГП ) [ 7 ] и расширения для запуска новых TLD [ 20 ] среди прочего. [ 8 ]

Некоторые реестры также разработали расширения, специфичные для их TLD. Распространенным вариантом использования нестандартизированных расширений является сбор дополнительных данных, необходимых для создания домена, например идентификационного номера плательщика НДС . [ 8 ]

Коды результатов

[ редактировать ]

Все ответы сервера должны соответствовать указанному формату. Каждый код ответа соответствует удобочитаемому сообщению. Коды формата 1xxx — это успешные операции, а коды формата 2xxx — ошибки. Ошибки снова делятся на синтаксические ошибки протокола в формате 20xx, конкретные правила реализации — 21xx, безопасность — 22xx, управление данными — 23xx, серверную систему — 24xx и управление соединениями — 25xx. Большинство результатов могут включать дополнительные данные в объект resData, например, какой обязательный параметр конкретно отсутствует. [ 1 ]

Код ответа 1001 включает обработку в автономном режиме. Примером этого может быть то, что реестр доменных имен хочет проверить владельца регистрации перед регистрацией домена. В этом случае домен блокируется для других клиентов до тех пор, пока процесс не завершится, и клиент будет уведомлен с помощью сообщения опроса, которое клиент может получить с помощью команды опроса. Коды 1300 и 1301 предназначены специально для команды опроса и сигнализируют, есть ли сообщение или нет. [ 1 ]

Полный список стандартизированных кодов результатов и сообщений о результатах: [ 1 ]

Код Сообщение
1000 Команда выполнена успешно
1001 Команда выполнена успешно; действие ожидается
1300 Команда выполнена успешно; нет сообщений
1301 Команда выполнена успешно; подтвердить удаление из очереди
1500 Команда выполнена успешно; завершение сеанса
2000 Неизвестная команда
2001 Синтаксическая ошибка команды
2002 Ошибка использования команды
2003 Отсутствует обязательный параметр
2004 Ошибка диапазона значений параметра
2005 Синтаксическая ошибка значения параметра
2101 Нереализованная команда
2102 Нереализованный вариант
2103 Нереализованное расширение
2104 Ошибка выставления счетов
2105 Объект не подлежит продлению
2106 Объект не подлежит передаче
2200 Ошибка аутентификации
2201 Ошибка авторизации
2202 Неверная информация для авторизации
2300 Объект ожидает передачи
2301 Объект не ожидает передачи
2302 Объект существует
2303 Объект не существует
2304 Статус объекта запрещает работу
2305 Ассоциация объектов запрещает работу
2306 Ошибка политики значения параметра
2307 Нереализованный объектный сервис
2308 Нарушение политики управления данными
2400 Команда не выполнена
2500 Команда не удалась; закрытие соединения с сервером
2501 Ошибка аутентификации; закрытие соединения с сервером
2502 Превышен лимит сеансов; закрытие соединения с сервером

Коды состояния объекта EPP

[ редактировать ]

Существует 2 типа кодов состояния: серверный и клиентский. Разница в том, что все коды состояния сервера могут устанавливаться и удаляться только реестром, тогда как коды состояния клиента также могут устанавливаться и удаляться регистратором, если только код состояния сервера не запрещает это. [ 15 ]

Коды состояния сервера обычно используются для обработки случаев злоупотребления доменом, обозначения стадии жизненного цикла домена или обеспечения дополнительной защиты от несанкционированного вмешательства — услуги, часто называемой Registry-Lock.

Коды состояния клиента обычно используются также для обработки случаев злоупотреблений, неплатежей, неверных контактных данных или для функции блокировки регистратора .

В настоящее время стандартизированные коды состояния сервера: [ 15 ] [ 7 ]

Статус сервера Описание Требуемое пользователем действие
добавитьпериод Этот льготный период предоставляется после первоначальной регистрации доменного имени. Если регистратор удаляет доменное имя в течение этого периода, реестр может предоставить регистратору кредит на стоимость регистрации. Это информативный статус, установленный на первые несколько дней после регистрации вашего домена. С вашим доменным именем проблем нет.
автообновление периода Этот льготный период предоставляется после истечения срока регистрации доменного имени и автоматически продлевается (продлевается) реестром. Если регистратор удаляет доменное имя в течение этого периода, реестр предоставляет регистратору кредит на стоимость продления. Это информационный статус, устанавливаемый на ограниченное время после автоматического продления вашего домена реестром. Если вы больше не хотите его сохранять (т. е. платить за продление), вам следует немедленно связаться со своим регистратором, чтобы обсудить доступные варианты.
неактивный Этот код состояния указывает, что информация о делегировании (серверы имен) не связана с вашим доменом. Ваш домен не активирован в DNS и не будет разрешен. Если ваш домен оставался в этом статусе в течение нескольких дней, вы можете обратиться к своему регистратору и запросить информацию о задержке обработки. Если TLD требует предоставления документации для регистрации, вам может потребоваться предоставить необходимую документацию.
хорошо Это стандартный статус домена, означающий, что у него нет ожидающих операций или запретов. Попросите своего регистратора ввести ограничения статуса, такие как clientTransferProhibited, clientDeleteProhibited и clientUpdateProhibited, может помочь предотвратить несанкционированную передачу, удаление или обновление вашего домена.
в ожиданииСоздать Этот код состояния указывает на то, что запрос на создание вашего домена получен и находится в обработке. Если TLD находится в особом периоде регистрации (например, восход солнца), это может указывать на то, что доменное имя будет выделено в конце такого периода.
ОжиданиеУдалить Этот код состояния можно смешивать с redemptionPeriod или pendingRestore. В таком случае, в зависимости от статуса (т.е. redemptionPeriod или pendingRestore), установленного в доменном имени, применяется соответствующее описание, представленное выше. Если этот статус не объединен со статусом redemptionPeriod или pendingRestore, код статуса pendingDelete указывает, что ваш домен находился в статусе redemptionPeriod в течение 30 дней, и вы не восстановили его в течение этого 30-дневного периода. Ваш домен останется в этом статусе в течение нескольких дней, после чего ваш домен будет удален из базы данных реестра. После удаления домен доступен для перерегистрации в соответствии с политикой реестра. Если вы хотите сохранить свое доменное имя, вам необходимо немедленно связаться со своим регистратором, чтобы обсудить доступные варианты.
ОжиданиеОбновить Этот код состояния указывает, что запрос на продление вашего домена получен и находится в обработке. Если вы не запрашивали продление своего домена и не хотите больше его сохранять (т. е. платить за продление), вам следует немедленно связаться со своим регистратором, чтобы обсудить доступные варианты.
ОжиданиеВосстановление Этот код состояния указывает, что ваш регистратор попросил реестр восстановить ваш домен, который находился в статусе redemptionPeriod. Ваш реестр будет удерживать домен в этом статусе, пока ваш регистратор предоставит необходимую документацию для восстановления. Если ваш регистратор не предоставит оператору реестра документацию в течение установленного периода времени для подтверждения запроса на восстановление, домен вернется в статус redemptionPeriod. Следите за кодами статуса вашего домена в течение этого часто определяемого семидневного периода, чтобы убедиться, что ваш регистратор предоставил правильную документацию по восстановлению в течение этого временного окна. Если этот период закончился и ваш домен вернулся к статусу redemptionPeriod, обратитесь к своему регистратору, чтобы решить любые проблемы, которые могли помешать доставке необходимой документации по восстановлению вашего домена.
Ожидание перевода Этот код состояния указывает на то, что запрос на перенос вашего домена новому регистратору получен и находится в обработке. Если вы не запрашивали перенос своего домена, вам следует немедленно обратиться к своему регистратору и попросить его отклонить запрос на перенос от вашего имени.
ожидается обновление Этот код состояния указывает, что запрос на обновление вашего домена получен и обрабатывается. Если вы не запрашивали обновление своего домена, вам следует немедленно обратиться к своему регистратору для решения проблемы.
Период погашения Этот код состояния указывает на то, что ваш регистратор попросил реестр удалить ваш домен. Ваш домен будет удерживаться в этом статусе в течение 30 дней. По истечении пяти календарных дней после окончания периода погашения ваш домен удаляется из базы данных реестра и становится доступным для регистрации. Если вы хотите сохранить свой домен, вы должны немедленно обратиться к своему регистратору для решения проблем, которые привели к тому, что ваш регистратор потребовал удалить ваш домен, что привело к изменению статуса redemptionPeriod для вашего домена. Как только все нерешенные проблемы будут решены и соответствующая плата будет уплачена, ваш регистратор должен восстановить домен от вашего имени.
обновитьпериод Этот льготный период предоставляется после того, как регистратор явно продлит (продлит) период регистрации доменного имени. Если регистратор удаляет доменное имя в течение этого периода, реестр предоставляет регистратору кредит на стоимость продления. Это информационный статус, устанавливаемый на ограниченный период времени или на продление вашего домена вашим регистратором. Если вы не запрашивали продление своего домена и не хотите больше его сохранять (т. е. платить за продление), вам следует немедленно связаться со своим регистратором, чтобы обсудить доступные варианты.
серверDeleteProhibited Этот код состояния предотвращает удаление вашего домена. Это необычный статус, который обычно применяется во время юридических споров, по вашему запросу или при наличии статуса redemptionPeriod. Этот статус может указывать на проблему с вашим доменом, которую необходимо решить. В этом случае вам следует обратиться к своему регистратору, чтобы запросить дополнительную информацию и решить проблему. Если с вашим доменом нет никаких проблем и вы просто хотите его удалить, вам необходимо сначала обратиться к своему регистратору и попросить его совместно с оператором реестра удалить этот код состояния. В качестве альтернативы некоторые операторы реестра предлагают услугу блокировки реестра, которая позволяет владельцам регистраций через своих регистраторов устанавливать этот статус в качестве дополнительной защиты от несанкционированного удаления. Удаление этого статуса может занять больше времени, чем для clientDeleteProhibited, поскольку вашему регистратору придется перенаправить ваш запрос в реестр вашего домена и дождаться, пока он снимет ограничение.
серверУдержание Этот код состояния устанавливается оператором реестра вашего домена. Ваш домен не активирован в DNS. Если вы предоставили информацию о делегировании (серверах имен), этот статус может указывать на проблему с вашим доменом, которую необходимо решить. В этом случае вам следует обратиться к своему регистратору и запросить дополнительную информацию. Если с вашим доменом нет никаких проблем, но вам необходимо разрешить их в DNS, вам необходимо сначала обратиться к своему регистратору, чтобы предоставить необходимую информацию о делегировании.
серверОбновлениеЗапрещено Этот код состояния указывает, что оператор реестра вашего домена не разрешит вашему регистратору продлить срок действия вашего домена. Это необычный статус, который обычно применяется во время юридических споров или когда ваш домен подлежит удалению. Часто этот статус указывает на проблему с вашим доменом, которую необходимо срочно устранить. Вам следует обратиться к своему регистратору, чтобы запросить дополнительную информацию и решить проблему. Если с вашим доменом нет никаких проблем и вы просто хотите продлить его, вам необходимо сначала обратиться к своему регистратору и попросить его совместно с оператором реестра удалить этот код состояния. Этот процесс может занять больше времени, чем для clientRenewProhibited, поскольку ваш регистратор должен перенаправить ваш запрос в реестр вашего домена и дождаться, пока он снимет ограничение.
serverTransferProhibited Этот код состояния предотвращает перенос вашего домена от текущего регистратора к другому. Это необычный статус, который обычно применяется во время юридических или других споров, по вашему запросу или при наличии статуса redemptionPeriod. Этот статус может указывать на проблему с вашим доменом, которую необходимо срочно устранить. Вам следует обратиться к своему регистратору, чтобы запросить дополнительную информацию и решить проблему. Если с вашим доменом нет никаких проблем, и вы просто хотите передать его другому регистратору, вам необходимо сначала связаться со своим регистратором и попросить его совместно с Оператором реестра удалить этот код состояния. В качестве альтернативы некоторые операторы реестра предлагают услугу блокировки реестра, которая позволяет владельцам регистраций через своих регистраторов устанавливать этот статус в качестве дополнительной защиты от несанкционированной передачи. Удаление этого статуса может занять больше времени, чем для clientTransferProhibited, поскольку вашему регистратору придется перенаправить ваш запрос в реестр вашего домена и дождаться, пока он снимет ограничение.
обновление сервера запрещено Этот код состояния блокирует ваш домен, предотвращая его обновление. Это необычный статус, который обычно применяется во время юридических споров, по вашему запросу или при наличии статуса redemptionPeriod. Этот статус может указывать на проблему с вашим доменом, которую необходимо решить. В этом случае вам следует обратиться к своему регистратору для получения дополнительной информации или решения проблемы. Если с вашим доменом нет никаких проблем и вы просто хотите его обновить, вам необходимо сначала обратиться к своему регистратору и попросить его совместно с оператором реестра удалить этот код состояния. В качестве альтернативы некоторые операторы реестра предлагают услугу блокировки реестра, которая позволяет владельцам регистраций через своих регистраторов устанавливать этот статус в качестве дополнительной защиты от несанкционированных обновлений. Удаление этого статуса может занять больше времени, чем для clientUpdateProhibited, поскольку вашему регистратору придется перенаправить ваш запрос в реестр вашего домена и дождаться, пока он снимет ограничение.
TransferPeriod Этот льготный период предоставляется после успешной передачи доменного имени от одного регистратора к другому. Если новый регистратор удаляет доменное имя в течение этого периода, реестр предоставляет регистратору кредит на стоимость передачи. Это установка информативного статуса на ограниченный период или передача вашего домена новому регистратору. Если вы не запрашивали перенос своего домена, вам следует обратиться к своему первоначальному регистратору.

В настоящее время стандартизированные коды состояния клиента: [ 15 ]

Статус клиента Описание Требуемое пользователем действие
клиентDeleteProhibited Этот код состояния сообщает реестру вашего домена отклонять запросы на удаление домена. Этот статус указывает на то, что невозможно удалить регистрацию доменного имени, что может предотвратить несанкционированное удаление в результате взлома и/или мошенничества. Если вы хотите удалить свой домен, вам необходимо сначала обратиться к своему регистратору и попросить его удалить этот код состояния.
клиентHold Этот код состояния сообщает реестру вашего домена не активировать ваш домен в DNS и, как следствие, он не будет разрешен. Это необычный статус, который обычно применяется во время юридических споров, неуплаты или когда ваш домен подлежит удалению. Часто этот статус указывает на проблему с вашим доменом, которую необходимо решить. В этом случае вам следует обратиться к своему регистратору для решения проблемы. Если с вашим доменом нет проблем, но вам необходимо их решить, вам необходимо сначала обратиться к своему регистратору и попросить его удалить этот код состояния.
клиентRenewProhibited Этот код состояния сообщает реестру вашего домена отклонять запросы на продление вашего домена. Это необычный статус, который обычно применяется во время юридических споров или когда ваш домен подлежит удалению. Часто этот статус указывает на проблему с вашим доменом, которую необходимо решить. В этом случае вам следует обратиться к своему регистратору для решения проблемы. Если с вашим доменом нет никаких проблем и вы просто хотите продлить его, вам необходимо сначала обратиться к своему регистратору и попросить его удалить этот код состояния.
clientTransferProhibited Этот код состояния сообщает реестру вашего домена отклонять запросы на передачу домена от вашего текущего регистратора к другому. Этот статус указывает на то, что невозможно передать регистрацию доменного имени, что поможет предотвратить несанкционированную передачу в результате взлома и/или мошенничества. Если вы хотите перенести свой домен, вам необходимо сначала обратиться к своему регистратору и попросить его удалить этот код состояния.
clientUpdateProhibited Этот код состояния сообщает реестру вашего домена отклонять запросы на обновление домена. Этот статус доменного имени указывает на то, что обновить домен невозможно, что может помочь предотвратить несанкционированные обновления в результате мошенничества. Если вы хотите обновить свой домен, вам необходимо сначала обратиться к своему регистратору и попросить его удалить этот код состояния.

Соображения безопасности

[ редактировать ]

EPP предлагает только текстовые пароли, кроме того, тип пароля для входа в EPP указывается как строка длиной 6–16 символов. [ 1 ] что можно считать очень низким по сегодняшним стандартам. Поэтому соединения через TCP должны использовать TLS , и настоятельно рекомендуется использовать клиентские сертификаты , а также правильное подтверждение личности клиента и сервера. [ 21 ]

Кроме того, многие реестры доменных имен предлагают настроить белый список IP-адресов для подключения к своим серверам EPP.

EPP предлагает некоторую защиту от атак повторного воспроизведения через clTRID, сгенерированный клиентом, однако этот элемент является необязательным и поэтому не используется каждым серверным программным обеспечением. Поэтому в используемом транспортном механизме должны быть реализованы дополнительные механизмы предотвращения повторного воспроизведения. [ 1 ]

[ редактировать ]
  • RFC 3375 , Общие требования к протоколу реестра-регистратора
  • RFC 5730, Extensible Provisioning Protocol (EPP) (obsoletes RFC 4930, which obsoleted RFC 3730 )
  • RFC 5734, Extensible Provisioning Protocol (EPP) Transport over TCP (obsoletes RFC 4934 )

Объекты EPP RFC

[ редактировать ]
  • RFC 5731, Extensible Provisioning Protocol (EPP) Domain Name Mapping (obsoletes RFC 4931 )
  • RFC 5732, Extensible Provisioning Protocol (EPP) Host Mapping (obsoletes RFC 4932 )
  • RFC 5733, Extensible Provisioning Protocol (EPP) Contact Mapping (obsoletes RFC 4933 )
  • RFC 8543 , Сопоставление организации расширяемого протокола обеспечения (EPP)

RFC расширения EPP

[ редактировать ]
  • RFC 3735 , Рекомендации по расширению EPP
  • RFC 3915 , сопоставление льготного периода реестра доменов (например, добавление льготного периода , льготный период погашения )
  • RFC 4114 , Сопоставление номеров E.164 для расширяемого протокола обеспечения (EPP)
  • RFC 5076 , Отображение информации проверки ENUM для расширяемого протокола обеспечения
  • RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) (obsoletes RFC 4310 , DNSSEC )
  • RFC 8334 , Сопоставление фаз запуска расширяемого протокола обеспечения (EPP)
  • RFC 8495 , Расширение токена распределения для расширяемого протокола обеспечения (EPP)
  • RFC 8544 , Расширение организации для расширяемого протокола обеспечения (EPP)
  • RFC 8590 , Расширение опроса изменений для расширяемого протокола обеспечения (EPP)
  • RFC 8748 , Расширение регистрационного сбора для расширяемого протокола обеспечения (EPP)
  • RFC 9038 , Необработанные пространства имен расширяемого протокола обеспечения (EPP)

См. также

[ редактировать ]
  1. ^ Jump up to: а б с д и ж г час я дж к л м Холленбек, С. (август 2009 г.). «Расширяемый протокол обеспечения (EPP)» . дои : 10.17487/RFC5730 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  2. ^ «Расширяемый протокол обеспечения» . Трекер данных IETF . Проверено 13 марта 2023 г.
  3. ^ «Протоколы IETF за декабрь 2000 г.» . www.ietf.org . Проверено 13 марта 2023 г.
  4. ^ Холленбек, С. (март 2004 г.). «Расширяемый протокол обеспечения (EPP)» . дои : 10.17487/RFC3730 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  5. ^ Холленбек, С. (май 2007 г.). «Расширяемый протокол обеспечения (EPP)» . дои : 10.17487/RFC4930 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  6. ^ Холленбек, С. (август 2009 г.). «Расширяемый протокол обеспечения (EPP)» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  7. ^ Jump up to: а б с Холленбек, С. (сентябрь 2004 г.). «Сопоставление льготного периода реестра доменов для расширяемого протокола обеспечения (EPP)» . дои : 10.17487/RFC3915 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  8. ^ Jump up to: а б с «Расширения для расширяемого протокола обеспечения (EPP)» . www.iana.org . Проверено 11 марта 2023 г.
  9. ^ «Отчет о внедрении RFC 4930-4934 — Wayback Machine» . 15 января 2012 г. Архивировано из оригинала 15 января 2012 г. Проверено 12 марта 2023 г. {{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
  10. ^ «Договор о базовом реестре ICANN» . newgtlds.icann.org . Проверено 12 марта 2023 г.
  11. ^ «Официальный сайт CoCCA» . Проверено 12 марта 2023 г.
  12. ^ «Представляем ФРЕДА — Фред» . fred.nic.cz. ​Проверено 12 марта 2023 г.
  13. ^ Холленбек, С. (август 2009 г.). «Сопоставление хостов расширяемого протокола обеспечения (EPP)» . дои : 10.17487/RFC5732 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  14. ^ Холленбек, С. (август 2009 г.). «Сопоставление контактов расширяемого протокола обеспечения (EPP)» . дои : 10.17487/RFC5733 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  15. ^ Jump up to: а б с д Холленбек, С. (август 2009 г.). «Сопоставление доменных имен расширяемого протокола обеспечения (EPP)» . дои : 10.17487/RFC5731 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  16. ^ Чжоу, Л.; Конг, Н.; Яо, Дж.; Гулд, Дж.; Чжоу, Г. (март 2019 г.). «Сопоставление организации расширяемого протокола обеспечения (EPP)» . дои : 10.17487/RFC8543 . ISSN   2070-1721 . S2CID   65065583 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  17. ^ Гулд, Дж.; Холленбек, С. (май 2010 г.). «Сопоставление расширений безопасности системы доменных имен (DNS) для расширяемого протокола обеспечения (EPP)» . дои : 10.17487/RFC5910 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  18. ^ «Интернациональное расширение сопоставления доменных имен для расширяемого протокола обеспечения (EPP)» . Трекер данных IETF . Проверено 11 марта 2023 г.
  19. ^ Карни, Роджер (март 2020 г.). «RFC 8748: Расширение регистрационного сбора для расширяемого протокола обеспечения (EPP)» . www.rfc-editor.org . Проверено 11 марта 2023 г.
  20. ^ Гулд, Дж.; Тан, В.; Браун, Г. (март 2018 г.). «Составление карты этапов запуска расширяемого протокола обеспечения (EPP)» . дои : 10.17487/RFC8334 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  21. ^ Холленбек, С. (август 2009 г.). «Транспортировка расширяемого протокола обеспечения (EPP) через TCP» . дои : 10.17487/RFC5734 . ISSN   2070-1721 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 1327e106598a53a88b4d619e1376c80e__1713707880
URL1:https://arc.ask3.ru/arc/aa/13/0e/1327e106598a53a88b4d619e1376c80e.html
Заголовок, (Title) документа по адресу, URL1:
Extensible Provisioning Protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)