Skip to main content

Nouveaux gTLD sûrs et sécurisés : ICANN cherche des opérateurs de registre de secours back-up | (Opérateurs de registre de secours back-end ou « EBERO »)

Cette page est disponible en:

Mis à jour le 29 novembre 2011
23 novembre 2011

L'ICANN publie aujourd'hui une demande d'information (Request for Information (RFI) [PDF, 660 KB] pour identifier de potentiels opérateurs de registre de secours back-end (EBERO). 

Une des missions fondamentales de l'ICANN est de préserver la sécurité opérationnelle et la stabilité de l'Internet tout en soutenant la libre concurrence. Avec le prochain lancement du nouveau programme des domaines génériques de premier niveau (gTLD), l'Internet va voir surgir de nombreux opérateurs de registres gTLD. Bien que tous les candidats doivent respecter certains critères techniques, opératifs et financiers (voir le guide du candidat de gTLD ─ http://www.icann.org/en/topics/new-gtlds/dag-en.htm) le programme des nouveaux gTLD développé par la communauté comprend tous les aspects nécessaires à un processus de back-up. L'EBERO est conçu pour être activé si un opérateur de registre a besoin d'aide pour soutenir les fonctions essentielles d'un registre pour une période de temps donnée ou dans le cas d'une transition d'un opérateur de registre à un autre.

Les candidats doivent répondre aux exigences énoncées dans la RFI, qui requiert, par exemple, au moins trois ans d'expérience dans l'exploitation des services DNS et un an d'expérience dans le fonctionnement des services d'annuaire d'enregistrement de données (RDDS) et des services de protocole d'approvisionnement extensible (Extensible Provisioning Protocol - EPP). Outre les exigences techniques, l'ICANN cherche à réunir des candidats issus de diverses régions géographiques, afin de fournir un service local aux registres de toutes les régions et de garantir l'existence d'autres sites en cas de catastrophes locales.

L'ICANN est impatient de recevoir l'information complète des candidats potentiels. Les négociations avec les participants à la demande d'information (RFI) qui fourniront des informations complètes seront entamées dans le but de mettre en place les détails du processus et de conclure un accord pour fournir des services back-end. La date limite de réception des réponses est le 5 décembre 2011 - 5:00PM Pacific Time. Veuillez adresser vos informations à ebero@icann.org. Les réponses reçues après la date limite ne seront pas acceptées.

Calendrier des activités de RFI :

Demande de propositions émise par l'ICANN 14 septembre 2011
Téléconférence, questions et réponses des participants Le 16 novembre 2011 ou aux environs de cette date
Questions and Answers: Emergency Back-end Registry Operators RFI (EBERO RFI) [PDF, 411 KB]
Propositions écrites 30 novembre 2011 23h59
Prolongée jusqu'au 5 décembre 2011 - 5:00PM Pacific Time

1. Qu'est-ce qu'un registre ?

Le « registre » est la base de données principale faisant autorité et regroupant tous les noms de domaine enregistrés dans chaque domaine de premier niveau. L'opérateur de registre conserve la base de données principale et génère le « fichier de zone » permettant aux ordinateurs d'acheminer le trafic Internet depuis et vers les domaines de premier niveau partout dans le monde.

2. Qu'est-ce qu'un opérateur d'urgence ?

Un opérateur d'urgence ou opérateur de registre back-end est une organisation qui a conclu un partenariat avec l'ICANN pour fournir des services de registre au cas où un registre cesserait de fonctionner. Les opérateurs d'urgence seront sélectionnés par l'ICANN en se basant sur des critères établis dans la demande d'information (RFI).

3. Que se passe-t-il quand un registre gTLD cesse de fonctionner à cause d'un problème financier ou d'une urgence technique ?

Si une urgence survient et qu'un registre est incapable de fournir des services essentiels, la fonction de l'opérateur d'urgence sera d'assurer la continuité des services. Ce processus de transition en cas d'urgence est géré par l'ICANN et requiert de multiples fournisseurs afin de pouvoir prendre la relève au cas où un fournisseur ne serait pas capable de prendre les opérations en main en temps opportun ou s'il y a un conflit d'intérêts.

4. Quelles sont les fonctions de registre qui sont essentielles ?

Fonctions critiques au fonctionnement d'un registre de gTLD (c'est-à-dire, celles qui sont fournies par l'EBERO) sont les suivantes :

  • DNS - Domain Name System (système de noms de domaine)
  • Zone des extensions de sécurité de système de noms de domaine (DNSSEC) correctement signée (si les technologies DNSSEC sont offertes par le registre)
  • Système d'enregistrement partagé (SRS), en général via le protocole EPP (Extensible Provisioning Protocol)
  • Services d'annuaire de données d'enregistrement (RDDS), par exemple, le service WHOIS fourni via le port 43 et un service basé sur le web.
  • Dépôt de données de registre

5. Quel type d'information demande l'ICANN et qui peut répondre ?

Les participants doivent être des parties qui souhaitent s'engager à assumer la fonction d'opérateur de registre back-end d'urgence. La demande d'information (RFI) couvre de nombreux domaines, mais les participants devraient être prêts à discuter les points suivants :

  • Compétences et expérience dans le domaine des fonctions essentielles d'un registre ;
  • Concepts de transition de registre, expérience, accords de niveau de services (SLA), et cas d'utilisation ;
  • Tarifications pour la fourniture de fonctions de registre d'urgence ;
  • Profil de l'organisation  participante, leadership et ressources.

Contexte

En avril 2009, l'ICANN a publié le Plan de continuité de registre gTLD de l'ICANN – http://www.icann.org/en/registries/continuity/. Ce document décrit un cadre de continuité des registres gTLD développé en collaboration avec des gTLD expérimentés, des registres de ccTLD et des membres de la communauté technique. Les objectifs globaux du cadre de continuité de registre gTLD de l'ICANN sont les suivants :

  1. La protection des registrants existants ; et
  2. Assurer la confiance dans le DNS.

Le cadre de continuité de registre indiquait le besoin d'une compétence reconnue pour continuer à fournir les services en cas de défaillance de l'opérateur de registre.  Il introduit le concept d'un opérateur back-end et les complications que représente un système basé sur un seul opérateur back-up soutenant toutes les capacités existantes des différents modèles de registre. Compte tenu de ces complications, le concept d'identification du niveau de base des « fonctions essentielles », nécessaires pour maintenir les services d'exploitation minimale d'un domaine de premier niveau, a été créé et défini.

En mai 2010, l'ICANN a publié une note explicative sur les nouveaux domaines de premier niveau intitulée « Modèle de processus de transition de registre gTLD » (RyTP) - http://www.icann.org/en/topics/new-gtlds/registry-transition-processes-clean-30may11-en.pdf [PDF, 747 KB]. Ce document développe le concept de fonctions essentielles requises pour le maintien des services de domaine de premier niveau et examine les types de transitions entre un opérateur de registre et l'autre. Le concept d'opérateur de registre back-end d'urgence a également été introduit pour soutenir les fonctions essentielles de TLD des opérateurs de registre défaillants, quand il n'y a pas d'opérateur de registre successeur immédiatement assigné.

Liens pour accéder aux principales informations :

Archives contenant des documents relatifs à la continuité de registre gTLD : http://www.icann.org/en/registries/continuity/archive-en.htm


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."