|
Home page HOWTO build a DNS registry Sheets Credits How to contribute Legal notice Whois service |
Printable version
Version française
On voit souvent des gens affirmer que le DNS serait handicapé, par exemple du point de vue de la sécurité, par l'existence d'une seule racine. Des propositions plus ou moins sérieuses circulent pour proposer des schémas (en général très peu détaillés) avec plusieurs racines. Cet article a pour but de discuter des significations du modèle à une seule racine et de voir pourquoi il n'y a pas de solutions réalistes à plusieurs racines. Dans ce modèle, l'arbre du DNS a une seule racine. Cela veut dire qu'il n'y a qu'une seule source qui fasse autorité pour mettre à jour le fichier de zone de la racine (cette source est actuellement le Department of Commerce des États-Unis, l'ICANN servant de prête-nom). Dans ce modèle, tout utilisateur de l'Internet, quelque soit son fournisseur d'accès, verra les mêmes données dans le DNS et aura les mêmes réponses à ses questions. Cela n'implique pas qu'il y aie un serveur unique. Bien au contraire, il en existe treize à l'heure actuelle. Ni même que ces treize serveurs de la racine soient sous la même administration (aucun n'est contrôlé par l'ICANN, ils sont gérés par des entités très variées). Ni même qu'on n'aie pas le droit d'en ajouter en local, par exemple pour obtenir de meilleures performances (le fichier de zone est public) : de nombreux fournisseurs d'accès font cela[1]. Mais tous ont les mêmes données. Les serveurs de noms ne sont que des éditeurs, pas des auteurs. Il est donc faux de prétendre que, du point de vue de la sécurité du service, l'existence d'une racine unique est une faiblesse. On peut multiplier le nombre de serveurs de la racine pour limiter les risques de pannes simultanées. En revanche, elle pose une question politique : qui contrôle la racine et donc les données ? Quel organisme a la légitimité de le faire dans un environnement international ? Un certain nombre d'organisations prétendent résoudre un problème mal spécifié (on a vu que l'existence d'une seule racine ne signifiait pas qu'il existait un point unique de vulnérabilité) en permettant l'existence de plusieurs racines. Ces organisations ont des motivations très variables : la plupart du temps, il s'agit d'un projet commercial, le magot de Verisign GRS excitant bien des convoitises. C'est ainsi que des entreprises comme new.net vendent des noms de domaine bidons sans le préciser. La gestion d'une racine bidon leur permet de créer autant de TLD que le souhaitent les exigences du commerce. Certaines des ces racines bidon sont gérées par des clowns agressifs qui vont jusqu'à faire des procès pour garder leur monopole sur les TLD bidons qu'ils ont créé. Parfois, les motivations se veulent politiques : résoudre l'impossible équation citée plus haut ("Qui contrôle les données et de quel droit ?"). Mais le remède n'en est pas un. Il y a en effet deux façons de gérer un ensemble de racines :
ICP-3: A Unique, Authoritative Root for the DNS. Un document très intéressant expliquant la nécessité d'une racine unique. Malheureusement gâché par le plaidoyer prodomo en faveur de l'ICANN. Available online.[1] Techniquement, il existe plusieurs solutions pour faire utiliser ce ou ces serveurs : l'anycast, par exemple. |
Last news THIS IS THE TITLE HOWTO setup a domain registry Anycast, une nouvelle technique de gestion d'un parc de serveur de noms NDI (Noms de Domaines Internationaux) Changing the IP address of the TLD name server Setting up a DNS registry with XML and XSL Checking your domaine: why and how The choices for a nameserver The zone file generator Modélisation de données The whois service |
DocBook/XML source of this page
For every question about generic NIC, please ask info@generic-nic.net.
(last rebuild by WML 2.0.11 (19-Aug-2006): Monday 10 November 2008)