Процессы передачи регистратуры

Определения

В контексте настоящего документа перечисленные ниже термины имеют следующие определения:

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

Критически важные функции:функции, которые критически важны для деятельности регистратуры gTLD:

1. Разрешение DNS
2. Правильное подписание зоны с помощью DNSSEC (если DNSSEC предлагается регистратурой)
3. Общая система регистрации (SRS), обычно посредством протокола EPP
4. Служба каталогов регистрационных данных (RDDS), например, предоставление WHOIS как через порт 43, так и через веб-интерфейс.
5. Временное депонирование данных регистратурой

Передача регистратуры: изменение стороны в Соглашении об администрировании домена верхнего уровня gTLD с ICANN. Примеры обстоятельств, приводящих к передаче регистратуры: изменение наименования организации, управляющей gTLD, продажа или перемещение регистратуры, нарушение действующей регистратурой Соглашения об администрировании домена верхнего уровня и так далее.

Регистратура-преемница: новая сторона в Соглашении об администрировании домена верхнего уровня gTLD с ICANN после передачи регистратуры.

Процессы передачи регистратуры

Как указано в разделе 9.2 документа «Подтверждение обязательств», одно из обязательств ICANN:

сохранение безопасности, стабильности и отказоустойчивости [DNS].¹

Устав ICANN определяет основные ценности организации. Основная ценность № 1 имеет следующую формулировку:

Сохранение и повышение операционной стабильности, надежности, безопасности и глобальной функциональной совместимости интернета.²

В плане операционной деятельности ICANN на 2006–2007 годы (раздел 1.1.2) указано, что ICANN:

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

Этот процесс был создан в 2006–2007 финансовых годах и постоянно обновляется; в настоящее время его название — Концепция обеспечения непрерывности работы регистратур ⁴. Процесс управления инцидентами и событиями, описанный в Концепции обеспечения непрерывности работы регистратур, определяет необходимость урегулирования ситуаций, когда критически важные функции регистратуры испытывают негативное влияние.

Стремясь соблюдать свою основную ценность № 1, а также благодаря разработке Концепции обеспечения непрерывности работы регистратур ICANN выявила потребность определить процессы передачи gTLD безопасным, стабильным и надежным образом, минимизируя при этом последствия для владельцев доменов и пользователей gTLD и обеспечивая транспарентность для сторон, участвующих в передаче.

Разработаны и описаны в настоящем документе следующие три процесса:

1. Процесс передачи регистратуры с предложенной регистратурой-преемницей
2. Процесс передачи регистратуры с запросом предложений (RFP)
3. Процесс временной передачи Резервному оператору регистратуры

 

1. Процесс передачи регистратуры с предложенной регистратурой-преемницей

   Этот процесс будет использоваться в тех случаях, когда регистратура просит ICANN перезаключить свое Соглашение об администрировании домена верхнего уровня с потенциальной регистратурой-преемницей (например, при приобретении регистратуры, изменении наименования организации, передаче поставщику для сохранения непрерывности оказания услуг регистратуры). Данный процесс также будет использоваться, если по истечении срока действия Соглашения об администрировании домена верхнего уровня или вследствие получения предписания суда, обладающего юридическими полномочиями в данной юрисдикции, соответствующее правительство или государственный орган отзывает свою поддержку оператора регистратуры gTLD, являющегося географическим наименованием, и предложит регистратуру-преемницу. Схема этого процесса представлена в Приложении 2.

   При оценке предложенной регистратуры-преемницы всегда будет осуществляться проверка с необходимой степенью тщательности. Например, в случае изменения наименования основное внимание при проверке будет уделено законности, чтобы гарантировать невозможность перехвата домена верхнего уровня (TLD).

   После получении запроса от действующей регистратуры, правительства или государственного органа (в случае географических gTLD) ICANN оценивает ситуацию на основе собранных фактов, переговоров с действующей регистратурой и правительством или государственным органом (если применимо) и анализа Соглашения об администрировании домена верхнего уровня. В центре внимания при этой оценке будут находиться следующие вопросы:

   • Изменится ли субъект, являющийся поставщиком каких-либо конечных услуг регистратуры?
   • Есть ли у этого TLD соответствующее сообщество, с которым необходимо проконсультироваться?
   • Является ли gTLD географическим наименованием согласно определению в Руководстве кандидата? (Или, требовалась ли поддержка со стороны правительства во время подачи заявки?)
   • Имеются ли в Соглашении об администрировании домена верхнего уровня какие-то ограничения, способные повлиять на передачу?

   Кроме того, ICANN выполняет оценку рисков gTLD, действующей регистратуры и поставщика конечных услуг регистратуры (если есть изменения в этом отношении). При оценке основное внимание уделяется особенностям как всех трех субъектов в совокупности, так и каждого из трех по отдельности. Например, проверяется интенсивность использования gTLD финансовыми учреждениями или для электронной коммерции; высокая интенсивность может стать причиной более строгих мер безопасности при передаче.

   После выполнения этих оценок предлагаемая регистратура-преемница проверяется на предмет наличия внешней поддержки, если таковая необходима. Если gTLD — географическое наименование согласно определению в Руководстве кандидата программы New gTLD, тогда ICANN дает указание предложенной регистратуре-преемнице заручиться поддержкой соответствующего правительства или государственного органа и получить документацию, свидетельствующую о поддержке/отсутствии возражений. Если в Соглашении об администрировании домена верхнего уровня указано какое-либо сообщество, с которым необходимо проконсультироваться при передаче, ICANN проводит на данном этапе консультации с таким сообществом. В таких случаях для продолжения процесса передачи необходима поддержка предлагаемой регистратуры-преемницы со стороны соответствующего сообщества.

   Если предлагаемая регистратура-преемница пользуется необходимой поддержкой или поддержка не требуется, ICANN приступает к оценке кандидата, используя процесс, который определен в Руководстве кандидата программы New gTLD. На основании критериев, изложенных в Таблице оценки потенциальной регистратуры (см. Приложение 1), ICANN определяет совокупность необходимых оценок, собирает информацию и получает плату за рассмотрение заявки. Эта плата покрывает расходы на выполнение оценок сторонними поставщиками.

   Оценки, выполняемые внутри ICANN, бесплатны для кандидата.

   Объем оценок зависит от необходимой в каждом случае степени тщательности. Три степени глубины проверок представлены в Приложении 1. Наиболее глубокий уровень (то есть полная проверка) будет аналогичен по объему проверке кандидатов программы New gTLD. Этот анализ будет выполнять одна из трех фирм, привлеченных для оценки заявок на новые gTLD. Следующий уровень (то есть ограниченная проверка)представляет собой более узкую проверку. Например, техническая оценка и оценка операций могли бы заключаться в проверке того, что новая организация использует соглашения, аналогичные действующим соглашениям с существующим оператором конечных услуг регистратуры. Третий уровень (то есть минимальная проверка) соответствует очень узкой по объему проверке, которая выполняется внутри ICANN.

   Затем поставщик услуг оценки выполняет необходимый анализ и представляет отчет кандидату и ICANN. Если кандидат не соответствует критериям оценки, ему предоставляется возможность устранить недостатки в течение трех недель после того, как он не смог успешно пройти оценку (расширенная оценка). Если кандидат не смог пройти оценку во второй раз, процесс заканчивается без передачи с возвратом кандидату полученной суммы за вычетом фактических расходов на оценку.

   Если потенциальная регистратура-преемница успешно проходит оценку, ICANN стремится получить необходимые разрешения и в случае их получения заключает с регистратурой-преемницей Соглашение об администрировании домена верхнего уровня. Если кандидатура потенциальной регистратуры-преемницы не одобрена, процесс заканчивается без передачи.

   После одобрения регистратуры-преемницы результат передается по внутренним и внешним каналам связи необходимым и надлежащим образом. Если передача не подразумевает замены оператора конечных услуг регистратуры, регистратура-преемница впоследствии обязана направить в Администрацию адресного пространства интернета (IANA) запрос на изменение организации-спонсора.

   Если меняется организация, являющаяся оператором конечных услуг регистратуры, регистратура-преемница должна пройти тестирование функциональности перед запуском согласно Руководству кандидата программы New gTLD. Это имеет место, когда поставщик конечных услуг — оператор регистратуры или подрядчик оператора регистратуры. После успешного тестирования новый оператор регистратуры обязан обратиться в IANA и приступить к изменению организации-спонсора в базе данных корневой зоны IANA. После завершения этого этапа взаимодействия с IANA оператор регистратуры-преемницы выполняет перенос данных и услуг, а затем направляет в IANA запрос на внесение изменений в регистрационные записи DNS и RDDS (WHOIS).

   Заключительные этапы процесса передачи — передача необходимой и целесообразной информации по внутренним и внешним каналам связи и обновление корпорацией ICANN своей общедоступной и внутренней информации о регистратуре gTLD.

2. Процесс передачи регистратуры с RFP

   Этот процесс будет использоваться главным образом тогда, когда регистратура gTLD нарушает Соглашение об администрировании домена верхнего уровня (что приводит к его расторжению) и не указывает регистратуру-преемницу. Данный процесс также будет использоваться, если по истечении срока действия Соглашения об администрировании домена верхнего уровня или вследствие получения предписания суда, обладающего юридическими полномочиями в данной юрисдикции, соответствующее правительство или государственный орган отзывает свою поддержку оператора регистратуры географического gTLD, не предлагая регистратуру-преемницу. Схема этого процесса представлена в Приложении 3.

   Данный процесс аналогичен описанному выше процессу передачи регистратуры с предложенной регистратурой-преемницей, за исключением того, что он содержит подчиненный процесс Запроса предложений (RFP). Цель RFP — получить оформленные заявки от потенциальных регистратур-преемниц.

   Процесс RFP начинается после оценки рисков gTLD, так как она может привести к выводам, которые важно раскрыть в RFP. В документе RFP описываются услуги, которые должна оказывать регистратура-преемница. Кроме того, в RFP указываются ожидаемые расходы на услуги оценки, определяя минимально приемлемое экономическое предложение кандидата.

   Если gTLD, которым управляет регистратура, является географическим наименованием согласно определению в Руководстве кандидата программы New gTLD, ICANN консультируется с соответствующим правительством или государственным органом, предлагая внести вклад в подготовку RFP. Кроме того, если Соглашение об администрировании домена верхнего уровня содержит положение, требующее, чтобы ICANN перед передачей проконсультировалась с конкретным сообществом при оценке потенциальной регистратуры-преемницы, такие консультации проводятся на данном этапе процесса.

   Сразу после утверждения RFP, этот запрос публикуется на 45 дней, и кандидаты до завершения этого срока опубликования могут направлять свои ответы.

   После этого кандидат, предлагающий максимальный размер выплаты первоначальной регистратуре, проверяется на предмет необходимой поддержки и проходит оценку согласно процессу передачи регистратуры с предложенной регистратурой-преемницей. Такой механизм отбора гарантирует максимальное возмещение первоначальной регистратуре и минимизирует лишние расходы кандидатов, проигравших конкурс, одновременно обеспечивая соответствие победителя установленным требованиям.

   Если кандидат пользуется необходимой поддержкой (или поддержка не требуется) и успешно проходит оценку, процесс продолжается так, как описано в вышеупомянутом процессе. Если кандидат не пользуется необходимой поддержкой или не проходит оценку, рассматривается кандидат, занявший второе место, и так далее, пока не будет определен кандидат, имеющий необходимую поддержку и отвечающий критериям оценки, или не будут исчерпаны все поступившие предложения.

   Если в течение процесса RFP не поступило ни одного предложения или если нет кандидатов, соответствующих установленным требованиям, из-за отсутствия надлежащей поддержки или невозможности успешно пройти оценку, запускается процесс прекращения работы TLD, чтобы закрыть этот gTLD. Если состоятельный кандидат обнаружен после завершения процесса RFP, в течение которого не удалось определить регистратуру-преемницу, его кандидатуру можно рассмотреть, исходя из текущей ситуации и того, что такое решение будет служить общественным интересам.

   Если посредством данного процесса определена соответствующая установленным требованиям регистратура-преемница, все полученные денежные средства за вычетом расходов на оценку и невыплаченного комиссионного вознаграждения перечисляются оператору регистратуры, избавляющемуся от gTLD.

3. Процесс временной передачи Резервному оператору регистратуры

   Этот процесс будет использоваться для новых gTLD главным образом при выполнении двух следующих условий: (1) регистратура нарушает Соглашение об администрировании домена верхнего уровня, и (2) качество выполнения критически важной функции ниже критических порогов, установленных в Соглашении об администрировании домена верхнего уровня, в результате чего возникает неприемлемый риск, как описано ниже. В таком случае выполнение операций можно перепоручить резервному поставщику конечных услуг регистратуры до восстановления нормального функционирования оператора регистратуры. Такая временная передача также может осуществляться по запросу оператора регистратуры, если ему известно о своей неспособности сейчас или в ближайшем будущем надлежащим образом выполнять критически важные функции.

   Результаты измерений, позволяющие обнаружить достижение критического порога выполнения критически важных функций (кроме временного депонирования данных), будут поступать из системы мониторинга SLA (соглашения об уровне обслуживания) регистратуры, используемой ICANN согласно положениям Соглашения об администрировании домена верхнего уровня.

   Также следует отметить, что данный процесс передачи является временной мерой для защиты владельцев доменов и пользователей gTLD. Временная передача критически важных функций осуществляется на срок, необходимый для решения основных проблем или для передачи gTLD другому оператору с использованием одного из описанных ранее процессов передачи регистратуры. Чтобы обеспечить возможность этой временной передачи, Соглашение об администрировании домена верхнего уровня для новых gTLD содержит заранее полученное согласие оператора регистратуры на внесение изменений в регистрационные записи DNS и RDDS (WHOIS) базы данных IANA в экстренном случае.

   Как только оператор регистратуры будет готов возобновить выполнение операций и устранит все проблемы, которые могли являться причиной нарушения, он может начать процесс передачи регистратуры с предложенной регистратурой-преемницей для возвращения контроля над gTLD. Эта возможность доступна оператору регистратуры до истечения установленного срока устранения нарушения. В рамках данного процесса оператор регистратуры указывает себя в качестве регистратуры-преемницы.

   ICANN поддерживает в актуальном состоянии договоры по крайней мере с двумя заранее выбранными Резервными операторами регистратуры (Резервными операторами). Процесс RFP для определения Резервных операторов осуществляется каждые пять лет, чтобы продлить договоры и/или найти и выбрать новых Резервных операторов. Среди выбранных Резервных операторов обеспечивается географическое разнообразие, чтобы повысить безотказность работы Резервных операторов в целом; если в регионе произойдет катастрофа, влияющая на способность одного из Резервных операторов вести свою деятельность, другой Резервный оператор по-прежнему будет готов к работе. Основные квалификационные требования к Резервным операторам — не менее чем трехлетний опыт работы с DNS и опыт управления службами RDDS (например, WHOIS) и EPP по крайней мере в течение года.

   ICANN осуществляет выбор Резервных операторов, исходя из ценности: наилучшего сочетания услуг и цены. Финансирование использования услуг Резервного оператора в каждом конкретном случае будет осуществляться с помощью соответствующих механизмов обеспечения непрерывности деятельности регистратур, которые должны быть у операторов регистратур новых gTLD согласно Спецификации 8 Соглашения об администрировании домена верхнего уровня.

   Оценка кандидатов на исполнение обязанностей Резервных операторов будет выполняться с использованием процессов, аналогичных процессам для новых gTLD, включая тестирование функциональности инфраструктуры, которая должна использоваться в экстренном случае, перед запуском. На этапе оценки инфраструктура должна находиться в работоспособном состоянии. ICANN вправе периодически требовать проведения проверки возможностей и готовности Резервного оператора принять регистратуру и действовать в случае экстренной передачи.

   Как только ICANN выберет Резервных операторов, они предложат заключить упрощенное соглашение между регистратурой и регистратором всем регистраторам, которые позволят Резервным операторам выполнять функции SRS в течение процесса временной передачи. Регистраторам будет рекомендовано связать себя обязательствами перед Резервными операторами до возникновения экстренной ситуации, чтобы обеспечить свою готовность к работе (то есть, чтобы было заключено соглашение, заблаговременно разосланы учетные данные для доступа к SRS, выполнено тестирование функциональных возможностей совместно с Резервными операторами и так далее) в случае экстренной передачи конкретного gTLD.

   При возникновении экстренной ситуации, в которой требуются услуги Резервного оператора, ICANN приглашает одного из Резервных операторов. Если выбранный поставщик не в состоянии взять на себя управление или существует конфликт интересов, ICANN обращается к другому поставщику. Действующий Резервный оператор имеет право подать заявку и стать в конечном итоге регистратурой-преемницей или оператором конечных услуг регистратуры gTLD в случае передачи регистратуры в соответствии со стандартными правилами RFP. Чтобы процесс конкурсного отбора был сбалансированным, действующий Резервный оператор предоставляет ICANN оперативную информацию о функционировании gTLD, которая должна быть включена в RFP.

   Возможны ситуации, когда в качестве Резервного оператора выступает текущий Оператор конечных услуг регистратуры, если:

   • оператор регистратуры попросил ICANN в экстренном случае осуществить передачу Оператору конечных услуг регистратуры как Резервному оператору;
   • текущий Оператор конечных услуг регистратуры выполняет критически важные функции согласно положениям об уровне обслуживания, которые определены в Соглашении об администрировании домена верхнего уровня;
   • компания Оператора конечных услуг регистратуры не связана и не аффилирована с оператором регистратуры; и
   • Оператор конечных услуг регистратуры согласен управлять gTLD на таких же или лучших условиях, что и Резервные операторы.

   Тогда ICANN по своему единоличному усмотрению вправе предложить Оператору конечных услуг регистратуры выполнять функции регистратуры для данного gTLD. В таком случае Оператору конечных услуг регистратуры, выступающему в качестве Резервного оператора, выплачиваются денежные средства через механизм обеспечения непрерывности деятельности регистратур.

   Резервные операторы выполняют следующие требования к уровню обслуживания (SLR) при активации каждой критически важной функции.

   Критически важная функция	Требование к уровню обслуживания
   DNS / DNSSEC	4 часа после получения запроса от ICANN
   RDDS	24 часа после получения данных
   SRS (EPP)*	72 часа после получения данных
   Временное депонирование данных	24 часа после начала функционирования SRS

   *Серверы SRS готовы к приему запросов от регистраторов.

   Резервные операторы ведут архив, по крайней мере, ежедневных файлов зон для всех gTLD, чтобы позволить выбранному Резервному оператору быстро возобновить обслуживание DNS в экстренном случае. Что касается остальных критически важных функций, данные предоставляет текущая регистратура и/или они будут получены из временного депозитария данных.

   Депозитарии новых gTLD будут обязаны выполнять требование о передаче данных gTLD по запросу в течение 24 часов, в экстренном случае.

   В период выполнения критически важных функций gTLD в экстренном режиме Резервный оператор не выставляет регистраторам счета на оплату операций в SRS.

   Как правило, Резервный оператор не будет принимать от регистраторов запросы на регистрацию новых доменов, продление срока регистрации, передачу и удаление доменов. Однако в определенных исключительных случаях запросы на вышеупомянутые операции будут приниматься, например, в рамках ускоренного процесса обеспечения безопасности регистратур ⁵, Единой политики разрешения споров о доменных именах (UDRP) или любых других процедур ICANN по урегулированию разногласий в отношении доменных имен. ICANN может одобрить операции массового переноса доменов, спонсируемых регистраторами, которые больше не в состоянии их обслуживать (например, когда регистратор лишился аккредитации). Резервный оператор не выполняет операций, связанных с истечением срока регистрации или автоматическим продлением доменов, и включает в состав выводимых данных RDDS (например, WHOIS) краткое разъяснение причин (утвержденное ICANN), по которым дата истечения срока регистрации предшествует текущей дате, перед отказом от ответственности (если таковой имеется), согласно разделу 1.1 Спецификации 4 Соглашения об администрировании домена верхнего уровня. Остальные стандартные операции в SRS для доменных имен, контактных данных и хостов (RFC 5730-34, 5910) разрешены. Резервный оператор сотрудничает со всеми аккредитованными регистраторами, у которых есть спонсируемые домены в gTLD.

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

   Схема процесса, который необходимо соблюдать в экстренном случае, представлена в Приложении 4.

   При передаче от Резервного оператора обратно предыдущему оператору регистратуры или новому оператору регистратуры Резервный оператор действует в сотрудничестве с новым оператором, чтобы осуществить передачу с минимальными последствиями для владельцев доменов и пользователей gTLD.

   ICANN контролирует и документирует процессы экстренной передачи. Будут разработаны показатели, характеризующие качество выполнения оператором регистратуры и EBERO пяти критически важных функций. ICANN намерена отслеживать, что оправдало себя на практике, а что можно улучшить, чтобы предлагать изменения этого процесса.

---

• Appendix 1 | Prospective Registry Evaluation Matrix
• Appendix 2-1 | Registry Transition Process with Proposed Successor
• Appendix 2-2 | Registry Transition Process with Proposed Successor - Check Support
• Appendix 2-3 | Registry Transition Process with Proposed Successor - Evaluate
• Appendix 2-4 | Registry Transition Process with Proposed Successor - Communicate
• Appendix 3-1 | Registry Transition Process with Request for Proposals
• Appendix 3-2 | Registry Transition Process with Request for Proposals - Check Support
• Appendix 3-3 | Registry Transition Process with Request for Proposals - Evaluate
• Appendix 3-4 | Registry Transition Process with Request for Proposals - RFP
• Appendix 3-5 | Registry Transition Process with Request for Proposals - Communicate
• Appendix 4-1 | Emergency Back-End Registry Operator Temporary Transition Process
• Appendix 4-2 | Emergency Back-End Registry Operator Transition Process - DNS
• Appendix 4-3 | Emergency Back-End Registry Operator Transition Process - RDDS
• Appendix 4-4 | Emergency Back-End Registry Operator Transition Process - SRS
• Appendix 4-5 | Emergency Back-End Registry Operator Transition Process - Data Escrow
• Appendix 4-6 | Emergency Back-End Registry Operator Transition Process - Communicate

---

¹ ICANN. (2009, September 30). Affirmation of Commitments. Retrieved from http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.htm

² ICANN. (2009, September 30). ICANN bylaws. Retrieved from http://www.icann.org/en/general/bylaws.htm#I

³ ICANN. (2006, June 22). 2006-2007 ICANN Operating Plan. Retrieved from http://www.icann.org/announcements/operating-plan-22jun06.htm

⁴ ICANN. (2009). gTLD Registry Continuity. Retrieved from http://www.icann.org/en/registries/continuity/

⁵ http://icann.org/en/registries/ersr/