Технічний регламент
Технічний регламент домену .УКР (версія 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:name> і <contact:org> при створенні або модифікації об’єкту 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. Вимоги до КСЗІ формуються у технічному завдані на її створення в Системі, яка подається разом з заявою організації-претендента, що бажає стати Оператором реєстру домену .УКР, розробляється з урахуванням технічних вимог до Оператора реєстру домену. УКР і надалі доопрацьовується та КСЗІ впроваджується в Системі з урахуванням вимог законодавства.