% $Id: racines-alternatives.tex,v 1.6 2003/07/29 14:32:55 bortzmeyer Exp $ \documentclass[a4paper,12pt]{article} \usepackage[latin1]{inputenc} \usepackage{bortzmeyer-utils} \usepackage[french]{babel} %\usepackage{ncntrsbk} \usepackage{times} \title{Les ``racines alternatives'' : réalité et avenir} \author{Stéphane Bortzmeyer\\ (AFNIC, mais s'exprimant en son nom personnel)\\ \url{}} \date{9 septembre 2003} \setmarginsrb{1cm}{2cm}{2.5cm}{3cm}{0.5cm}{0.5cm}{0.5cm}{0.5cm} \begin{document} \maketitle \abstract{La question de racines du DNS, alternatives à celle existante, revient souvent dans les débats politiques sur Internet. Ce texte explique la notion de racine alternative, discute sa faisabilité et essaie surtout de séparer les questions techniques et politiques, et de bien distinguer ce qui est faisable à court terme et ce qui relève - au bon sens du terme - de l'utopie. Ce texte propose ensuite une approche à la question de la gouvernance\footnote{Le terme de gouvernance désigne l'ensemble des mécanismes politiques de gestion du système. Il est délibèrement assez flou car il doit pouvoir désigner des mécanismes politiques très divers. Les questions purement techniques n'appartiennent pas à ce domaine.} de la racine du DNS en suggérant, non pas une juxtaposition de racines, ce qui ne peut pas marcher, mais la création d'une nouvelle racine, qui devra s'imposer par ses mérites. } \section{Qu'est-ce qu'une racine du DNS ?} \subsection{Le DNS tel qu'il est} \subsubsection{Organisation des données} À la base de la conception du DNS (\cite{rfc1034}), se trouve la notion de hiérarchie\footnote{Passer à un système non-hiérarchique - système non encore conçu et implémenté - nécessiterait donc de changer profondément l'Internet, avec d'énormes investissements.}. Les domaines sont organisés en un arbre des domaines (voir figure \ref{hierarchie}). Chaque domaine est le sous-domaine d'un domaine parent, jusqu'aux TLD\footnote{\foreign{Top Level Domains} comme \url{.fr} ou \url{.org}.} qui sont sous-domaine de la racine, le point culminant\footnote{Contrairement aux botanistes, les informaticiens placent les racines des arbres en haut.} de l'espace de nommage hiérarchique. La racine est traditionnellement représentée par un point (\textbf{.}). \begin{figure} \ifpdf \includegraphics[scale=0.52]{hierarchie.pdf} \else \includegraphics[scale=0.52]{hierarchie.eps} \fi \caption{Hiérarchie des domaines\label{hierarchie}} \end{figure} Chaque domaine peut déléguer des sous-domaines à d'autres organismes. Ceux-ci pourront alors les peupler à leur guise : le DNS est décentralisé. Mais le délégateur peut toujours accepter, refuser, ou bien changer une délégation. Il a donc un grand pouvoir, qui doit être encadré. La racine a le contrôle du contenu du DNS. D'autant plus que la ``possession'' d'un nom de domaine suscite des passions violentes (cf. \cite{rfc3467}). Des schémas de nommage non-hiérarchiques pourraient être envisagés mais aucun n'a encore fait l'objet d'une spécification complète, sans même parler d'un développement logiciel, a fortiori d'un déploiement sur le terrain. Le DNS est donc un élément hiérarchique dans un Internet qui en comporte peu\footnote{Bien que l'égalité de tous dans l'Internet soit une notion assez idéalisée : Microsoft a un pouvoir considérable sur l'Internet, simplement en décidant du comportement de la prochaine version d'Internet Explorer.}. \subsubsection{La résolution de noms} Les humains se servent de noms (comme \url{www.debian.org}) et les machines d'adresses IP comme \url{192.134.4.20} ou bien \url{2001:660:3003:3::1:4}. Pratiquement tout utilisation d'Internet, du Web au courrier en passant par des applications moins communes, nécessite de trouver l'adresse IP correspondant à un nom. Pour cela, les logiciels interrogent leur serveur de noms local (celui géré par leur Service Informatique ou bien par leur FAI\footnote{Fournisseur d'Accès Internet}), le \foreign{cache/forwarder}. Celui-ci, s'il n'a pas de moyen plus direct de répondre, va contacter l'un des serveurs de noms de la racine, qui le redirigera vers les serveurs d'un TLD, et ainsi de suite (voir figure \ref{resolution}). \begin{figure} \ifpdf \includegraphics[scale=0.52]{resolution.pdf} \else \includegraphics[scale=0.52]{resolution.eps} \fi \caption{Résolution du nom www.debian.org en adresse IP\label{resolution}} \end{figure} Les serveurs de la racine tirent cette information de leur fichier de zone (voir annexe \ref{root.zone}), un fichier géré par l'ICANN\footnote{C'est ce qu'on appelle ``la fonction IANA'' dans le jargon de la gouvernance Internet, l'IANA (Internet Assigned Numbers Authority, \url{http://www.iana.org/}) étant un service de l'ICANN.}, The Internet Corporation for Assigned Names and Numbers (\url{http://www.icann.org/}), un prête-nom du gouvernement des États-Unis\footnote{C'est pourquoi on voit souvent des mentions de la ``racine ICANN'' ou bien la ``racine NTIA/DoC'' (le Doc, Department of Commerce, étant l'autorité de tutelle de l'ICANN et le NTIA \url{http://www.ntia.doc.gov/} son département des télécommunications) ou bien de ``racine USG'', pour United States Government.}. Le contrôle de ce fichier de zone, qui peut y faire des modifications, est l'objet de rudes luttes de pouvoir (cf. \cite{mueller}). Ainsi, pour résoudre\footnote{Traduire un nom en adresse IP.} \url{www.nic.fr}, le serveur local d'une Université brésilienne va demander à la racine, qui lui dira quels sont les serveurs de \url{.fr}. Il suffit donc à ce serveur local, à son démarrage, de connaitre les serveurs de la racine, le reste s'apprendra. Comment les serveurs locaux trouvent-ils ceux de la racine ? Eh bien, nous sommes là au c\oe{}ur du problème des racines alternatives. Ils trouvent l'adresse des serveurs de la racine dans un fichier local (voir annexe \ref{named.root}), configuré par le Service Informatique compétent. En général, ledit service se contente du fichier livré avec le logiciel utilisé. Dans la grande majorité des cas, ce logiciel est BIND (\url{http://www.isc.org/products/BIND/}). L'organisme qui gère BIND, l'ISC\footnote{Internet Software Consortium, \url{http://www.isc.org/}}, a donc le pouvoir d'orienter fortement\footnote{La plupart des administrateurs système ne changent pas les choix effectués par l'éditeur du logiciel.} le choix de la racine qu'on utilise. Le second serveur de noms, en terme d'utilisation, est probablement celui livré par Microsoft avec certaines versions de Windows. \subsection{Les racines alternatives} Alors, comment fonctionne une racine ``alternative'' ? Tout simplement, elle utilise le même système de nommage hiérarchique que la ``vraie'' mais elle a ses propres serveurs de noms, et son propre fichier de zone (qui peut utiliser tout ou partie du ``vrai'' fichier de zone). \subsubsection{Pourquoi créer une racine alternative ?} Il peut y avoir de nombreuses motivations pour se lancer dans cet exercice : \begin{itemize} \item C'est un exercice amusant et intéressant (beaucoup de techniciens créent une racine alternative pour cela), \item La gestion du contenu de la racine n'est pas satisfaisante, par exemple trop liée à un seul gouvernement (voir page \pageref{gouvernance}), \item La gestion des serveurs de la racine n'est pas satisfaisante (pas assez de serveurs ou bien mal répartis), \item La racine alternative n'est qu'un moyen de créer de nouveaux TLD, par exemple pour vendre des enregistrements dans ces nouveaux TLD. \end{itemize} \subsubsection{Créer sa racine ou ``Le pape, c'est moi !''} Pour gérer son propre fichier de zone, la plupart des racines alternatives prennent celui de l'ICANN et ajoutent des domaines ``bidon'', c'est-à-dire reconnus uniquement par les utilisateurs de cette racine alternative particulière. C'est ainsi que l'on peut créer \url{.sex} ou \url{.law} sans formalités particulières. Le processus est analogue à celui d'un schismatique qui prétend être le pape : tout le monde peut faire cela, et se mettre à émettre bulles et encycliques. Le plus dur est d'être reconnu par une communauté significative de fidèles. On notera que, tant que la racine alternative demeure marginale, cela ne pose aucune difficulté technique. Trois PC connectés en ADSL et répartis chez des amis suffisent largement. Un tel exercice est souvent fait lors des formations DNS. \subsubsection{Utiliser une autre racine} Utiliser une racine alternative veut donc dire modifier le fichier de configuration de BIND (ou du logiciel équivalent) pour désigner ces serveurs au lieu des ``vrais''. Il faut donc une action délibérée de la part du Service Informatique ou bien du FAI\footnote{Dans une certaine mesure, cette opération peut être faite par l'utilisateur final mais cela n'est pas réaliste si de nombreuses personnes le font : on perd en effet la fonction de \foreign{cache} effectuée par le serveur local, fonction sans laquelle les serveurs de la racine s'écrouleraient sous la charge.}. % \url{http://www.new.net/download/instructions_unix.tp} % \url{http://www.new.net/help_isp_info.tp} Le déploiement significatif d'une racine alternative nécessite donc de convaincre beaucoup de décideurs. Ce qui nous amène aux questions sociales et politiques. \section{Quelles sont les racines alternatives actuelles ?} Cette section va malheureusement être courte : à l'heure actuelle, aucune des racines ``alternatives'' existantes n'offre la moindre garantie de sérieux, même en étant très indulgent. Il existe en gros trois catégories de racines alternatives : % On oublie les trucs de test comme http://www.rs.net \begin{itemize} \item Les commerciaux sans scrupule, dont le seul but est de gagner de l'argent auprès de clients naïfs en leur vendant des domaines bidon. C'est l'équivalent \foreign{high tech} de l'escroc qui vous vend des propriétés sur la Lune. % Mon avocat m'a déconseillé de citer des noms ici :-) % new.net % Pacific Root % Boroon % Atlantic Root (Gallegos) Ils prétendent en général qu'il existerait ``un autre Internet'' que l'on pourrait voir si l'ICANN ne les bloquait pas injustement. Ils menacent souvent l'ICANN de procès si elle ose créer un TLD correspondant au TLD bidon qu'ils ont ``créé'' deux ans auparavant (cf. \cite{biz-duplicate}. Ils prétendent parfois avoir inventé une technologie révolutionnaire et brevetée, comme si la création d'une racine le nécessitait. \item Les individus isolés. Là encore, je ne citerai pas de noms pour ne faire de peine à personne, mais il s'agit typiquement d'individus qui viennent de découvrir que la création technique d'une racine ne demandait guère de compétences. % Ceux qui jouent à la racine, comme on joue au chef des armées avec ses petits % soldats : % http://www.dot-root.com (Jefsey) % dot-god (Baptista) \item Les organisations qui tentent d'explorer des voies politiques nouvelles et d'expérimenter une gouvernance vraiment démocratique de l'Internet. Elles sont peu nombreuses et les tentatives en ce sens ont toujours échoué. Aucune organisation de cette catégorie n'a une base d'utilisateurs significative. Aucune n'a vraiment produit (ou tenté de produire) de mécanisme de concertation et de décision nouveaux. On notera ORSC \url{http://www.open-rsc.org/}, ORSN \url{http://european.orsn.net/} ou bien OpenNIC \url{http://www.opennic.unrated.net/}. Certaines organisations appartenant à la première ou bien à la seconde catégorie avaient essayé de se faire admettre dans la troisième\ldots \end{itemize} Une liste de racines alternatives, apparement incomplète (et qui ne trie pas selon les catégories ci-dessus) est disponible en \url{http://root-dns.org/zones.htm}. On notera que certaines des racines alternatives publient exactement le même fichier de zone que l'ICANN : elles ne cherchent qu'à tester la gestion des serveurs de la racine, pas la gestion des données de la racine. Comme le disent les administrateurs des serveurs racine : nous sommes des diffuseurs, pas des auteurs. \section{Doit-on et peut-on créer une nouvelle racine ?} \subsection{Le problème d'une gouvernance vraiment internationale} \label{gouvernance} Beaucoup de gens s'inquiètent de l'absence d'une gouvernance de l'Internet qui reflèterait son caractère international. Actuellement, on l'a vu, le gouvernement des États-Unis dispose d'un monopole sur la gestion de la racine. Il peut à sa guise redéléguer un domaine à ses amis, voire garder en otage un domaine (\cite{delacourt-irak}). Ce pouvoir n'est pas utilisé souvent, mais il est équivalent à l'arme nucléaire : on ne peut pas s'en servir à tout bout de champ mais c'est un monopole (un oligopole dans le cas des bombes nucléaires) qu'aucun gouvernement ne peut abandonner. De même, l'ICANN exerce une pression permanente sur les gérants de ccTLD\footnote{Country-Code Top Level Domains}, exigeant qu'ils signent un contrat avec l'ICANN avant de faire la moindre modification au fichier de zone. Ainsi, des changements purement techniques, comme l'ajout d'un serveur de noms, prennent de six à dix-huit mois. Pour renforcer ce pouvoir, l'ICANN garde la plupart des serveurs de noms sous son contrôle étroit. Dix de ces treize serveurs sont situés aux USA\footnote{\url{http://www.root-servers.org/}}, ce qui limite le risque d'indépendance (le gestionnaire d'un serveur racine pourrait toujours décider d'aller chercher son fichier de zones ailleurs qu'à l'ICANN). Si des techniques comme l'\foreign{anycast} (\cite{rfc3258} ou \cite{ripe-anycast}) peuvent permettre de placer d'avantage de serveurs de noms, même sans autorisation de l'ICANN, elles ne réduisent pas le problème du contrôle de ces serveurs (toutes les répliques d'une même machine \foreign{anycastée} sont contrôlées par le même organisme). De nombreux efforts ont été tentés pour changer cela : des demandes polies aux pressions modérées, les gestionnaires de domaines nationaux (ccTLD), l'ONU, les gouvernements non-états-uniens, des individus\footnote{\url{http://www.icannwatch.org} ou bien \cite{mueller}} ont essayé de faire évoluer les choses. Avec des résultats infimes. Le contrôle de l'Internet est devenu un enjeu majeur depuis que l'usage du réseau s'est répandu dans tous les domaines d'activité. Et le 11 septembre n'a pas amélioré les choses\ldots Il semble donc que le gouvernement des États-Unis n'acceptera d'évoluer que s'il a une raison sérieuse de penser que ses critiques sont prêts à mettre la main à la pâte et à démarrer une nouvelle racine. Je dis ``nouvelle racine'' et pas ``racine alternative'' car, on va le voir, il n'y a pas d'intérêt à faire marcher plusieurs racines. \subsection{L'Internet peut-il fonctionner avec plusieurs racines ?} En gros, non. Qui dit plusieurs racines dit fragmentation de l'Internet. Toute application utilisant le DNS (c'est-à-dire la grande majorité des applications) verra donc un résultat différent selon la racine utilisée. Un message envoyé à \url{nom@domaine.example} atterrirait dans des boites différentes selon la racine utilisée par votre fournisseur~! Ce problème, à mon avis bloquant, est bien décrit dans \cite{ICP-3} et \cite{RFC2826} même si le caractère \foreign{pro domo} du premier document le rend agaçant. Pour résoudre ce problème de la coordination entre racines, certains ont développé le concept de racines inclusives ou exclusives. En gros, une racine exclusive ne sert sur le réseau que ses propres TLD (l'ICANN gère donc une racine exclusive) alors qu'une racine inclusive, comme son nom l'indique, inclus les TLD des autres racines inclusives. Les racines inclusives sont souvent présentées comme un moyen de faire marcher en parallèle plusieurs racines. Mais cela oublie complètement la question des litiges : si deux racines différentes veulent \url{.sex}, qui l'aura ? Les litiges sont rares à l'heure actuelle, car les racines inclusives existantes ne sont que des petites expérimentations locales sans enjeu. Mais ce système ne pourrait pas fonctionner en vrai\footnote{C'est pour cela que les partisans des racines alternatives sont toujours très discrets sur ce sujet. Parfois, il y a une proposition concrète (dans une de celles que j'ai lu, il y avait une liste ordonnée de racines, les premières étant prioritaires), mais elle est vite oubliée car toutes reviennent à créer une super-racine, une nouvelle ICANN et pas forcément meilleure.}. % C'est d'ailleurs pour cela qu'il y a si peu de litiges dans .fr, ce % domaine n'intéresse personne :-) Et cela pose la question de leur légitimité : chaque individu peut créer une racine sur son PC en un quart d'heure, mais a t-il le droit de créer le TLD de son choix et d'obliger les racines inclusives à le servir ? Cette question est elle aussi laissée dans le flou : et pour cause, la définition de critéres de légitimité\footnote{``Au moins cinquante TLD et au moins trois mois de fonctionnement'', ai-je lu dans un texte un peu plus précis que les autres. \cite{adns-alternative} dit juste \foreign{``Those in the inclusive namespace work very hard to avoid and resolve collisions''}.} reviendrait à créer une instance politique supérieure, justement ce qu'on prétendait éviter avec les racines multiples. \subsection{La période transitoire} On l'a vu dans la section précédente, la coexistence durable de plusieurs racines n'est pas une solution envisageable. Le but est donc au contraire de faire une nouvelle racine, pendant une période transitoire, pour bien montrer au monde et au gérant actuel de la racine qu'une autre solution est possible et réaliste. Comme la confiance dans une telle racine ne se construit pas en quelques semaines, ni même en quelques mois, cette nouvelle racine coexistera avec l'ancienne pendant un temps assez long. Pendant la coexistence, la nouvelle racine aura tout intérêt à suivre de près l'activité de l'ancienne : si un nouveau pays est créé, les responsables de son ccTLD ne préviendront pas forcément la nouvelle racine, il faudra donc noter son apparition dans le fichier de zone de l'ancienne racine et copier les données. En revanche, il n'est pas utile de s'engager à copier aveuglément le fichier de zone de l'ancienne racine, le but étant de montrer la supériorité de la nouvelle. Les changements purement techniques, par exemple, comme l'ajout ou le retrait d'un serveur de noms, doivent se faire dans la journée, vue la faible taille du fichier de zone de la racine. Cette période transitoire se terminera lorsque le gérant de l'ancienne racine sera persuadé que la nouvelle est une réalisation effective et qu'il acceptera de discuter d'égal à égal. Ce projet est utopique, dans le bon sens du terme. Il est tout à fait inenvisageable à court terme\footnote{C'est l'argument favori de l'ICANN : ``Que proposez-vous à la place ?''.}. Mais c'est un guide pour orienter les politiques futures, une ``expérience de pensée'' qui s'incarnera peut-être un jour, sous une forme qu'il est difficile de déterminer aujourd'hui. \section{Un petit numéro de politique-fiction} Un tel projet a t-il des chances de se réaliser un jour ? Il est possible de suggérer quelques pré-requis pour que cette nouvelle racine ait quelques chances de succès. Il n'est pas possible ici de proposer un plan complet et détaillé, la situation n'est clairement pas assez mûre pour cela. La partie technique est la plus facile, et de loin. Mais les parties sociales et politiques sont redoutables. D'abord, la nouvelle racine doit être crédible, c'est-à-dire être soutenue par un certain nombre d'acteurs significatifs (un ensemble varié de gouvernements, d'opérateurs ou prestataires, d'utilisateurs). La crédibilité implique aussi d'avoir, sinon des réponses toutes prêtes à toutes les questions, du moins d'avoir des propositions concrètes pour traiter un certain nombre de questions délicates. Le statut juridique des organismes de gouvernance est en effet très secondaire\footnote{Surtout quant les statuts sont régulièrement violés, comme ce que fait l'ICANN.} par rapport à leur politique effective. Par exemple, \foreign{quid} des redélégations de ccTLD ? La nouvelle racine suivra t-elle \cite{RFC1591} ? Comment se fera l'attribution de nouveaux gTLD ? L'ICANN a un processus très ouvert pour cela\footnote{Voir tout le dossier de redélégation du \url{.org} en \url{http://www.icann.org/tlds/org/}.}. Tout n'est pas forcément public mais il serait paradoxal que la nouvelle racine soit, par exemple, moins ouverte que l'ICANN sur ce point ! Cela donnerait raison à ceux qui présentent l'ICANN comme un moindre mal. L'inconsistance des racines alternatives existantes ne se mesure nulle part mieux que dans leur silence complet sur ces questions délicates. Les réponses tournent la plupart du temps autour de ``On se cordonnera''. Comme si le fait de ne pas dépendre de l'ICANN allait suffire et que toutes les parties allaient devenir pleines de bonne volonté\footnote{Certains gérants de TLD bidons sont très agressifs et n'hésitent pas à proférer des menaces ou à déclencher des procès à la moindre occasion, voir \url{http://www.dot-god.com/communications/TLD_Networks_Ltd/public_announcement.html}.}. Parfois, la technique vient au secours du silence et on apprend qu'un protocole révolutionnaire (mais jamais décrit en détail) va permettre de synchroniser les racines entre elles sans douleur. Ensuite, la nouvelle racine va devoir être humble : son succès dépendra du nombre d'acteurs qu'elle pourra convaincre\footnote{FAI, pour modifier la configuration de leur serveur DNS local~; gérants de domaine, pour qu'ils s'adressent à la nouvelle racine et pas uniquement à l'ICANN~; auteurs de logiciels pour qu'ils livrent un fichier de serveurs de la nouvelle racine, etc.} et aucune directive bureaucratique ne remplacera ce travail de conviction. Certaines organisations internationales, souvent présentées comme une alternative à l'ICANN, ont un passif particulièrement lourd sur ce point. Cela suffira-t-il pour assurer le succès ? Je l'ignore mais il serait regrettable que la communauté Internet, qui a déjà remporté tant de victoires contre la résignation, ne puisse pas traiter avec succès la question d'une gouvernance vraiment internationale et démocratique. \appendix \section{Annexe : la configuration du serveur local pour trouver la racine} \label{named.root} Voici le fichier de configuration d'un serveur de noms local (celui de votre Université ou de votre FAI). C'est dans ce fichier qu'on trouve les adresses IP des serveurs de la racine. ``Changer de racine'' signifie donc simplement éditer ce fichier\footnote{On peut trouver la version officielle en \url{ftp://rs.internic.net/domain/named.root}.}. \begin{info} ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ... ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ... (Autres serveurs, treize en tout) \end{info} \section{Annexe : le fichier de la racine} \label{root.zone} C'est ce fichier qu'utilisent les serveurs de noms de la racine. Il est disponible en \url{ftp://rs.internic.net/domain/root.zone.gz}. Vue sa taille, c'est une toute petite base de données, dont l'exploitation ne soulève aucune difficulté technique. En voici un extrait : \begin{info} ... COM. NS A.GTLD-SERVERS.NET. COM. NS G.GTLD-SERVERS.NET. COM. NS H.GTLD-SERVERS.NET. ... (autres serveurs de .com) EE. NS NS.EU.NET. EE. NS SUNIC.SUNET.SE. EE. NS NS.UU.NET. EE. NS NS.KBFI.EE. ... (autres serveurs de l'Estonie) FR. NS DNS.CS.WISC.EDU. FR. NS NS1.NIC.FR. FR. NS NS3.NIC.FR. FR. NS DNS.INRIA.FR. FR. NS NS2.NIC.FR. FR. NS DNS.PRINCETON.EDU. FR. NS NS-EXT.VIX.COM. FR. NS NS3.DOMAIN-REGISTRY.NL. ... \end{info} \bibliographystyle{alpha-plus-url} \bibliography{dns} \end{document}