Skip to main content

Questions fréquentes sur le plan de gestion de l'occurrence de collisions de noms dans les nouveaux gTLD

Dans le cadre de sa mission et de ses valeurs fondamentales, l'ICANN est tenue de préserver et de renforcer la stabilité opérationnelle, la fiabilité, la sécurité et l'interopérabilité mondiale du système d'identificateurs uniques de l'Internet (noms, numéros IP et paramètres des protocoles). Dans la poursuite de ces objectifs, sous la direction de son Conseil d'administration et en application de l'avis du Comité consultatif sur la stabilité et la sécurité, l'ICANN a commandité une étude pour connaître l'impact potentiel sur la sécurité que pourraient avoir les chaînes de caractères des nouveaux gTLD faisant l'objet de candidatures. L'étude visait à examiner si des collisions de noms pouvaient se produire entre les chaînes de caractères des nouveaux gTLD et les noms de domaine déjà utilisés dans l'espace de noms privé (« TLD non délégués »). L'étude cherchait également à explorer la possibilité d'occurrence de collisions de noms résultant de l'utilisation de noms internes associés à des certificats numériques X509.

Une collision de noms a lieu lorsque les utilisateurs accèdent accidentellement à un nom qui a été délégué dans le DNS public alors qu'ils voulaient accéder à une ressource identifiée au même nom dans un réseau privé. Des situations de ce type, où les frontières administratives entre l'espace de noms privé et public se chevauchent avec, à la clé, la possibilité de résultats inattendus, posent des problèmes et devraient être évitées dans la mesure du possible. Or, le problème ne tient pas à l'occurrence des collisions elle-même, mais plutôt aux comportements ou aux actions nuisibles qui peuvent en découler, ainsi qu'à la nature du comportement inattendu ou du dommage, et à la gravité des conséquences.

Le 5 août 2013,l' ICANN a publié et mis à disposition une étude sur la collision de noms <http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf> [PDF, 3.34 MB] (l'« étude ») où des catégories de chaînes étaient identifiées en fonction de l'occurrence de requêtes, suivant les comportements identifiés dans les échantillons des fichiers journaux du serveur racine, issus de l'initiative du Centre d'opérations, d'analyse et de recherche du DNS (DNS-OARC) « Un jour dans la vie de l'Internet » (DITL). L'étude a utilisé les données ci-dessous : 1) des exemples de requêtes DNS envoyées aux serveurs racine (issus de l'initiative DITL), complétés par 2) des informations fournies par les autorités de certification concernant les certificats de noms internes délivrés (par exemple, certificats TLS/SSL pour des noms non délégués). Une description complète de la méthodologie d'analyse peut être trouvée dans la section 3.4 de l'étude.

Des options pour atténuer les risques ont également été incluses dans l'étude, mais sans recommandations spécifiques pour chacune des catégories. Sur la base de l'étude, le personnel de l'ICANN a publié pour consultation publique, du 5 août au 17 septembre 2013 <http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf> [PDF, 166 KB], une proposition pour gérer les risques liés à la collision de noms.

Le 7 octobre 2013, le Comité du programme des nouveaux gTLD du Conseil d'administration de l'ICANN a adopté une proposition révisée <http://www.icann.org/fr/groups/board/documents/resolutions-new-gtld-07oct13-fr.htm#1.a> qui décrit un plan destiné à gérer l'occurrence de collisions de noms entre les nouveaux gTLD et les mêmes chaînes utilisées dans le secteur privé.

Vous trouverez ci-dessous les questions les plus fréquemment posées concernant le plan, ainsi que les réponses fournies par l'ICANN.

  1. Quelle a été la démarche suivie par l'ICANN pour dresser la liste des noms de domaine de deuxième niveau (SLD) à bloquer dans le cadre de la voie alternative de délégation ?

    La liste des SLD à bloquer pour chaque TLD est constituée par les SLD ayant fait l'objet de requêtes pour le TLD dans les échantillons DITL de la période comprise entre 2006 et 2013 et dans les ensembles de données de déploiement du DNSSEC de 2010.

  2. Quels critères ont été utilisés pour considérer un nouveau gTLD comme étant inéligible à la voie alternative de délégation ?

    Les nouveaux gTLD qui ont affiché des comportements atypiques d'une année à l'autre au niveau des SLD ayant fait l'objet de requêtes ont été considérés inéligibles. Autrement dit, l'ICANN considère qu'un nouveau gTLD est inéligible à la voie alternative de délégation lorsque la liste des SLD change significativement de manière fréquente.

    Les sources de données utilisées pour dresser les listes de variation des SLD sont constituées par des échantillons annuels de données correspondant à des requêtes DNS de 2006 à 2012. L'ensemble des données de l'année 2013 n'a pas été inclus dans la mesure où les chaînes de caractères étaient déjà connues à l'époque (et plusieurs activités ou études menées sur les chaînes connues risquaient de biaiser l'analyse). Pour ces chaînes de caractères, l'accroissement annuel du nombre de SLD faisant l'objet de requêtes est une valeur atypique par rapport à la population des gTLD proposés : (a) dans au moins une des comparaisons annuelles, et (b) en 2012 (indiquant qu'il existe un turnover).

    Par exemple, un TLD qui affiche des valeurs atypiques uniquement dans la comparaison des années 2006-2007 sera toujours considéré éligible. Par contre, un TLD qui affiche des valeurs atypiques dans les comparaisons 2009-2010 et 2011-2012 ne sera pas éligible à la voie alternative de délégation.

  3. La liste de noms de deuxième niveau (SLD) bloqués sera-t-elle amendée suite à l'utilisation d'autres ensembles de données du cadre de gestion de l'occurrence de collisions de noms?

    Aucun amendement aux listes de SLD bloqués pour les nouveaux gTLD n'est envisagé comme résultat du développement du Cadre. Cependant, si de nouvelles découvertes étaient faites pendant le développement du Cadre, elles seront prises en considération.

  4. Le code source pour la création des listes de noms bloqués est-il disponible ?

    Le processus mis en place pour créer la liste de noms bloqués est expliqué en détail dans chacun des rapports de la voie alternative de délégation établis pour les nouveaux gTLD qui ont conclu des accords et sont considérés éligibles. Voir par exemple http://www.icann.org/en/about/agreements/registries/luxury/luxury-apd-report-12nov13-en.htm

    Le code utilisé pour créer les listes est basé sur le code publié sur https://github.com/JASdevteam/dns-oarc

  5. Pour combien de temps les SLD figurant sur la liste de noms à bloquer resteront-ils bloqués ?

    Le blocage devra se poursuivre jusqu'à l'application des mesures d'atténuation décrites dans l'évaluation de l'occurrence de collisions de noms respective.

  6. Pour un TLD spécifique, si le SLD « nic » apparaît dans les données DITL (indiquant qu'il peut y avoir un problème de collision de noms), pourquoi « nic » est-il accepté dans le gTLD et pourquoi ce risque est plus acceptable que le risque de toute autre collision de noms ?

    Le seul nom dont l'utilisation est exigée par contrat est « whois.nic.<tld> », afin de permettre aux opérateurs de registre de proposer des services WHOIS, c'est à dire, « whois.nic.<tld> ». Après avoir analysé les risques liés à l'utilisation de ce nom versus l'utilité d'avoir un service WHOIS disponible à une endroit bien localisé, l'ICANN a décidé de ne pas inclure « nic » dans la liste des SLD à bloquer pour tout nouveau gTLD. Cependant, un mécanisme de réponse à la collision de noms <http://www.icann.org/fr/help/name-collision> est disponible pour être utilisé par toute partie affectée souhaitant faire état d'un tort significatif causé par un tel nom de domaine. Il faut également noter que le nom n'est disponible que pour l'opérateur de registre lui-même, ce qui veut dire que le registre possède un contrôle total sur le SLD.

  7. Est-ce que l'ICANN mettra à jour la liste des SLD bloqués pour inclure l'année à laquelle les noms ont fait l'objet de requêtes ?

    L'ICANN n'envisage pas de mettre à jour la liste des SLD bloqués ou d'y inclure l'année à laquelle les SLD ont fait l'objet de requêtes. Cependant, s'il existe un intérêt de la part de la communauté, l'ICANN considérera l'inclusion de ces données lorsque les ressources seront disponibles.

  8. Que doit-on faire avec les noms de la liste des SLD bloqués par rapport à la période d'enregistrement prioritaire et de revendications de marques dans le centre d'échange d'informations sur les marques commerciales (TMCH) ?

    Les noms figurant sur la liste des SLD bloqués doivent être inclus dans la période d'enregistrement prioritaire et la période de revendication de marques, conformément aux politiques usuelles de l'opérateur de registre, mais ne pourront pas être activés tant que les mesures d'atténuation n'auront pas été mises en œuvre. Si un opérateur de registre alloue des noms de la liste de SLD bloqués pendant la période d'enregistrement prioritaire ou de revendication de marques, il est tenu d'informer au titulaire du nom que l'activation de celui-ci n'est pas possible et qu'elle est soumise à l'évaluation de l'occurrence de collision de noms du TLD.

    Il s'agit ici d'une précision par rapport au texte de la section 3.2 du plan de gestion de l'occurrence de collisions de noms. Le but de la liste de noms bloqués est de faire en sorte que le comportement reste toujours le même avant la délégation d'un nouveau gTLD (c'est à dire, une réponse NXDOMAIN dans le DNS). Ce résultat est obtenu par la non activation des noms sur la liste, indépendamment de leur allocation.

  9. Que considère-t-on un dommage susceptible d'entraîner la désactivation d'un nom de domaine de deuxième niveau ayant provoqué des collisions ?

    Il est possible que des occurrences de collisions de certains noms de deuxième niveau n'apparaissant pas dans l'ensemble de données utilisé pour dresser la liste de SLD bloqués puissent se produire une fois que le gTLD devient opérationnel. Pour atténuer ce risque, l'ICANN a mis en place un processus permettant à une partie affectée de signaler le problème et de demander le blocage temporaire d'un nom de domaine récemment activé qui provoque des dommages démontrables et graves découlant d'une collision de noms.

    L'ICANN agira comme point de contact unique pour ces signalisations et coordonnera la notification à l'opérateur de registre concerné afin d'assurer que l'on y donne suite dans les plus brefs délais. L'évaluation des dommages sera faite au départ par l'ICANN, au cas par cas, jusqu'à ce que le travail sur le Cadre donne lieu à des critères uniformes.

  10. Y aura-t-il un portail pour la collision des noms ?

    L'ICANN envisage de mettre en place un portail avec les informations disponibles à ce sujet.

  11. Est-ce que la mise en place de différents types de délégations d'essai est envisagée dans la portée du travail du Cadre de gestion de l'occurrence de collisions de noms ?

    Oui, les délégations d'essai, autant au niveau des TLD (pour les TLD non éligibles à la voie alternative de délégation) qu'au deuxième niveau, pour les SLD sous les nouveau gTLD, seront envisagées pendant le développement du Cadre. Si elles sont adoptées, le Cadre devrait spécifier la délégation d'essai applicable à chaque type spécifique de collision.

    En outre, pendant sa réunion à Buenos Aires, le Conseil d'administration de l'ICANN a adopté une résolution indiquant au personnel d'évaluer les recommandations SAC 062 du SSAC, où il est spécifiquement demandé à l'ICANN de considérer les délégations d'essai.

  12. Quelle est le processus à suivre pour évaluer le travail réalisé pour développer un cadre de gestion de l'occurrence de collisions de noms de domaine et décider de son adoption ?

    Le prestataire principal devra travailler en coopération avec la communauté sur une version préliminaire du Cadre, tel qu'expliqué sur <http://www.icann.org/fr/news/announcements/announcement-2-11nov13-fr.htm>. La version préliminaire du Cadre sera ensuite publiée pour consultation publique. Après la période de consultation publique, une synthèse des commentaires sera faite et la version préliminaire du Cadre sera mise à jour à partir des contributions du public. Finalement, le Comité du programme des nouveaux gTLD du Conseil d'administration de l'ICANN considérera l'adoption du Cadre final.

  13. Comment peut-on participer au développement du Cadre de gestion de l'occurrence de collisions de noms ?

    Tout le monde est invité à participer au développement du Cadre. Les discussions sur le cadre auront lieu par le biais d'une liste de diffusion publique, sur <https://lists.dns-oarc.net/mailman/listinfo/collisions>.

  14. La gestion de la collision de noms sera-t-elle appliquée aux ccTLD ?

    Le problème de la collision de noms a été signalé pour la première fois à l'ICANN en relation avec le programme des nouveaux gTLD. Vu le nombre de nouveaux gTLD attendus, la priorité du travail a été accordée aux nouveaux gTLD. Nous reconnaissons que le problème ne concerne pas uniquement les gTLD. C'est pourquoi l'ICANN a signalé cette question au Comité de risques du Conseil d'administration afin d'identifier le meilleur moyen d'aborder ce problème.


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