Commentaire technique de l'IAB sur la racine unique du DNS

Statut de ce mémoire

Le présent mémoire fournit des informations pour la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

Pour rester un réseau mondial, l'Internet exige l'existence d'un espace de noms publics unique au niveau mondial. L'espace de noms du DNS est un espace de noms hiérarchisé dérivé d'une seule racine, unique au monde. C'est une contrainte technique inhérente à la conception du DNS. Il n'est donc pas faisable techniquement qu'il y ait plus d'une racine dans le DNS public. Cette racine unique doit être soutenue par un ensemble de serveurs racines coordonnés administrés par une autorité de dénomination unique.

Pour faire simple, déployer plusieurs racines de DNS public donnerait une très forte probabilité que les usagers de différents FAI qui cliquent sur le même lien sur une page de la Toile arrivent à des destinations différentes, à l'encontre de la volonté des concepteurs des pages de la Toile.

Cela n'empêche pas des réseaux privés de faire fonctionner leurs propres espaces de noms privés, mais si ils souhaitent utiliser des noms définis de façon univoque pour l'Internet mondial, ils doivent aller chercher cette information auprès de la hiérarchie de dénomination du DNS global, et en particulier auprès des serveurs racines coordonnés de la hiérarchie de dénomination du DNS global.

1.   Explication détaillée

Il y a plusieurs raisons distinctes au fait que le DNS exige une seule racine afin de fonctionner correctement.

1.1   Maintenance d'un ensemble de symboles communs

Des communications efficaces entre deux parties exigent deux préconditions essentielles :

-   l'existence d'un ensemble commun de symboles, et

-   l'existence d'une interprétation sémantique commune de ces symboles.

Manquer à la première condition implique l’échec de toute communication, alors que manquer à la seconde implique la perte du sens de la communication.

Dans le cas d’un système de communications publiques, cette condition d’un ensemble commun de symboles avec une interprétation sémantique commune doit être encore renforcée en celle d’un ensemble unique de symboles avec une unique interprétation sémantique. Cette condition d’unicité permet à tous d’initier une communication qui peut être reçue et comprise par toute autre partie. Une telle condition exclut la capacité à définir un symbole au sein d’un contexte borné. Dans un tel cas, une fois que la communication sort du contexte d’interprétation dans lequel elle a été définie, la signification du symbole est perdue.

Au sein des réseaux publics de communications numériques tels que l’Internet, cette exigence d’une définition univoque de la signification de l’ensemble des symboles existe à de nombreux niveaux, en commençant par le schéma de codage binaire, en continuant avec les en-têtes de paquet et les formats de charge utile ainsi que les protocoles qu’utilisent les applications pour interagir. Dans chaque cas, une variation de l’ensemble de symboles ou une différence d’interprétation des symboles utilisés au sein de l’interaction cause une défaillance du protocole et l’échec de la communication. La propriété d’unicité permet à un symbole d’être utilisé sans ambiguïté dans tout contexte, permettant que le symbole soit transmis, qu’on s’y réfère, qu’on le réutilise, tout en conservant la signification de l’utilisation originale.

Le DNS joue un rôle essentiel au sein de l’environnement du protocole Internet en permettant aux localisations du réseau d’être référencées en utilisant une étiquette autre qu’une adresse de protocole. Comme avec tout autre ensemble de symboles similaires, les noms du DNS sont conçus pour être uniques au monde, c’est-à-dire que pour tout nom du DNS à tout instant donné, il doit y avoir un seul ensemble d’enregistrements DNS qui décrive de façon univoque les adresses de protocole, les ressources du réseau et les services associés à ce nom du DNS. Toutes les applications déployées dans l’Internet qui utilisent le DNS se fondent sur cela, et les utilisateurs de l’Internet attendent un tel comportement de la part des noms du DNS. Les noms sont des symboles constants, dont l’interprétation n’exige pas spécifiquement la connaissance des contextes individuels. Un nom du DNS peut être passé d’un point à un autre sans altérer l’intention sémantique du nom.

Comme le DNS est structuré hiérarchiquement en domaines, l’exigence d’unicité des noms du DNS dans leur globalité implique que chacun des noms (sous domaines) définis au sein d’un domaine ait une signification unique (c’est-à-dire, un ensemble unique d’enregistrements du DNS) au sein de ce domaine. Ceci est vrai pour le domaine racine comme pour tout autre domaine du DNS. L’exigence d’unicité au sein d’un domaine implique de plus qu’il y ait un mécanisme pour empêcher les conflits de noms au sein d’un domaine. Dans le DNS, ceci est accompli en allouant un seul propriétaire ou gestionnaire à chaque domaine, y compris au domaine racine, qui est chargé de s’assurer qu’à chaque sous domaine de ce domaine sont associés les enregistrements appropriés. Ceci est une exigence technique, pas un choix politique.

1.2   Coordination des mises à jour

La conception et la mise en œuvre du protocole du DNS se sont toutes deux fortement appuyées sur l’hypothèse d’un seul propriétaire ou gestionnaire de chaque domaine, et que tout ensemble d’enregistrements de ressources associé à un domaine est modifié par duplication en série. C'est-à-dire que même en supposant qu’un seul domaine pourrait d’une certaine façon être "partagé" par des parties qui ne coopèreraient pas, il n’y a aucun moyen dans le protocole du DNS qui permette à un usager ou un client de découvrir, et choisir entre elles, des définitions contradictoires d’un nom DNS faites par des parties différentes. Le client va simplement retourner le premier ensemble d’enregistrements de ressource qu’il va trouver correspondre au domaine demandé, et supposer qu’ils sont valides. Ce protocole est incorporé dans le logiciel d’exploitation de centaines de millions d’ordinateurs, et il n’est pas facile de le mettre à jour pour prendre en charge un scénario de partage de domaine.

De plus, même en supposant que d’autres moyens de résoudre les conflits de définition puissent être fournis à l’avenir, ils devraient se fonder sur des règles objectives établies à l’avance. Par exemple, la zone A.B pourrait déclarer que l’autorité de dénomination Y a reçu délégation pour tous les sous domaines de A.B qui ont un nombre impair de caractères, et que l’autorité de dénomination Z a reçu délégation pour définir les sous domaines de A.B qui ont un nombre pair de caractères. Donc, un seul ensemble de règles devrait être accepté pour empêcher des conflits d’allocations entre Y et Z, et cette série d’action créerait de toutes façons un seul espace unique. Même cela ne permettrait pas à plusieurs autorités non coopérantes d’allouer des sous domaines arbitraires au sein d’un seul domaine.

Il semble qu’un certain degré de coopération et l’accord sur des règles techniques sont nécessaires afin de garantir l’unicité des noms. Dans le DNS, ces règles sont établies indépendamment pour chaque partie de la hiérarchie de dénomination, et le domaine racine n’y fait pas exception. Donc, il doit y avoir un accord général sur un seul ensemble de règles pour la racine.

1.3   Difficulté de délocalisation de la zone racine

Il y a un aspect technique spécifique dans lequel la zone racine diffère de toutes les autres zones du DNS : les adresses des serveurs de noms pour la zone racine viennent principalement d’informations hors bande. Ces informations hors bande sont souvent mal entretenues, et à la différence des autres données du DNS, les informations hors bande n’ont pas de mécanisme automatique de péremption. Il n’est pas rare que ces informations soient périmées depuis des années sur de nombreux sites.

Comme toute autre zone, la zone racine contient un ensemble d’enregistrements de ressource de "serveur de noms" qui font la liste de ses serveurs, mais un résolveur sans adresses valides pour l’ensemble actuel de serveurs racines ne va jamais être capable d’obtenir ces enregistrements. De façon plus insidieuse, un résolveur qui a un mélange d’informations de configuration hors bande partiellement valides et partiellement périmées ne sera pas cap able de dire quels sont les serveurs racines "réels" si il reçoit en retour des réponses contradictoires ; et donc, il est très difficile de révoquer le statut d’un serveur racine malveillant, ou même de contourner un serveur racine fautif.

En effet, chaque résolveur de plein exercice dans le monde "délègue" la racine de l’arborescence publique au ou aux serveurs racines publics de son choix.

Une conséquence directe en est que tout changement à la liste des adresses IP qui spécifient la zone racine publique est significativement plus difficile qu’un changement à tout autre aspect de la chaîne des délégations du DNS. Et donc, la stabilité du système plaide en faveur d’une gestion extrêmement conservatrice et prudente de la zone racine publique : la fréquence de mise à jour de la zone racine doit rester faible, et les serveurs pour la zone racine doivent être étroitement coordonnés.

Ces problèmes peuvent être améliorés dans une certaine mesure par les extensions à la sécurité du DNS de la [RFC2535], mais un problème similaire à celui de la configuration hors bande existe pour la clé de signature cryptographique pour la zone racine, de sorte que la zone racine exige quand même un couplage étroit et une gestion coordonnée même en présence de DNSSEC.

2.   Conclusion

Le système de type DNS de dénomination unique et de transposition de nom peut n’être pas idéal pour un certain nombre d’objets pour lesquels il n’a jamais été conçu, comme des informations de localisation lorsque l’usager ne connaît pas avec précision les noms corrects. Avec la poursuite de l’expansion de l’Internet, on peut s’attendre à ce que les systèmes de répertoire évoluent pour aider l’usager à traiter des références vagues ou ambiguës. Pour préserver les nombreuses caractéristiques importantes du DNS et ses types multiples d’enregistrements – y compris l’équivalent Internet de la portabilité du numéro de téléphone – on préfèrerait que le résultat des recherches dans les répertoires et l’identification des noms corrects pour un objet particulier soit les noms DNS univoques qui sont alors résolus normalement, plutôt que de voir les systèmes de répertoires "remplacer" le DNS.

Il n’y a pas d’autre voie que la racine unique pour le DNS public.

3.   Considérations pour la sécurité

Le présent mémoire n'introduit aucun nouveau problème de sécurité, mais il essaye d'identifier certains des problèmes inhérents à une familles de propositions récurrentes bien que techniquement infondées.

4.   Considérations relatives à l'IANA

Le présent mémoire n'est pas destiné à créer de nouveau sujet pour l'IANA.

5.   Références

[RFC1034]   P. Mockapetris, "Noms de domaines - Concepts et facilités", STD 13, novembre 1987.

[RFC1035]   P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987.

[RFC2535]   D. Eastlake, "Extensions de sécurité au système des noms de domaines", mars 1999.

6.   Adresse de l'auteur

Bureau d'architecture de l'Internet

mél : iab@iab.org

7.   Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1998). Tous droits réservés.

Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant la notice de droits d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.