Технический регламент
Технический регламент домена .УКР (версия 3.0) разработан Оператором реестра (ООО “Технический центр Интернет”) и утверждён Администратором домена .УКР.
Внимание! Настоящий текст Технического регламента был переведен на русский язык только для информационных целей.
Оригинал и аутентичный текст Технического регламента на украинском языке.
Технический регламент прошёл общественное обсуждение, в ходе которого было представлено со стороны участников рынка и госорганов более 40 предложений и поправок.
Текст Технического регламента домена .УКР (версия 3.0) в формате .pdf (на украинском языке)
Текст Технического регламента:
| УТВЕРЖДЕНО | |
| Директор ОП «Украинский сетевой информационный центр»
________________ Гончарук Ю.В. «07» ноября 2013 |
Технический регламент
домена. УКР
(Редакция 3.0)
| РАЗРАБОТАН |
| Директор ООО «Технический центр Интернет» |
| ________________ Билык З.Ю. |
| «07» ноября 2013 г |
Киев
2013
Содержание
1. Общие положения.
2. Определения и термины
3. Система регистраций и управления доменными именами в домене. УКР Оператора реестра.
3.1. Принципы работы Системы
3.2. Техническая архитектура и состав системы
3.3. Взаимодействие участников Системы
3.3.1. Участники Системы
3.3.2. Схема взаимодействия участников Системы
4. Подсистема регистраций.
4.1. Общие сведения
4.2. Реестр
4.3.Объекты типа Domain
4.3.1. Периоды (циклы) жизни, полный жизненный цикл домена
4.3.2. Статусы доменных имен
4.4.Объекты типа Contact
4.4.1. Периоды жизни
4.4.2. Статусы объекта Contact
4.5. Объекты типа Host
4.5.1. Периоды жизни
4.5.2. Статусы объекта Host
4.6. Объекты типа Registrar
4.6.1. Периоды жизни
4.6.2. Статусы объекта Registrar
4.7.Доступность подсистемы регистраций
4.8. Требования к безопасности
4.9. Набор инструментов разработки программного обеспечения EPP
4.10. Надежность подсистемы регистраций
5. Подсистема DNS.
5.1. Общие сведения
5.2. Ресурсные записи файла зоны
5.3. Обслуживание файла зоны
5.4. Доступность подсистемы DNS
5.5. Надежность работы DNS-серверов
6. Служба WHOIS
6.1. Общие сведения
6.2. Набор данных WHOIS
6.3. Протоколы для запросов к службе WHOIS
6.4. Доступность службы WHOIS
6.5. Надежность службы WHOIS
7. Трансфер доменных имен
7.1.Процедура трансфера доменного имени состоит из следующих шагов
7.2. Процедура трансфера при принудительной смены Регистратора
8. Защита информации в Системе
Список иллюстраций
Рисунок 1. Система Оператора реестра
Рисунок 2. Схема взаимодействия участников Системы технически
Рисунок 3. Жизненный цикл домена
Рисунок 4.Последовательность и условия перехода домена между периодами жизненного цикла
Список таблиц
Таблица 1. Принципы работы Системы
Таблица 2. Взаимодействие и функции участников процесса пользования, сопровождения и технического обслуживания Системы
Таблица 3. Статусы объекта Domain, связанные с его жизненным циклом
Таблица 4. Запрещающие статусы объекта Domain
Таблица 5. Технологические статусы объекта Domain
Таблица 6. Информационные статусы объекта Domain
Таблица 7. Статусы объекта Contact
Таблица 8. Технологические статусы объекта Contact
Таблица 9. Информационные статусы объекта Contact
Таблица 10. Статусы объекта Host
Таблица 11. Технологические статусы объекта Host
Таблица 12. Информационные статусы объекта Host
Таблица 13. Статусы объекта Registrar
Таблица 14. Минимальные параметры доступности службы EPP, которая должна обеспечивать подсистема регистраций
Таблица 15. Минимальные параметры доступности сервера доменных имен, должна обеспечивать подсистема DNS
Таблица 16. Набор данных WHOIS
Таблица 17. Минимальные параметры доступности службы WHOIS
1. Общие положения.
1.1. Этот Технический регламент домена. УКР (далее – Регламент) определяет общую архитектуру, состав и принципы работы, общие параметры и характеристики системы регистрации и пользования доменными именами в домене. УКР (далее – Система) Оператора реестра, технические условия взаимодействия участников пользования, сопровождения и технического обслуживания всех компонентов Системы, с целью обеспечения ее постоянной, безопасной и бесперебойной работоспособности.
1.2. Система представляет собой комплекс, состоящий из:
- публично доступных подсистем и служб, связанных с сопровождением реестра. УКР,
- ограничено доступных внутренних подсистем и служб, отвечающих за осуществление внутренних и внешних транзакций,
- подсистем, отвечающих за документарный и электронное сопровождение и оформление осуществляемых транзакций в ходе регистрации и пользования доменными именами.
1.3. Регламент определяет порядок взаимодействия участников пользования, сопровождения и технического обслуживания Системы:
- в процессе поддержки Регистраторов,
- в процессе поддержки регистранта / пользователей услуг,
- выполнения запросов в реестр,
- актуализации информации в файле зоны домена. УКР и базе данных реестра,
- проведения мониторинга и регламентных работ,
- осуществления резервного копирования и восстановления информации о файле зоны домена. УКР и базу данных реестра,
- в процессе получения информации о доменных именах с помощью сервиса WHOIS.
1.4. Регламент является руководящим техническим документом для использования в ходе промышленной эксплуатации Системы и при процессов тестирования Регистраторов. Его выполнение обязательное для всех участников процесса пользования, сопровождения и технического обслуживания Системы.
1.5. Кроме положений настоящего Регламента, используются следующие условия и положения, связанные с настоящим Регламентом, а именно:
1) технические условия на взаимодействие программно-аппаратных комплексов Регистраторов с Системой, представленные в документе «Технические условия взаимодействия с системой регистраций и управления доменными именами домена. УКР »,
2) правила и последовательность работы с EPP-командами, которые представлены в документе «Инструкция по работе с EPP-командами»,
3) технические условия прохождения Регистратором тестирования, представленные в документе «Программа тестирования Регистраторов при подключении к системы регистраций и управления доменными именами домена. УКР »,
4) правила и условия прохождения аккредитации представлены в документе «Положение об аккредитации Регистраторов доменных имен в домене. УКР»,
Условия и положения по взаимодействию Оператора реестра и Регистратора определяются при заключении между ними договора о техническую поддержку и обеспечение доступа к реестру, однако эти условия и положения не могут противоречить условиям настоящего Регламента.
1.6. Регламент разрабатывается Оператором реестра и утверждается администрацией после чего он действует для Регистраторов на весь период тестовой и промышленной эксплуатации Системы.
Нарушение положений или условий настоящего Регламента или любых других документов, ссылки на которые содержатся в настоящем Регламенте, недопустимы.
Изменение этого регламента может быть инициирована одним из следующих сторон:
- Администратором домена. УКР,
- Оператором реестра домена. УКР.
Инициативы по изменениям в документе осуществляются Оператором реестра. Измененный документ вступает в силу после согласования изменений Администратором и Оператором реестра домена. УКР.
2. Определения и термины
Определения, применяемые в настоящем Регламенте соответствуют определениям, указанным в «Правилах регистрации и пользования доменными именами в домене. УКР» (далее – Правила) и в «Положении об аккредитации Регистраторов в домене. УКР».
Определение, является отсутствовать, или такие, которые не использовались в технологическом смысле в вышеуказанных документах, приведены ниже:
| DNS-сервер | - Сервер, который отвечает на запросы по DNS протокола; |
| EPP | - Протокол взаимодействия программного обеспечения Регистратора реестра; |
| база данных реестра (БДР) | - База данных, в которой хранятся все имеющиеся сведения об объектах Domain, Registrant, Contact, Host, Registrar, и вспомогательная информация; |
| уполномоченный DNS-сервер | - DNS-сервер, отвечающий за данные в файле зоны домена. УКР; |
| делегирования домена | - Внесение NS записей домена в файл зоны домена высшего уровня; |
| доменное имя второго уровня | - Часть доменного имени, отделенная точкой от имени домена; |
| подсистема DNS | - Подсистема в составе Системы, которая отвечает за файл зоны домена, дает ответы на DNS запросы пользователей; |
| подсистема регистраций | - Подсистема в составе Системы, которая отвечает за доступ к информации в БДД и внесении изменений в БДД отношении доменов, регистрантов, хостов, контактов; |
| система регистрации и пользования доменными именами домена. УКР Оператора реестра (Система) | - Программно-технический и организационный комплекс, которой управляется Оператором реестра и предоставляет регистратору возможность на протяжении всего жизненного цикла доменного имени в полной соответствии с релевантных технических стандартов Интернет и значений технических параметров осуществлять операции с именами второго уровня в домене. УКР (а) по регистрации доменных имен, (б) делегирование доменных имен зарегистрированных доменов (в) изменение регистрантов этих доменных имен, (г) модификаций статусов объектов в системе доменных имен, (г) трансфера доменных имен, (д) отмене регистрации доменных имен, ( е) хранение информации о доменных именах второго уровня и связанных с ними контакты, (есть) получения информации о доменных именах; |
| служба WHOIS (сервис WHOIS) | - Подсистема в составе Системы, которая по соответствующему протоколу предоставляет сведения о доменах, регистрантов, контакты и хосты; |
| файл зоны домена. УКР (ФЗ) | - Данные, которые используется подсистемой DNS для обслуживания запросов в уполномоченные DNS серверов домена. УКР, и предоставление ответов о делегировании и адресацию доменов второго уровня в домене. УКР. |
3. Система регистраций и управления доменными именами в домене. УКР Оператора реестра.
Система решает задачи:
1) регистрации доменных имен второго уровня в домене. УКР;
2) хранение информации о регистрантов и контакты доменов;
3) хранение информации о DNS-серверы, на которые делегируется зарегистрирован домен;
4) хранение информации о Регистраторов;
5) хранения служебной информации (о полученных услугах, истории изменений, сроки выполнения команд и процедур и т.п.);
6) наблюдение за сроками хранения информации и выполнения процедур по удалению информации;
7) управления делегированием доменов;
8) формирование файла зоны домена. УКР и обработка запросов по DNS протокола;
9) информирование пользователей сети Интернет о зарегистрированных доменах и их регистрантов;
10) обновление информации о доменных именах, регистрантов и контакты доменов, DNS-серверы, Регистраторов.
3.1. Принципы работы Системы.
Система обеспечивает реализацию принципов, приведенных в таблице 1.
Таблица 1. Принципы работы Системы
|
№ |
Принцип |
Цель |
| 1 | Транзакционность | Обеспечение целостности данных и предотвращения и исключения конфликтов, при работе многих пользователей с одним и тем же набором данных |
| 2 | Масштабируемость | Увеличить производительность Системы путем увеличения количества серверных компонент или путем увеличения вычислительной мощности отдельных компонент |
| 3 | Многократного резервирования узлов и компонентов системы | Предотвращения потери данных и минимизации времени на восстановление полной работоспособности Системы в случае выхода из строя оборудования или других непредвиденных обстоятельств. |
| 4 | Наличие инструментов самодиагностики и внешней диагностики ключевых компонентов системы | Способность самоопределения Системой проблем с каким-либо компонентом, путем вызова и обработки специального набора тестовых задач, выполняемых каждой из подсистем. |
| 5 | Соответствие протоколов и схем взаимодействия международным стандартам | Доступ к Системе, работа Системы осуществляются по протоколам, которые отвечают общим Интернет стандартам |
| 6 | Защищенность от внешних вторжений | Реализация Системой политик безопасности, предоставляющих максимально возможную защиту от атак, вторжений, несанкционированного доступа к данным. |
| 7 | Безотказность | Обеспечение поддержания работоспособности в случаях сбоев в работе основных серверов подсистем регистрации, DNS и / или WHOIS с набором данных, которой был актуальным перед сбоем подсистемы. |
| 8 | Синхронизация данных | Обеспечение безотказной работы путем поддержки актуального состояния баз данных серверов, работающих в режиме «горячей замены». |
3.2. Техническая архитектура и состав системы.
Система состоит из следующих подсистем:
- подсистема регистраций,
- подсистема DNS,
- служба WHOIS,
- телекоммуникационная подсистема,
- подсистема защиты информации
- подсистема диагностики, мониторинга и статистики.
Схема Системы представлена на рисунке 1.
Рисунок 1. Система Оператора реестра.
Соответствующая информация об адресах публично доступных серверов DNS и сервисов размещена по ссылке https://www.iana.org/domains/root/db/xn--j1amh.html .
Система состоит из следующих основных компонентов:
1) единой базы данных реестра ( в которой реализован реестр доменов второго уровня);
2) EPP-серверов, обеспечивающих обмен информацией между Регистраторами и реестром с использованием EPP-протокола;
3) DNS-серверов (front-end, hidden), обеспечивающих ответы на DNS запросы по соответствующим протоколом;
4) WHOIS-серверов, обеспечивающих получение информации из реестра о зарегистрированных доменах, их делегирование, о регистрантов и контакты зарегистрированных доменов для всех пользователей сети Интернет;
5) DNS-серверов, обслуживающих специальные домены по решению Администратора.
3.3. Взаимодействие участников Системы.
3.3.1. Участники Системы
Участниками Системы являются:
1) Администратор домена. УКР,
2) Оператор реестра домена. УКР,
3) Регистраторы доменных имен,
4) Регистранты,
5) Пользователи Интернет.
Ниже приведена таблица 2, в которой определена взаимодействие и функции участников процесса пользования , сопровождения и технического обслуживания Системы.
Таблица 2. Взаимодействие и функции участников процесса пользования, сопровождения и технического обслуживания Системы
|
Участник |
Функция |
С кем взаимодействует |
| Администратор | обеспечения выполнения требований Правил, принятия решений о регистрации в течение периода приоритетной регистрации | Оператор реестра, Регистратор, Регистранты |
| Оператор реестра | обеспечения рабочих процессов Регистраторов | Регистратор |
| обеспечения выполнения требований Правил | Администратор | |
| обеспечения рабочих процессов Регистраторов | Регистратор | |
| поддержка в актуальном состоянии ФЗ | Администратор Регистратор | |
| поддержка в актуальном состоянии БДД | Администратор Регистратор | |
| обеспечение мероприятий по безотказной работе ФЗ | Администратор | |
| обеспечение мероприятий по безотказной работе БДД | Администратор | |
| обеспечение мероприятий по безотказной работе и восстановлению во временные нормативы работы всей Системы | Администратор Регистраторы | |
| Регистратор | обеспечения выполнения требований Правил | Администратор |
| регистрация и обслуживание доменных имен | Оператор реестра, Регистрант | |
| Регистрант | регистрация и пользование доменными именами | Регистратор |
| Пользователь | WHOIS о доменном имя | Оператор реестра,
Регистратор |
| Пользователь | DNS запросы к подсистеме DNS | Оператор реестра |
3.3.2. Схема взаимодействия участников Системы.
Схема взаимодействия участников Системы технически представлена на рисунке 2.
Рисунок 2. Схема взаимодействия участников Системы на техническом уровне.
4. Подсистема регистраций.
4.1. Общие сведения.
Через подсистему регистраций Регистраторам предоставляется доступ к БДР реестра. Регуляторные и организационные условия, на которых Регистратор получает доступ к БДР реестра, определяются Правилами.
Регистратор обязан пройти аккредитацию и по ее итогам получить в Администратора уникальный идентификатор Регистратора. Только имея такой идентификатор Регистратор может получить доступ к реестру через подсистему регистраций.
Виртуальный регистратор имеет специальный идентификатор Registrar ID: REGISTRY.
Подсистема регистраций поддерживает и обеспечивает работу по протоколу EPP.
Подсистема регистраций включает минимально 3 (три) сервера, расположенных в 2-х ( двух) независимых датацентрах.
Используется транспортный протокол TCP / IP.
Минимально два сервера всегда находятся в режиме Standby.
Подсистема регистраций поддерживает и обеспечивает полный жизненный цикл домена.
4.2. Реестр
Реестр подсистемы регистраций предполагает наличие пяти объектов:
1) объект Registrar , содержащий информацию о Регистратора;
2) объект Domain , содержащий информацию о доменном имени, его статусы, связи с объектами Registrar , Registrant,Contact и Host ;
3) объект Registrant – это особый тип объекта Contact, содержащий информацию о Регистранта определенного доменного имени (объекта Domain)
4) объект Contact , содержащий информацию о контактных лицах, которые могут быть связаны с доменами;
5) объект Host , содержащий информацию о DNS-сервер, который может использоваться для делегирования домена.
Такая организация позволяет многократно использовать информацию, хранящуюся в объектах Host, Registrant и Contact при регистрации нескольких доменных имен в реестре. Для изменения данных о Регистранта доменного имени, или контактных лиц или данных DNS-сервера для нескольких доменов необходимо выполнить изменение значений атрибутов в объектах Registrant, Contact и Host только один раз.
Объекты предусматривают наличие периодов (циклов) жизни. На каждом определенном периоде (цикле) жизни, объекты имеют определенные характеристики и ограничения.
Объекты в Системе характеризуются атрибутами, статусами и связями с другими.
Атрибуты объектов бывают: содержащие тестовую информацию, содержащие только цифровую информацию, и такими, которые могут иметь только фиксированный набор значений.
Значения атрибутов могут быть изменены Регистратором и / или Оператором реестра
4.3. Объекты типа Domain
Объекты типа Domain предназначены для хранения информации о доменных именах и о связях объектов Domain с другими.
идентификатором объектов Domain (домен) в реестре есть имя домена. Формат и ограничения для имен доменов определяются Правилами. Идентификатор объекта Domain является уникальным в реестре. Все заглавные символы идентификатора объекта Domain при сохранении в реестре переводятся в строчные.
Домен может находиться под управлением только одного Регистратора. Домен может быть зарегистрирован в реестре только при наличии в нем четырех ссылок на контактные лица (ссылки на объекты Registrant – Регистрант и Contact – административный, технический, финансовый контакты).
Часть информации об объекте Domain может быть получена с помощью запроса к сервиса WHOIS Системы, где в качестве ключа запроса указано имя домена. При этом в состав информации, предоставляется через сервис WHOIS, где включается информация из объектов, ссылки на которые присутствуют в объекте Domain.
4.3.1. Периоды (циклы) жизни, полный жизненный цикл домена
Объект Domain (домен) имеет полный жизненный цикл с момента создания доменного имени до момента его удаления из реестра и может находиться в пяти различных периодах жизненного цикла, приведены на рисунке 3. Этот рисунок не отражает последовательность переходов домена по периодам полного жизненного цикла, а лишь схематично отражает наличие периодов, и их продолжительность. Последовательность и условия перехода домена между периодами жизненного цикла отражены на рисунке 4.
По окончании периода действия регистрации объекта Domain, реестр автоматически продлевает его регистрации на +1 год (домен переходит в Период автоматического продления).
Объект Domain хранится в реестре и доступен для внесения изменений Регистратору в течение периода действия регистрации и периода автоматического продления. На протяжении различных периодов жизни домен может иметь различные статусы.
Особенности технологических действий, совершаемых над доменами протяжении различных периодов его жизненного цикла, представлены в Технических условиях взаимодействия с системой регистраций и пользования доменными именами в домене. УКР.
Рисунок 3. Жизненный цикл домена
Рисунок 4. Последовательность и условия перехода домена между периодами жизненного цикла
4.3.2. Статусы доменных имен
Каждое доменное имя в каждый момент времени имеет определенный набор статусов. Статусы доменов делятся на те, которые связаны с жизненным циклом доменного имени, и запретительные статусы.
Статусы, начинающиеся с приставки «server» устанавливаются Оператором реестра, статусы, начинающиеся с приставки «client» устанавливаются Регистратором.
Например: статус serverRenewProhibited, устанавливаемый Оператором реестра и запрещает продление срока регистрации доменного имени; статус clientHold, что устанавливается Регистратором и запрещает делегирование домена.
Условия установления статуса определены в Правилах.
Статусы, связанные с жизненным циклом домена приведены в таблице 3.
Таблица 3. Статусы объекта Domain, связанные с его жизненным циклом
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| автоматическое продление | устанавливается после окончания срока действия регистрации. Домен продлевается, если это не запрещено запретительными статусами. Если в течение 30 суток Регистратор отменяет продолжение – домен переходит в «ожидания восстановления» | autoRenewPeriod |
| ожидания восстановления | устанавливается когда срок действия регистрации домена закончился или его досрочно прекращены.Этот статус временно, сроком на 25 (двадцать пять) суток, устанавливается Оператором реестра. В этот срок действующий Регистратор имеет возможность восстановить регистрацию домена. Если в течение действия этого статуса действующий Регистратор не отправляет команду восстановления – домен переходит в «ожидания удаления» | redemptionPeriod |
| ожидания удаления | устанавливается когда срок действия регистрации домена закончился или досрочно прекращены и во время действия статуса “ожидания восстановления” не поступила команда на восстановление. Этот статус определяет, что в течение 5 (пяти) дней домен должен быть удален из реестра, при этом запись о домене удаляется из базы данных реестра и этот домен приобретает статус «свободен». Если в течение действия этого статуса до сведения Оператора реестра, в установленном действующим законодательством порядке, будет доказано, что в отношении доменного имени вступило законную силу решения суда о продлении действия регистрации доменного имени, отмены регистрации доменного имени не осуществляется.Оператор реестра осуществляет действия, в результате которых доменное имя приобретает статус «ожидания восстановления» | pendingDelete |
| ожидания трансфера | устанавливается когда в реестр поступила заявка на трансфер домена к другому Регистратору.Действует до момента когда заявку на трансфер будет одобрен или отклонен | pendingTransfer |
Запрещающие статусы могут устанавливаться как Регистратором, так и Оператором реестра. Запрещающие статусы, установленных Регистратором могут быть сняты только Регистратором, запрещающие статусы, установленные Оператором реестра могут быть сняты только Оператором реестра.
Запрещающие статусы приведены в таблице 4.
Таблица 4. Запрещающие статусы объекта Domain
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| запрет продолжение | устанавливается для предотвращения продления срока действия регистрации доменного имени | clientRenewProhibited
serverRenewProhibited |
| запрет удаления | устанавливается для предотвращения удаления доменного имени | clientDeleteProhibited
serverDeleteProhibited |
| делегирование приостановлено | устанавливается в случае нарушения регистранта условий регистрации или использования доменного имени согласно Правил. При устранении нарушений этот статус может быть снят. При этом срок приостановления делегирования не влияет на срок регистрации доменного имени | clientHold
serverHold |
| трансфер запрещено | устанавливается для предотвращения трансфера доменного имени | clientTransferProhibited
serverTransferProhibited |
| изменения запрещено | устанавливается когда нужно запретить внесение изменений в атрибуты объекта, или в связи объекта Domain с объектами Contact и Host. Этот статус не устанавливает запрета на действия по продлению, удаления или трансфер домена. | clientUpdateProhibited
serverUpdateProhibited |
| в состоянии спора | устанавливается когда относительно домена возбуждено досудебное или судебное дело. Действия по удалению, внесении изменений, отмене регистрации домена при этом статусе не проводятся. Процедура снятия делегирования домена осуществляется по судебному решению. Оператор реестра или Регистратор могут установить этот статус только при условии получения соответствующего официального уведомления о начале процедуры судебного или досудебного рассмотрения спора о доменном имя. | clientChangeProhibited
serverChangeProhibited |
Система поддерживает технологические статусы, которые характеризуют переходное состояние объекта Domain протяжении всех периодов жизненного цикла. Эти статусы устанавливаются и контролируются только Оператором реестра и определены в таблице 5.
Таблица 5. Технологические статусы объекта Domain
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| ожидания создания | свидетельствует, что домен находится в процессе выполнения процедуры создания | pendingCreate |
| ожидание продолжения | свидетельствует, что домен находится в процессе выполнения процедуры продления | pendingRenew |
| ожидание перемен | свидетельствует, что домен находится в процессе выполнения процедуры изменения | pendingUpdate |
Система поддерживает информационные статусы объекта Domain протяжении всех периодов его жизненного цикла, которые определены в таблице 6.
Таблица 6. Информационные статусы объекта Domain
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| свободный | статус, во время действия которого, домен может быть зарегистрирован | специальное обозначение статуса отсутствует, проверяется отсутствием записи о доменном имя в базе данных WHOIS |
| зарезервирован | статус, во время действия которого, домен является зарезервирован согласно Правил (находится в стоп-листе) | специальное обозначение статуса отсутствует, проверяется присутствием ограничений на регистрацию согласно условиям стоп-листа |
| зарегистрирован | устанавливается после осуществления регистрации, данные о домене внесены в реестр, действует в течение срока действия регистрации доменного имени | специальное обозначение статуса отсутствует, может отображать любые текущие статусы |
| не делегировано | свидетельствует, что домен не является делегированным и ему не назначены DNS-серверы | inactive |
| запретов и ограничений нет | устанавливается при отсутствии запрещающих, других информационных статусов или статусов, свидетельствующие о том, что домен находится в процессе выполнения любой процедуры | ok |
4.4. Объекты типа Contact
Особым типом объекта Contact является объект Registrant. Объекты типа Contact предназначены для хранения информации о контактных лицах доменов (физических или юридических лиц).
Объект Domain должен иметь четыре ссылки на объекты Contact о следующие типы административных полномочий по домена:
1) Регистрант (Registrant contact) (особенности формирование данных для Registrant contact – см.. пункт 6.2)
2) административный контакт (Administrative contact – admin-c),
3) технический контакт (Technical contact – tech-c),
4) финансовый контакт (Billing contact – bill-c),
идентификатором объекта Contact является сформирован Оператором реестра ключ «Contact ID», который должен быть уникальным в реестре. Все заглавные символы идентификатора при сохранении в реестре переводятся в строчные символы.
Объект Contact может иметь два набора контактных данных (минимум один). Один набор контактных данных – локальный, содержит только символы кириллической азбуки (в кодировке UTF-8). Другой набор контактных данных – международный, содержит только символы ASCII.
Объект Contact может иметь или только локальный набор контактных данных, или только международный набор контактных данных ил и международный наборы.
Кроме атрибутов в виде информационных полей, в объекте Contact предусмотрена возможность Регистратору установления признаков, управляющие типом отражением той или иной информации при выводе информации WHOIS-сервером (если это предусмотрено Правилами).
4.4.1. Периоды жизни
Объект Contact должен быть создан в реестре перед регистрацией доменного имени, содержащей ссылку на этот Contact. Объект Contact имеет жизненный цикл с момента создания контакта до момента его удаления из реестра.
Созданный объект Contact может быть автоматически удален из реестра через 20 суток, если в течение этого периода времени ни в одном домене не явились ссылки на этот об объект. Объект Contact хранится в реестре до тех пор, пока хотя бы одно зарегистрированное доменное имя имеет ссылку на этот объект.
4.4.2. Статусы объекта Contact
Каждый контакт в каждый момент времени имеет определенный набор статусов.
Статусы, начинающиеся с приставки «server» устанавливаются Оператором реестра, статусы, начинающиеся с приставки «client» устанавливаются Регистратором. Например: статус serverUpdateProhibited и clientUpdateProhibited.
Статусы объекта Contact представлены в таблице 7.
Таблица 7. Статусы объекта Contact
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| запрет удаления | устанавливается для предотвращения удаления контакта | clientDeleteProhibited
serverDeleteProhibited |
| трансфер запрещено | устанавливается для предотвращения трансфера контакта имени | clientTransferProhibited
serverTransferProhibited |
| изменения запрещено | устанавливается когда нужно запретить внесение изменений в атрибуты объекта. Этот статус не устанавливает запрета на действия по удалению или трансфер контакта. | clientUpdateProhibited
serverUpdateProhibited |
Система поддерживает технологические статусы, которые характеризуют переходное состояние объекта Contact. Эти статусы устанавливаются и контролируются только Оператором реестра, определенные в таблице 8.
Таблица 8. Технологические статусы объекта Contact
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| ожидания создания | свидетельствует, что контакт находится в процессе выполнения процедуры создания | pendingCreate |
| ожидания трансфера | свидетельствует, что контакт находится в процессе выполнения процедуры трансфера | pendingTransfer |
| ожидание перемен | свидетельствует, что контакт находится в процессе выполнения процедуры изменения | pendingUpdate |
Система поддерживает информационные статусы объекта Contact, которые определены в таблице 9.
Таблица 9. Информационные статусы объекта Contact
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| запретов и ограничений нет | устанавливается при отсутствии запрещающих, других информационных статусов или статусов, свидетельствующие о том, что контакт находится в процессе выполнения любой процедуры | ok |
| контакт связан с объектом домен | устанавливается, если контакт связан хотя бы с одним объектом домен. | linked |
4.5. Объекты типа Host
Объекты типа Host (хост) предназначены для хранения в реестре информации о DNS-серверы, которые обслуживают делегированы домены. Внутренним идентификатором объекта Host в реестре есть ключ, состоящий из имени DNS сервера, информацию о котором содержит данный объект, и идентификатора Регистратора. Все заглавные символы идентификатора при сохранении в реестре переводятся в строчные символы.
Хостом может быть любое корректное доменное имя, включая имя в кодировке PUNYCODE.
Если доменное имя хоста входит в любой другой доменной зоны верхнего уровня кроме. УКР – каждый Регистратор имеет возможность создавать для себя такие хосты (даже с одинаковым именем).
Если доменное имя хоста относится к доменной зоны. УКР – такой хост может существовать в Системе только в одном экземпляре. Только Регистратор, который является спонсором соответствующего доменного имени может создавать, редактировать и удалять такие хосты. Другие Регистраторы могут использовать такие хосты в режиме «только чтение».
Для объектов Host, которые не базируются на доменном имени в домене. УКР процедура трансфера не предусмотрена.
Для тех объектов Host, которые основаны на доменном имени в домене. УКР , процедура трансфера будет проведена автоматически при трансфере соответствующего объекта Domain.
4.5.1. Периоды жизни
Объект Host должен быть создан в реестре перед регистрацией домена, что на него ссылку. Объект Host имеет жизненный цикл с момента создания до момента его удаления из реестра.
Созданный объект Host, который не базируется на доменном имени в домене. УКР может быть автоматически удален из реестра через 20 суток если в течение этого периода времени ни в одном домене не появилось ссылка на этот объект.
Объекты Host, основанные на доменном имени в домене. УКР автоматически удаляются из реестра при удалении соответствующего объекта Domain.
4.5.2. Статусы объекта Host
Каждый объект Host в каждый момент времени имеет определенный набор статусов.
Статусы, начинающиеся с приставки «server» устанавливаются Оператором реестра, статусы, начинающиеся с приставки «client» устанавливаются Регистратором. Например: статус serverUpdateProhibited и clientUpdateProhibited.
Статусы объекта Host представлены в таблице 10.
Таблица 10. Статусы объекта Host
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| запрет удаления | устанавливается для предотвращения удаления хоста | clientDeleteProhibited
serverDeleteProhibited |
| изменения запрещено | устанавливается когда нужно запретить внесение изменений в атрибуты объекта. Этот статус не устанавливает запрета на действия по удалению хоста. | clientUpdateProhibited
serverUpdateProhibited |
Система поддерживает технологические статусы, которые характеризуют переходное состояние объекта Host. Эти статусы устанавливаются и контролируются только Оператором реестра и определены в таблице 11.
Таблица 11. Технологические статусы объекта Host.
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| ожидания создания | свидетельствует, что хост находится в процессе выполнения процедуры создания | pendingCreate |
| ожидание перемен | свидетельствует, что хост находится в процессе выполнения процедуры изменения | pendingUpdate |
Система поддерживает информационные статусы объекта Contact, которые определены в таблице 12.
Таблица 12. Информационные статусы объекта Host
|
Статус |
Определение статуса |
Обозначения статуса в Системе |
| запретов и ограничений нет | устанавливается при отсутствии запрещающих, других информационных статусов или статусов, свидетельствующие о том, что хост находится в процессе выполнения любой процедуры | ok |
| хост связан с объектом домен | устанавливается, если хост связан хотя бы с одним объектом домен. | linked |
4.6. Объекты типа Registrar
Объекты типа Registrar предназначены для хранения информации о Регистраторов – о контактах, об авторизации, идентификаторов, статусов. Объекты Registrar регистрируются, изменяются, удаляются из реестра Оператором реестра.Определенные атрибуты объектов могут изменяться Регистратором.
4.6.1. Периоды жизни
Объект Registrar должен быть создан в реестре перед началом работы Регистратора с системой регистраций и управления доменными именами в домене. УКР после получения Регистратором аккредитации. Объект Registrar имеет жизненный цикл с момента создания до момента его удаления из реестра.
4.6.2. Статусы объекта Registrar
Объекты типа Registrar не имеют статуса, устанавливаемых Регистратором.
Статусы объекта Registrar представлены в таблице 13.
Таблица 13. Статусы объекта Registrar
|
Обозначения статуса в Системе |
Определение статуса |
Кто устанавливает |
| paidOperationsProhibited | запрещает Регистратору осуществления платных операций | Оператор реестра |
| blocked | запрещает Регистратору выполнения любых процедур | Оператор реестра |
| active | определяет факт наличия объекта в реестре и отсутствии запрещающих статусов. | Оператор реестра |
4.7. Доступность подсистемы регистраций. Доступность службы EPP – способность совокупности EPP-серверов домена. УКР выполнять удачную обработку запросов через корректные EPP-команды от аккредитованных Регистраторов, которые имеют надлежащие учетные записи для доступа к EPP-серверов реестра. Ответ должен включать соответствующие сведения из Системы в соответствии с описанием работы EPP-команд. Событие ожидания ответа на запрос EPP, при которой значение показателя параметра сервиса в пять раз превышает соответствующее необходимое значение, считается завершившейся неудачно. Если в 51% или более при проверке мониторами (отдельными программами диагностики) такие действия были неудачными, такая служба EPP считается недоступной в течение определенного времени. Минимальные значения параметров, которые обеспечивает подсистема регистраций, приведены в таблице 14.
Таблица 14. Минимальные параметры доступности службы EPP, которая должна обеспечивать подсистема регистраций
|
Параметр |
Требуемое значение параметра сервиса (ежемесячно) |
| Доступность службы EPP | = <Время простоя 864 мин. (Не менее 98%) |
| RTT команды сеанса EPP | =< 4000 мс по крайней мере для 90% команд |
| RTT команды запроса EPP | =< 2000 мс по крайней мере для 90% команд |
| RTT команды преобразования EPP | =< 4000 мс по крайней мере для 90% команд |
4.8. Требования к безопасности.
Решения по безопасности доступа к подсистеме формируются на основе инфраструктуры PKI.
Основные серверы подсистемы регистраций Оператора реестра со статусом Master предоставляют всем подчиненным серверам возможность актуализации, обработки и хранения данных о текущих регистрациях. Подчиненные серверы не доступны извне и имеют статус Hidden. Информация о расположении и адресацию серверов со статусом Hidden является строго конфиденциальной.
4.9. Набор инструментов разработки программного обеспечения EPP.
Общее описание протоколов взаимодействия, которые может использовать Регистратор для взаимодействия с реестром, структуры EPP-команд, структуры запросов и ответов, последовательности выполнения процедур с объектами в реестре предоставлено в Технических условиях взаимодействия с системой регистраций и управление доменными именами домена. УКР.
Набор инструментов разработки программного обеспечения EPP представлен в Инструкции по работе с EPP-командами.
Реализация протокола EPP обеспечивает на уровне «клиент-сервер» управления объектами, хранящихся в реестре.
4.10. Надежность подсистемы регистраций.
Надежность работы подсистемы регистраций – не менее 98%, электропитания задействовано по схеме 100% готовности использования устройств «горячей замены».
5. Подсистема DNS.
5.1. Общие сведения.
Подсистема DNS отвечает за подлинность файла зоны согласно БДД, а также отвечает на DNS-запросы пользователей, и таким образом обслуживает делегирование доменов второго уровня.
Подсистема DNS организует работу таким образом, что вторичные DNS-серверы регулярно обращаются к первичным DNS- серверов и в случае обнаружения изменений в файле зоны редактируют свой файл. Система должна предусматривать возможность принудительного дистрибуции ФЗ в подсистему DNS.
Подсистема DNS включает минимально 13 (тринадцать) серверов, расположенных на 5-ти (пяти) независимых датацентрах.
Минимально семь серверов всегда находятся в режиме Standby.
5.2. Ресурсные записи файла зоны
Формат ресурсных записей (Resource Record) базы данных DNS отвечает требованиям соответствующего RFC.
5.3. Обслуживание файла зоны.
Подсистема DNS обеспечивает динамическое обновление ФЗ.
Сохранение дампа ФЗ осуществляется ежесуточно на отдельные земни носители.
Восстановление БДД и ФЗ, в случае возникновения нештатных ситуаций, происходит из отдельных земних носителей на дисковые массивы DNS-серверов, находящихся в режиме «горячей замены ».
5.4. Доступность подсистемы DNS Доступность службы DNS – способность группы серверов доменных имен, которые определены как полномочные серверы DNS для домена. УКР, отвечать на запросы (в основном это запросы типа nslookup) других серверов и клиентов DNS или запросы от специальных мониторов по адресации и другой служебной информации доменных имен. Для того, чтобы служба DNS считалась доступной в конкретный момент времени, по крайней мере для двух полномочных серверов доменных имен, должны быть получены успешные результаты DNS-проверок. Если в 51% или более случаев DNS-проверок служба недоступна в течение определенного времени, такая служба DNS считается недоступной. Доступность сервера имен DNS – способность отдельного DNS сервера отвечать на запросы других DNS-серверов и клиентов в форме определенной Интернет-стандартами. Все зарегистрированные в уполномоченному службе DNS высшего уровня IP-адреса всех серверов доменных имен, контролируемых должны проходить проверку в индивидуальном порядке. Если в 51% или более случаев DNS проверок для определенных серверов в течение заданного времени получаемые ответы типа «undefined / unanswered» (не определено / без ответа), такой сервер имен считается недоступным. Минимальные значения параметров, которые обеспечивает подсистема DNS, приведенным в таблице 15.
Таблица 15. Минимальные параметры доступности сервера доменных имен, должна обеспечивать подсистема DNS
|
Параметр |
Требуемое значение параметра сервиса (ежемесячно) |
| Доступность службы DNS | Время простоя 0 мин. = 100% доступность |
| Доступность сервера имен DNS | =< Время простоя 432 мин. (Не менее 99%) |
| RTT для DNS / TCP | =< 1500 мс по крайней мере для 95% запросов |
| RTT для DNS / UDP | =< 1500 мс по крайней мере для 95% запросов |
| Время обновления DNS | =< 60 мин. по крайней мере для 95% тех, кто обращается за информацией |
5.5. Надежность работы DNS-серверов.
Надежность работы DNS-серверов – не менее 100%, электропитание должно быть задействовано по схеме 100% готовности использования устройств «горячей замены».
6. Служба WHOIS
6.1. Общие сведения.
Службой WHOIS используется кодировка UTF-8 (Unicode) с поддержкой и обеспечением ответов / запросов на украинском / русском языке, информация также дублируется (транслитерируется) ASCII.
Работоспособность WHOIS-серверов обеспечивается минимально 6 (шестью) серверами, расположенными на 3 -х (трех) различных датацентрах.
Минимально 3 (три) сервера находится в режиме Standby.
Используется транспортный протокол TCP / IP.
6.2. Набор данных WHOIS
Набор данных WHOIS отображает информацию на оригинальном языке регистрации доменного имени с транслитерацией в ASCII.
Один и тот же контакт (Contact ID) может быть использован для идентификации различных типов административных полномочий различных объектов Domain.
Если такой контакт (Contact ID) используется в качестве контакта Registrant, поле «Registrant Name (Organization)» отображает информацию о Регистранта объекта Domain, с которым он связан, а именно:
- если Регистрант является юридическим лицом – отображается содержание элемента;
- если Регистрант является физическим лицом – отображается содержание элемента.
Регистратор обязан при создании объекта Contact, который будет использоваться в качестве объекта Registrant осознавать и делать соответствующие записи так, что содержание элементов при создании контактов (EPP-команда CONTACT: CREATE) должно содержать корректную информацию, которая однозначно идентифицирует Регистранта определенного объекта типа Domain.
Внимание! Некорректное заполнение содержания элементов и при создании или модификации объекта Contact (EPP-команды CONTACT:CREATE или CONTACT:UPDATE), который будет использоваться в качестве объекта Registrant (Registrant Contact) является основанием для отклонения заявки или для отмены регистрации доменного имени (в некоторых случаях, определенных Правилами – для прекращения делегирования).
Последовательность данных, которые должны быть предоставлены в ответ на запрос, приведены в ниже приведенной таблице 16.
Таблица 16. Набор данных WHOIS
|
Поле |
Значение |
| Domain Name (PUNYCODE): | Имя домена в кодировке PUNYCODE |
| Domain Name (UTF8): | Имя домена в кодировке UTF8 |
| Registry Domain ID: | Идентификатор регистрации доменного имени |
| Registrar WHOIS Server: | WHOIS-сервер Регистратора |
| Updated Date: | Дата проведения модификации домена |
| Creation Date: | Дата регистрации доменного имени |
| Expiration Date: | Дата окончания действия регистрации доменного имени |
| Registry Status: | Текущий статус, в котором находится домен |
| Registrar: | Название Регистратора |
| Registrar URL: | Адрес сайта Регистратора |
| Registrar ID: | Идентификатор Регистратора |
| Registrar Abuse Contact Email: | Адрес электронной почты Регистратора, на которую следует отправлять жалобы в отношении использования домена |
| Registrar Abuse Contact Phone: | Телефон Регистратора, на которую следует звонить в случае возникновения жалоб относительно использования домена |
| Registry Registrant ID: | Идентификатор Регистранта |
| Registrant Name (Organization): | ФИО Регистранта (если частное лицо) или
Название организации Регистранта |
| Registrant Street: | Улица, номер дома с адреса Регистранта |
| Registrant City: | Город с адреса Регистранта |
| Registrant Postal Code: | Почтовый код с адреса Регистранта |
| Registrant Country: | Страна с адреса Регистранта |
| Registrant Phone: | Телефонный номер Регистранта |
| Registrant Phone Ext: | Дополнительный номер офисной АТС к телефонному номеру Регистранта |
| Registrant Fax: | Номер факса Регистранта |
| Registrant Fax Ext: | Дополнительный номер офисной АТС к факсу Регистранта |
| Registrant Email: | Адрес электронной почты Регистранта |
| Registry Admin ID: | Идентификатор администратора домена |
| Admin Name: | Имя администратора |
| Admin Organization: | Название организации администратора |
| Admin Street: | Улица, номер дома с адреса администратора |
| Admin City: | Город с адреса администратора |
| Admin Postal Code: | Почтовый код с адреса администратора |
| Admin Country: | Страна с адреса администратора |
| Admin Phone: | Телефонный номер администратора |
| Admin Phone Ext: | Дополнительный номер офисной АТС к телефонной номера администратора |
| Admin Fax: | Номер факса администратора |
| Admin Fax Ext: | Дополнительный номер офисной АТС к факсу администратора |
| Admin Email: | Адрес электронной почты администратора |
| Registry Tech ID: | Идентификатор технического контакта домена |
| Tech Name: | Имя технического контакта |
| Tech Organization: | Название организации технического контакта |
| Tech Street: | Улица, номер дома с адреса технического контакта |
| Tech City: | Город с адреса технического контакта |
| Tech Postal Code: | Почтовый код с адреса технического контакта |
| Tech Country: | Страна с адреса технического контакта |
| Tech Phone: | Номер технического контакта |
| Tech Phone Ext: | Дополнительный номер офисной АТС к телефонному номеру технического контакта |
| Tech Fax: | Номер факса технического контакта |
| Tech Fax Ext: | Дополнительный номер офисной АТС к факсу технического контакта |
| Tech Email: | Адрес электронной почты технического контакта |
| Registry Bill ID: | Идентификатор финансового контакта домена |
| Bill Name: | Имя финансового контакта |
| Bill Organization: | Название организации финансового контакта |
| Bill Street: | Улица, номер дома с адреса финансового контакта |
| Bill City: | Город с адреса финансового контакта |
| Bill Postal Code: | Почтовый код с адреса финансового контакта |
| Bill Country: | Страна с адреса финансового контакта |
| Bill Phone: | Телефонный номер финансового контакта |
| Bill Phone Ext: | Дополнительный номер офисной АТС к телефонному номеру финансового контакта |
| Bill Fax: | Номер факса финансового контакта |
| Bill Fax Ext: | Дополнительный номер офисной АТС к факсу финансового контакта |
| Bill Email: | Адрес электронной почты финансового контакта |
| NS servers (Domain servers in listed order): | Перечень серверов имен, которые обслуживают домен |
6.3. Протоколы для запросов к службе WHOIS
Дополнительно к стандартному протоколу WHOIS, запросы в службу WHOIS могут осуществляться через web-интерфейс.
6.4. Доступность службы WHOIS Доступность службы WHOIS – способность всех служб WHOIS домена. УКР предоставлять в ответ на запросы пользователей Интернета соответствующие данные по БДД. Если в 51% или в более случаях проверка WHOIS специальными мониторами показывает, что любая из служб WHOIS недоступна в течение определенного времени, такая служба WHOIS считается недоступной. Минимальные значения параметров по доступности службы WHOIS, приведенным в таблице 17.
Таблица 17. Минимальные параметры доступности службы WHOIS
|
Параметр |
Требуемое значение параметра сервиса (ежемесячно) |
| Доступность WHOIS | =< Время простоя 864 мин. (Не менее 98%) |
| RTT WHOIS-запросу | =< 2000 мс не менше чем для 95% запросов |
| Время обновления WHOIS | =< 60 мин. |
Если Регистратор создает собственную службу WHOIS (если такая возможность предусмотрена Правилами), он должен обеспечивать уровень доступности и значения параметров работы сервисов службы не менее приведенный в этом пункте.
Уровень доступности и значения параметров работы сервисов службы WHOIS Регистратора контролирует Оператор реестра с помощью штатных мониторов .
6.5. Надежность службы WHOIS
Надежность работы службы WHOIS – не менее 98%, электропитания задействовано по схеме 100% готовности использования устройств «горячей замены».
7. Трансфер доменных имен
7.1. Процедура трансфера доменного имени состоит из следующих шагов:
1) Регистрант предоставляет действующему Регистратору запрос на получение секретного кода доменного имени (authinfo)
2) действующий Регистратор должен предоставить секретный код в определенный им образ в срок не более 3 (трех) рабочих дней
3 ) Регистрант подает заявку на трансфер Регистратору, к которому осуществляется трансфер, указывая при этом секретный код домена, полученный у действующего Регистратора, а также сведения о своей личности, такие же, как для регистрации доменного имени;
4) Регистратор, к которому осуществляется трансфер отправляет регистранту на его адрес электронной почты, и на адрес электронной почты, указанным в административном контакте доменного имени (admin-c) (в случае если эти адреса электронной почты разные) письмо с информацией, им была получена заявка на трансфер соответствующего доменного имени , с запросом на подтверждение или отмену трансфера. Эта процедура подтверждения трансфера должна быть организована Регистратором таким образом, что исключает возможность подделки подтверждения;
5) Регистрант подтверждает свое намерение осуществить трансфер;
6) Регистратор, к которому осуществляется трансфер, направляет соответствующую заявку Оператору реестра;
7) Оператор реестра сообщает действующего Регистратора о получении заявки на трансфер. Действующий Регистратор имеет 5 (пять) календарных дней на то, чтобы убедиться в том, что процедура была действительно инициирована регистранта и в том, что не существует условий для отказа в осуществлении трансфера, согласно условиям договора между ним и регистранта. В случае, если действующий регистратор не убедился в том, что именно Регистрант указанного доменного имени инициировал трансфер этого доменного имени к другому Регистратора или если есть основания для отказа в трансфере согласно условиям договора между этим регистранта и действующим Регистратором, действующий Регистратор отменяет процедуру трансфера. Для этого он отправляет надлежащее извещение Оператору реестра. В случае получения уведомления (запроса) на отмену трансфера от действующего Регистратора – Оператор реестра должен сообщить Регистратора, которому было заказано трансфер, и отменить этот трансфер. В таком случае Регистратор, к которому осуществляется трансфер сообщает Регистранта о факте отмены заказанного трансфера;
8) Действующий Регистратор имеет возможность подтвердить трансфер, для этого он отправляет соответствующий сообщение (запрос) Оператору реестра. Если в срок 5 (пяти) календарных дней действующий Регистратор не отменял и не подтвердил трансфер, согласно указанной процедуре Оператор реестра автоматически позволяет и завершает трансфер, то есть изменяет запись о Регистратора доменного имени, о чем сообщает действующего Регистратора и Регистратора, которому исполнился трансфер ;
9) Регистратор, в адрес которого осуществлен трансфер, сообщает Регистранту о том, что процедура трансфера состоялась (завершилась) успешно.
7.2. Процедура трансфера при принудительной смене Регистратора.
Процедура принудительного (по решению Администратора) трансфера применяется в случае временного или полного прекращения осуществления Регистратором своих обязанностей.
С целью обеспечения бесперебойного обслуживания регистранта:
1) все доменные имена, связанные с БДР с идентификатором такого Регистратора получают статус-кво, независимо от окончания срока делегирования;
2) в случае отказа от продления исполнения обязанностей Регистратора или невозможности / нежелания устранения таким Регистратором замечаний и оснований приостановления его аккредитации, он будет лишен аккредитации и соответствующим образом проинформированы о таком решении администратора, при этом доменные имена регистранта переводятся на аккаунт виртуального Регистратора.
3), после чего Администратор через аккаунт виртуального Регистратора сообщает регистранта о возможности самостоятельно выбрать кому из аккредитованных Регистраторов будет осуществлен принудительный трансфер их доменных имен на обслуживание. После получения соответствующих запросов о трансфере от выбранных регистранта аккредитованных Регистраторов Оператор реестра осуществляет проверку правомочности такого трансфера согласно подпункту 4 пункта 7.1 настоящего Технического регламента и осуществляет трансфер на аккаунт избранное регистранта Регистратора.
8. Защита информации в Системе
8.1. Информация, требование относительно защиты которой установлена законом, в том числе персональные данные, должна обрабатываться в системе с применением комплексной системы защиты информации с подтвержденным соответствием (далее – КСЗИ).
8.2. Построение КСЗИ осуществляется согласно Правилам, утвержденным постановлением Кабинета Министров Украины от 29 марта 2006 года № 373, в порядке, установленном нормативным документом по технической защите информации НД ТЗИ 3.7-003-05 «Порядок проведения работ по созданию комплексной системы защиты информации в информационно- телекоммуникационной системе ».
8.3. Требования к КСЗИ формируются в техническом нанесенные на ее создание в системе, которая подается вместе с заявлением организации-претендента, желающего стать Оператором реестра домена. УКР, разрабатывается с учетом технических требований к Оператору реестра домена. УКР и дальнейшем дорабатывается и КСЗИ внедряется в Системе с учетом требований законодательства.