Skip to main content
Resources

Atténuation des occurrences de collision de noms pour les nouveaux ccTLD

Cette page est disponible en:

Collision de noms | Guide pour l’identification et l’atténuation des collisions de noms pour les professionnels des TI | Questions fréquentes : Identification et atténuation des collisions de noms pour les professionnels des TI | Atténuation des occurrences de collision de noms pour les nouveaux ccTLD | Questions fréquentes : Cadre de gestion de l’occurrence de collisions de noms de domaine à l’usage des opérateurs de registre | Signaler une collision de noms

Conformément à sa mission et à ses valeurs fondamentales, l'ICANN se doit 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 d'Internet (noms, numéros IP et paramètres de protocole)1. C'est dans cette optique, sous l'impulsion de son Conseil d'administration et à la lumière des recommandations du Comité consultatif sur la sécurité et la stabilité (SSAC), que l'ICANN s'emploie à comprendre et à endiguer les problèmes liés à la « collision de noms » au sein du système des noms de domaine (DNS).

On parle de collision de noms lorsqu'un nom de ressource, destiné à être résolu dans un système de nommage donné, est résolu par inadvertance dans un système de nommage distinct. La situation peut engendrer des anomalies, comme l'interruption d'une communication ou sa redirection vers un destinataire autre que celui prévu.

Dans le droit fil de son plan « Gestion de l'occurrence de collisions de noms dans les nouveaux gTLD » <https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-1-07oct13-en.pdf> [PDF, 840 Ko] et de son « Cadre de gestion de l'occurrence de collisions de noms » https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf> [PDF, 635 Ko], l'ICANN a demandé aux opérateurs de nouveaux domaines génériques de premier niveau (gTLD) de la série de 2012 l'application de mesures spécifiques visant à réduire les risques de collision.

Or, ces risques ne sont pas l'apanage des nouveaux gTLD : ils peuvent également se présenter dans les nouveaux domaines de premier niveau géographiques (ccTLD), qu'ils soient en ASCII ou en noms de domaine internationalisés (IDN). Afin de contribuer à atténuer ces risques au sein de votre futur ccTLD, l'ICANN vous recommande vivement d'adopter les mesures suivantes :

Pendant une période d'au moins 90 jours, le gestionnaire du nouveau ccTLD devrait appliquer une interruption contrôlée continue, en insérant les enregistrements suivants dans la zone du ccTLD (en prenant soin de remplacer la mention « TLD » par la chaine de votre nouveau ccTLD) :

TLD. 3600 IN MX 10 your-dns-needs-immediate-attention.TLD.
*    3600 IN MX 10 your-dns-needs-immediate-attention.TLD.
TLD. 3600 IN SRV 10 10 0 your-dns-needs-immediate-attention.TLD.
*    3600 IN SRV 10 10 0 your-dns-needs-immediate-attention.TLD.
TLD. 3600 IN A 127.0.53.53
*           3600 IN A 127.0.53.53
TLD. 3600 IN TXT "Your DNS configuration needs immediate attention see https://icann.org/namecollision"
*    3600 IN TXT "Your DNS configuration needs immediate attention see https://icann.org/namecollision"

Comme souligné dans le SAC0152, l'ICANN déconseille l'emploi d'enregistrements assortis de caractères génériques dans le DNS pour les noms de domaine ouverts à l'enregistrement par des tiers Par conséquent, il convient de n'enregistrer, ou à tout le moins de n'activer, aucun nom sous le TLD avant l'échéance de la période d'interruption contrôlée de 90 jours. Pour en savoir plus sur l'utilisation des caractères génériques, veuillez consulter ce document : <https://archive.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09-en.pdf> [PDF, 227 Ko].

Il est par ailleurs conseillé aux gestionnaires de nouveaux ccTLD de se doter d'un mécanisme de signalement de collision afin de réagir aux cas de préjudices graves causés par ce phénomène, à minima lors des premiers jours d'exploitation du ccTLD (voir l'exemple à l'adresse <https://forms.icann.org/en/help/name-collision/report-problems>). À titre d'exemple, les mesures d'intervention peuvent consister à retirer les caractères génériques du DNS durant la période d'interruption contrôlée, à supprimer un nom de domaine de second niveau du DNS, voire, dans les cas extrêmes, à retirer le TLD lui-même de la zone racine (par exemple, si le TLD — comme nom sans point — est directement à l'origine du préjudice lors de cette phase). Il est à noter que ces interventions n'ont vocation qu'à être temporaires, le temps que la partie lésée reconfigure son réseau pour éviter tout préjudice futur.

Pleinement attachée à la délégation de nouveaux gTLD dans le strict respect de sa mission et de ses valeurs fondamentales, l'ICANN salue l'attention que vous portez à cet enjeu et se tient prête à poursuivre cette collaboration sur demande.

1 https://www.icann.org/resources/pages/bylaws-2012-02-25-en, Article I

2 https://www.icann.org/resources/pages/sac-015-2012-02-25-en

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