Skip to main content

Nuevos gTLD seguros y protegidos: ICANN busca Operadores de Registro de Respaldo | (Operadores de Registro Back-End de Emergencia o "EBERO", por sus siglas en inglés")

Esta página está disponible en:

Actualizado el 29 de noviembre de 2011
23 de noviembre de 2011

El día de la fecha ICANN presenta una Solicitud de Información (RFI, por sus siglas en inglés) [PDF, 660 KB] para identificar potenciales Operadores de Registro Back-End de Emergencia (EBERO).

Una de las misiones centrales de ICANN es preservar la seguridad y estabilidad operativas de Internet, respaldando al mismo tiempo la competencia abierta. Con el inminente lanzamiento del programa para Nuevos Dominios genéricos de Alto Nivel (nuevos gTLD), Internet se encontrará con una cantidad de nuevos operadores de registro gTLD. Si bien todos los encuestados deben cumplir con los requisitos técnicos, operativos y financieros (véase la Guía de Solicitantes de gTLD: http://www.icann.org/en/topics/new-gtlds/dag-en.htm), la comunidad desarrolló un programa para el nuevo gTLD que incluye una disposición para un proceso de respaldo. El EBERO está diseñado para ser activado cuando un operador de registro necesite asistencia para realizar funciones críticas de registro durante un periodo de tiempo, o en los casos de transición de un operador de registro a otro.

Se espera que los candidatos cumplan con los requisitos descritos en el RFI, que exige, por ejemplo, al menos tres años de experiencia operando Servicios de Nombre de Dominio (DNS, por sus siglas en inglés) y un año de experiencia operando Servicios de Directorio de Datos de Registro (RDDS, por sus siglas en inglés) y servicios de Protocolo de Aprovisionamiento Extensible (EPP, por sus siglas en inglés). Además de los requisitos técnicos, ICANN busca candidatos de regiones de diversidad geográfica, con el fin de brindar un servicio local a los registros de todas las regiones y proveer sitios alternativos en caso de desastres locales.

ICANN espera recibir información amplia e integral por parte de los candidatos potenciales. Se iniciarán negociaciones con algunos de los encuestados del RFI que proporcionen información amplia e integral, con el fin de crear detalles de proceso y firmar un contrato para la provisión de servicios back-end. La fecha límite para el envío de las respuestas es el día 5 de diciembre de 2011 - 5:00PM Pacific Time. Por favor, envíe su información a ebero@icann.org. No se considerarán las respuestas que se envíen después de la fecha límite.

Vistazo general de la agenda de actividades de la RFI:

Solicitud de propuestas presentada por ICANN 14 de septiembre de 2011
Preguntas y Respuestas de los encuestados. Teleconferencia 16 de noviembre de 2011, o alrededor de esa fecha
Questions and Answers: Emergency Back-end Registry Operators RFI (EBERO RFI) [PDF, 411 KB]
Entrega de propuestas por escrito 30 de noviembre de 2011, 23:59 hs UTC
Extendió hasta el 5 de diciembre de 2011 - 5:00PM Pacific Time

1. ¿Qué es un registro?

Un "Registro" es la base de datos maestra autorizada de todos los nombres de dominio registrados en cada Dominio de Alto Nivel. El operador de registro mantiene la base de datos maestra y también genera el "archivo de zona", que permite a las computadoras dirigir el tráfico de Internet desde y hacia dominios de alto nivel en cualquier parte del mundo.

2. ¿Qué es un Operador de Emergencia?

El Operador de Emergencia u Operador de Registro Back-End es una organización que se ha asociado con ICANN para proveer servicios de registro en caso de que algún registro se vea impedido de realizar sus operaciones. Los operadores de emergencia serán seleccionados por ICANN basándose en los criterios detallados en el RFI.

3. ¿Qué sucede cuando una operación de registro gTLD falla, ya sea financieramente o debido a una emergencia técnica?

Si ocurriera una emergencia y un Registro se viera imposibilitado de proveer servicios críticos, el Operador de Emergencia tendrá la función de asegurar la continuidad de esos servicios. Este proceso de transición de emergencia de proveedores está administrado por ICANN y requiere que un gran número de proveedores se encuentre disponible para tomar una función en caso de que un proveedor no pueda tomar la operación a tiempo o si surgiera un conflicto de intereses.

4. ¿Cuáles son las funciones críticas de registro?

Las funciones críticas para la operación de un registro gTLD (es decir, aquellos que provee el EBERO) son:

  • Resolución del Sistema de Nombres de Dominio (DNS);
  • La zona debidamente firmada (si lo ofrece el registro) de las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC);
  • Sistema de Registro Compartido (SRS), generalmente mediante el Protocolo de Aprovisionamiento Extensible (EPP);
  • Servicios de Directorio de Datos de Registro (RDDS), por ejemplo, los que WHOIS proporcionó tanto a través del puerto 43 como mediante un servicio basado en la web;
  • Custodio de Datos de Registro.

5. ¿Qué tipo de información está solicitando ICANN y quiénes deberían responder?

Los encuestados deberán ser partes interesadas en comprometerse como potenciales Operadores de Registro Back-End de Emergencia. El RFI cubre varias áreas, pero los encuestados deberán estar preparados para discutir los siguientes temas:

  • Capacidades y experiencia en las funciones críticas de registro;
  • Conceptos de Transición de Registro, experiencia, SLA, y casos de uso;
  • Tarifa de precios para la provisión de funciones críticas de registro;
  • Perfil de la organización, liderazgo y recursos de los encuestados.

Información de referencia

En abril de 2009, ICANN publicó el Plan de Continuidad de Registros gTLD de ICANN: http://www.icann.org/en/registries/continuity/. Este documento describe un Esquema de Continuidad de Registros gTLD desarrollado en colaboración con los registros experimentados gTLD y ccTLD, y los miembros de la comunidad técnica. Los objetivos generales del Esquema de Continuidad de Registro de ICANN son:

  1. la protección de los registrantes existentes; y
  2. asegurar la confiabilidad del DNS.

El Esquema de Continuidad de Registros reconoció la necesidad de una capacidad reglamentaria para continuar con los servicios en caso de falla de un Operador de Registro. Introdujo el concepto de Operador Back-End y las complicaciones intrínsecas de que exista un único operador back-up que respalde todas las capacidades existentes de los distintos modelos de registro. En vista de estas complicaciones, se estableció y definió el concepto de identificación del nivel básico de "funciones críticas", que exige mantener la cantidad mínima servicios operativos de un Dominio de Alto Nivel.

En mayo de 2010, ICANN publicó un Memorando Explicativo para los Nuevos Dominios de Alto Nivel "Modelo para los Procesos de Transición de Registro" (RyTP, por sus siglas en inglés): http://www.icann.org/en/topics/new-gtlds/registry-transition-processes-clean-30may11-en.pdf [PDF, 747 KB]. Este documento elabora con más profundidad el concepto de funciones críticas necesarias para el mantenimiento de los servicios de Dominios de Alto Nivel, y discute los tipos de transición entre un Operador de Registro y otro. El concepto de Operador de Registro Back-End de Emergencia se introdujo también para respaldar las funciones críticas TLD de los Operadores de Registro que presentaran fallas, cuando no se cuente con un Operador de Registro sucesor que esté asignado inmediatamente.

Enlaces a información pertinente:


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."