La question des collisions de noms a fait l’objet d’une attention considérable dans les communautés du DNS et de l’Internet au cours des derniers mois. Une collision de noms se produit lorsqu’une tentative de résolution d’un nom utilisé dans un espace de noms privé (par exemple, un nom de domaine de premier niveau non délégué ou un nom court, non qualifié) donne lieu à une requête DNS vers le DNS public et y trouve une coïncidence de nom.
L’occurrence de collisions de noms n’est pas un problème nouveau ; il a été historiquement observé et signalé lorsqu’on faisait état de requêtes contenant des TLD non délégués au niveau de la racine du DNS [PDF, 507 KB]. Ces occurrences ont fait l’objet d’une attention renouvelée parce qu’un grand nombre des chaînes des nouveaux TLD sont identiques à des étiquettes utilisées dans l’espace de noms des réseaux privés.
L’ICANN et autres ont mené des études afin d’en évaluer l’impact potentiel sur les internautes [1 (PDF, 3.34 MB), 2]. Grâce à ces études, nous sommes capables d’observer les symptômes indiquant l’existence de requêtes de noms mal dirigées, d’identifier les origines et les causes probables de ces requêtes et d’y suggérer des remèdes (atténuation).
Traiter la cause et non pas les symptômes des collisions de noms
La sagesse conventionnelle, autant appliquée à la médecine qu’à la sécurité de l’Internet, indique que c’est la cause et non pas le symptôme qu’il faut traiter. Bloquer ou isoler des domaines ou des URL par des sinkholes pour empêcher des logiciels malveillants installés dans un dispositif de communiquer avec un centre de contrôle et de commande d’aun réseau zombie est un exemple de traitement d’un symptôme [3 (PDF, 386 KB), 4]. De telles contremesures soulagent et réduisent les risques, mais l’infection est toujours là et reste une menace. Identifier les dispositifs infectés, éliminer le logiciel malveillant et démanteler parallèlement le réseau zombie est un exemple de traitement de la cause [5] qui, avec un peu de chance, aboutira – de préférence – à un résultat permanent.
Dans le cas de la collision de noms, le blocage ou le report de la délégation d’un TLD faisant l’objet d’une candidature sert à traiter le symptôme mais néglige un aspect important : les collisions de noms sont des requêtes fortuites des TLD vers le niveau racine du DNS public. Il s’agit d’instances où de requêtes de noms qui s’« s’échappent » des espaces de noms auxquels elles sont destinées.
L’utilisation d’espaces de noms privés ou de noms courts, non complets constitue la principale cause des collisions de noms. Ces usages ont de multiples origines : choix au niveau du protocole, facilité pour l’utilisateur, critères de conception de l’application ou hypothèses de mise en œuvre. Des confusions, des erreurs ou des choix de configuration sont aussi souvent à l’origine des requêtes fortuites envoyées à la racine. Ces causes ont persisté pour un certain nombre de raisons. Indépendamment de ces raisons, de nombreuses organisations peuvent vouloir mettre en place des mesures d’atténuation pour réduire les fuites fortuites de requêtes de noms en provenance de leurs espaces de noms privés.
L’ICANN prend des mesures pour soulager les symptômes de la collision de noms. Ces mesures sont publiées dans un plan de gestion de l’occurrence de collisions de noms dans les nouveaux gTLD et sont destinées à donner aux organisations du temps pour :
- examiner leurs espaces de noms internes afin d’identifier si des requêtes sont envoyées à la racine du DNS public, y compris des TLD non délégués;
- évaluer si ces requêtes entraînent un risque inacceptable pour leurs organisations, et
- déterminer comment ce risque sera atténué.
Les mesures cadre que l’ICANN et les candidats aux nouveaux TLD vont mettre en place sont des mesures de diagnostique et d’endiguement mais ne traitent pas la cause sous-jacente. Traiter la cause relève de la décision et de la responsabilité des organisations qui utilisent les noms privés et/ou courts et non qualifiés. Cet aspect est aussi souvent négligé dans les discussions sur les collisions de noms : seules les organisations dont les requêtes ont ciblé à tort le DNS public peuvent déterminer avec certitude si cela représente un risque pour elles ; et c’est à elles de mettre en œuvre des mesures d’atténuation du risque qui leur donnent satisfaction.
L’ICANN a mené des consultations auprès d’experts en la matière afin de préparer un rapport sur l’atténuation des causes associées à l’utilisation de noms courts, non qualifiés. Le principal constat et la principale recommandation du rapport, Guide pour l’identification et l’atténuation des collisions de noms pour les professionnels des TI [PDF, 484 KB], sont :
Lorsque la résolution de noms courts et non qualifiés en est la cause, la résolution de domaines entièrement qualifiés via le DNS public en est une cure appropriée et recommandable.
Le rapport décrit les problèmes que les organisations peuvent rencontrer lorsque des noms internes « s’échappent » vers le DNS global et recommande des remèdes pratiques et réalisables pour un grand nombre d’organisations. Il prend en considération des espaces de noms privés qui s’écartent du DNS, des espaces de noms privés qui utilisent leurs propres TLD privés et des espaces de noms qui sont créés par l’utilisation de listes de recherche.
Le rapport recommande aux organisations qui n’utilisent pas encore des noms de domaine entièrement qualifiés (FQDN) du DNS public d’envisager l’adoption de la stratégie ci-dessous. Très brièvement, le rapport vous recommande de :
- surveiller les services de noms, dresser une liste des TLD privés ou des noms courts non qualifiés que vous voyez en interne et comparer la liste que vous avez créée à la liste de chaînes des nouveaux TLD.
- élaborer un plan pour atténuer les causes à l’origine des fuites ; par exemple, changer la racine de votre espace de noms privé pour utiliser un nom que vous avez enregistré dans le DNS global, ou changer les systèmes affectés de manière à utiliser des FQDN ;
- préparer vos utilisateurs au changement imminent dans l’utilisation des noms en les informant à l’avance ou en leur proposant une formation ;
- mettre en œuvre votre plan d’atténuation ;
- continuer à surveiller l’utilisation des anciens noms privés ainsi que l’utilisation des nouveaux noms FQDN au niveau des serveurs et du périmètre de votre réseau et utiliser ces données pour atténuer les causes que vous risquez d’identifier une fois que vous aurez commencé à atténuer les fuites.
Les mesures d’atténuation de ce type son nécessaires mais ne sont pas nouvelles pour les gestionnaires TI. Tout comme il est nécessaire d’identifier les PC infectées aux extrémités d’un réseau et d’éliminer le logiciel malveillant, il sera aussi nécessaire d’identifier et d’éliminer les causes à l’origine des vulnérabilités des noms internes dans les réseaux d’extrémité. Il est important de reconnaître que les organisations qui utilisent déjà des FQDN du DNS public dans leurs réseaux ne devront pas envisager la mise en place de ces mesures. Ces organisations ne verront aucune différence par rapport à leur propre utilisation des noms DNS, indépendamment du nombre ou de la nature des nouveaux TLD délégués.
Si d’autres solutions temporaires ou improvisées peuvent exister, la migration vers des FQDN a une valeur durable : une fois mise en place, vous êtes couvert pour toutes les délégations des nouveaux TLD.