Le système des noms de domaine Internet expliqué aux non-spécialistes Briefing n 16 des membres de l Internet Society par Daniel Karrenberg

Transcription

1 Le système des noms de domaine Internet expliqué aux non-spécialistes Briefing n 16 des membres de l Internet Society par Daniel Karrenberg Le système des noms de domaine expliqué aux non-spécialistes Chers non-spécialistes, Ceci s'adresse à vous, qui avez toujours voulu ou eu besoin de savoir comment les noms sur l'internet fonctionnent vraiment. Le système des noms de domaine Internet (Domain Name System - DNS) est une technologie fascinante ; pratiquement toutes les applications Internet s'en servent. Après avoir lu ce document, non seulement vous serez subitement devenu expert en DNS, mais vous comprendrez comment fonctionne le DNS et vous devriez être dorénavant capable de distinguer un véritable expert en DNS d'un imposteur. Chers experts, Ce document ne s'adresse pas à vous. Dans l'intérêt d'expliquer les principes, nous aurons souvent recours à des généralisations à tel point que nos explications ne seront pas toujours exactes dans leur moindre détail. C'est en consultant les normes Internet appropriées que vous trouverez tous les détails. Rôle du DNS Le DNS a pour objectif de permettre aux applications Internet et à leurs utilisateurs de nommer ce qui doit avoir un nom unique à l'échelle globale. Des noms facilement mémorisables pour des choses telles que les pages Web et les boîtes aux lettres, plutôt que de longues séries de chiffres ou de codes présente l'un des avantages évident du DNS. Ce qui est moins évident mais tout aussi important est la séparation du nom de quelque chose de son emplacement. Les choses peuvent être déplacées vers un endroit totalement différent du réseau de façon entièrement transparente, sans devoir procéder à un changement de leur nom. peut se trouver sur un ordinateur en Virginie aujourd'hui et sur un autre ordinateur à Genève demain, sans que quiconque ne s'en aperçoive. Afin de réussir cette séparation, les noms doivent être traduits sous forme d'autres identifiants que les applications utilisent pour communiquer via les protocoles Internet appropriés. Regardons ce qui se passe lorsque vous m'envoyez un message à daniel.karrenberg@ripe.net. Un serveur de courrier tentant de livrer le message doit découvrir où envoyer le courrier pour les boîtes aux lettres à 'ripe.net'. C'est à ce moment-là que le DNS entre en jeu. Le serveur de courrier transmet cette question, appelée une «requête» en terminologie DNS, au DNS. Il reçoit

2 rapidement comme réponse : ripe.net IN MX 100 postman.ripe.net. ripe.net IN MX 150 postboy.ripe.net. «le courrier pour ripe.net doit d'abord être envoyé à l'ordinateur appelé postman.ripe.net. Si postman.ripe.net n'est pas disponible, essayer postboy.ripe.net». Le serveur de courrier va maintenant faire la connexion avec postman.ripe.net. Pour ce faire, il doit connaître l'adresse Internet numérique pour postman.ripe.net'. Cette adresse numérique suffit pour envoyer des paquets Internet directement à l'ordinateur appelé postman.ripe.net à partir de n'importe où sur Internet. De nouveau, une requête est envoyée au DNS qui renvoie « ». postman.ripe.net IN A À partir de là, le serveur de courrier qui livre votre message peut communiquer directement avec le serveur de courrier qui reçoit et stock mon courrier que je pourrai récupérer plus tard. Il est évident que les informations que nous venons d'obtenir dans notre exemple ne peuvent pas provenir d'une liste centralisée quelque part. Cette liste serait trop grande, changerait trop souvent et elle serait rapidement inondée de requêtes. Alors, comment ça marche vraiment? Suivons la requête DNS en partant de votre ordinateur. Votre ordinateur connaît l'adresse d'un «serveur mandataire» DNS à proximité auquel il enverra la requête. Ces serveurs mandataires sont généralement exploités par les personnes qui vous fournissent votre connectivité Internet. Il peut s'agir de votre prestataire de services Internet dans un contexte résidentiel, ou de votre service informatique d'entreprise dans un contexte professionnel. Votre ordinateur peut apprendre l'adresse des serveurs mandataires disponibles automatiquement lorsqu'il se connecte au réseau ou ces adresses peuvent être configurées par votre administrateur de réseau de façon statique. Lorsque la requête parvient au serveur mandataire, il y a de bonnes chances que ce serveur connaisse déjà la réponse parce qu'il s'en est souvenu, il l a «mise en cache» en terminologie DNS, au cours d'une transaction précédente. Donc, si quelqu'un utilisant le même serveur mandataire a récemment envoyé un à quelqu'un à ripe.net, toutes les informations nécessaires seront déjà disponibles et le serveur mandataire n'aura qu'à envoyer les réponses qu'il a dans son cache à votre ordinateur. Vous voyez comment la mise en cache accélère considérablement l'obtention de réponses à des requêtes pour des noms répandus. Un autre effet important du cache est la réduction de la charge sur le DNS dans son ensemble, parce que de nombreuses requêtes ne vont pas au-delà des serveurs mandataires. Détails - hiérarchies des caches Les serveurs mandataires peuvent également être disposés selon une hiérarchie. Cela a du sens dans les cas où la capacité de réseau est limitée et/ou la latence de réseau entre le client DNS et le reste de l'internet est élevée. Lorsque vous connectez un ordinateur portable à l'internet via un accès commuté, il est logique d'exploiter un serveur mandataire directement sur le portable. Ainsi, chaque clic sur un hyperlien sur le même site Web n'entraînera pas un trafic DNS sur la connexion d'accès commuté. Un tel serveur mandataire local est souvent 2

3 configuré de sorte à envoyer toutes les requêtes pour lesquelles il n'a pas de réponses dans son cache au serveur mandataire du prestataire de service Internet. Parfois, les réseaux d'entreprises disposent de serveurs mandataires locaux qui, à leur tour, envoient les requêtes à un serveur mandataire d'entreprise avant qu'elles soient envoyées à l'internet. Ainsi, le serveur mandataire de l'entreprise peut élaborer un vaste cache en fonction des requêtes qui lui parviennent de l'ensemble de l'entreprise. Au-delà du cache Si le serveur mandataire ne trouve par la réponse à une requête dans son cache, il doit trouver un autre serveur DNS qui la détient. Dans notre exemple, il va chercher un serveur qui a les réponses à tous les noms se terminant par ripe.net. En terminologie DNS, un tel serveur est qualifié de «serveur autoritaire» pour le «domaine» ripe.net. Dans de nombreux cas, notre serveur mandataire connaît déjà l'adresse du serveur de noms autoritaire pour ripe.net. Si quelqu'un utilisant le même serveur mandataire s'est récemment rendu sur le serveur mandataire a eu besoin de trouver le serveur de noms autoritaire pour ripe.net à ce moment-là, et s'agissant d'un serveur mandataire, il a naturellement mis dans son cache l'adresse du serveur de noms autoritaire. Ainsi, le serveur mandataire enverra la requête concernant les serveurs de courrier pour ripe.net au serveur de noms autoritaire pour ripe.net, recevra une réponse, enverra cette réponse directement via votre ordinateur et mettra la réponse également dans son cache. Notez que jusqu'à présent, seul votre serveur mandataire et le serveur de noms autoritaire pour ripe.net ont été impliqués dans la réponse à cette requête. Redondance - De nombreux serveurs avec les mêmes réponses Maintenant, que faire si le serveur mandataire ou le serveur de noms autoritaire pour ripe. net ne sont pas joignables? Il est évident alors que votre serveur de courrier ne recevrait pas de réponse et ne pourrait pas immédiatement livrer votre message. Il mettrait simplement le message dans une file d'attente et essaierait plus tard. Par contre, si votre navigateur Web a besoin de trouver l'adresse de lorsque vous cliquez sur l'hyperlien de ce site, la situation est différente. Le navigateur paraîtrait bloqué en attendant que le nom soit résolu en une adresse numérique, parce qu'il ne pourrait pas contacter le serveur web sans connaître cette adresse numérique. Soit vous vous fatigueriez d'attendre et feriez autre chose, ou votre navigateur vous donnerait un message d'erreur après le délai d'expiration de la requête DNS. Cela ne se produit pas très souvent parce qu'il y a un gros potentiel de redondance dans l'architecture de l'internet, tout particulièrement pour le DNS. Pour s'assurer d'une forte disponibilité, le DNS dispose de multiples serveurs qui contiennent tous les mêmes données. Pour contourner le problème du serveur mandataire local non disponible, votre ordinateur a généralement configuré un certain nombre d'entre eux parmi lesquels il peut choisir. Ainsi, on peut être sûr qu'il y a toujours un serveur mandataire disponible. Mais qu'en estil des serveurs de noms autoritaires? Pour améliorer la disponibilité des serveurs de noms autoritaires, il en existe toujours un certain nombre pour chaque domaine. Dans notre exemple de ripe.net, il y en a cinq, trois en Europe, un en Amérique du Nord et un en Australie. 3

4 ripe.net IN NS ns.ripe.net. ripe.net IN NS ns2.nic.fr. ripe.net IN NS sunic.sunet.se. ripe.net IN NS auth03.ns.uu.net. ripe.net IN NS munnari.oz.au. Notre serveur mandataire ne dispose pas d'un endroit pour consulter des informations autoritaires concernant les noms ripe.net mais de cinq, lesquels sont tous autoritaires au même niveau. Il est entièrement libre de choisir l'un quelconque de ceux-ci en fonction de sa propre préférence car ils contiennent tous les mêmes informations ; le choix pourrait être fait soit entièrement au hasard soit en fonction des temps de réponse précédents de ces serveurs. Il suffit de se rappeler que n'importe quel choix est un choix valide. Ce mécanisme offre le potentiel pour une redondance relativement solide qui recouvre à la fois les problèmes de serveurs et de connectivité puisque les serveurs peuvent être situés n'importe où sur Internet. Bien sûr, le degré de redondance réellement atteint dépend de la conception et de l'emplacement des serveurs. Une assez grande entreprise a découvert ceci il y a quelques années lorsque ses deux serveurs de noms autoritaires situés dans la même pièce sont devenus inaccessibles à partir de l'internet en raison d'un problème de réseau qui «ne pouvait pas se produire». Saisie des informations dans le DNS Les informations sont saisies dans le DNS en modifiant les bases de données utilisées par les serveurs de noms autoritaires pour répondre aux requêtes. Comment ces bases de données sont entretenues et transmises aux serveurs est une question d'implémentation locale qui est entièrement transparent aux clients DNS et qui ne fait pas partie du champ de la présente description. Pour les plus petits domaines, un fichier texte local est souvent modifié sur l'un des serveurs de noms autoritaires puis transféré aux autres. Dans le cas présent, le serveur de noms autoritaire sur lequel le fichier est maintenu s'appelle le serveur «maître» et les autres serveurs de noms autoritaires sont appelés les serveurs «esclaves». Toutefois cette distinction est invisible au reste du DNS puisque tous les serveurs ont une autorité équivalente. Montée dans la hiérarchie Considérons maintenant la situation où notre serveur mandataire vient juste de démarrer et dont le cache est vide. Par conséquent, il ne connaît pas la réponse à votre requête ni ne sait où se trouvent les serveurs de noms autoritaires pour ripe.net. Par contre, il sait qu'il est possible de poser des questions pour ripe.net à un serveur de noms autoritaire pour «net» parce que des points séparent les différentes parties du nom de domaine. Cette connaissance fait partie du protocole DNS même, qui dit : «Si les serveurs de noms autoritaires pour un nom ne sont pas connus, retirer la partie la plus à gauche du nom y compris le premier point et envoyer la requête d'origine à un serveur de noms autoritaire pour ce nom.» Dans notre exemple, un serveur de noms autoritaire pour «net» ne connaît pas la réponse à une requête concernant quelquechose.ripe.net parce que les serveurs ripe.net détiennent ces informations, mais il sait quels sont les serveurs de noms autoritaires pour les requêtes concernant ripe.net. Donc, au lieu d'une réponse à la requête, le serveur «net» répondra avec une liste de serveurs de noms autoritaires pour ripe.net, un «renvoi de référence» en terminologie DNS. Le serveur mandataire recevra le renvoi de référence pour les serveurs 4

5 ripe.net. Comme dans l'exemple précédent, il pose alors sa question à un serveur de noms autoritaire pour ripe.net, obtient la réponse et la renvoie au client qui l'a posée. De plus, comme il s'agit d'un serveur mandataire, il mettra en cache la réponse et la liste des serveurs de noms autoritaires pour ripe.net pour toute éventualité future. C'est tout simple. Mais attendez, nous avons supposé que le cache était vide au départ, alors, comment notre serveur mandataire sait-il où se trouvent les serveurs de noms autoritaires pour «net»? Autrement dit, que se passe-t-il une fois que nous avons enlevé toutes les parties d'un nom de domaine et que nous ne savons toujours pas où nous rendre pour obtenir une réponse? Dans ce cas, il existe un ensemble de serveurs de noms autoritaires particuliers, les serveurs de noms racine DNS. Ils connaissent les adresses de tous les serveurs de noms autoritaires pour les noms qui ne contiennent pas un point, les domaines de premier niveau (Top Level Domains - TLD) tels que : org, com, ch, uk. Les serveurs de noms racine sont les seuls serveurs DNS qui doivent être trouvés sans que toute autre information ne soit mise en cache. Pour résoudre ce problème de démarrage, tous les serveurs mandataires contiennent une liste préconfigurée d'adresses numériques de tous les serveurs de noms racine. Au démarrage, un serveur mandataire enverra des requêtes pour la liste actuelle des serveurs de noms racine à chacune de ces adresses, tour à tour, jusqu'à ce qu'il obtienne une réponse. Une fois la liste à jour obtenue, il sait où envoyer les requêtes pour les noms sans point. Cela peut paraître inutilement compliqué, mais cela permet de s'assurer qu'un serveur mandataire continuera de travailler lorsque les adresses des serveurs de noms racine changent mais que sa liste n'est pas mise à jour ; ces adresses ne changent pas souvent, mais elles changent tout de même de temps à autre. Un serveur mandataire pourra utiliser tous les serveurs de noms racine actuels dans la mesure où il peut accéder à une seule des adresses préconfigurées. Nom du domaine Les points séparent les noms de domaine en différentes parties. La séparation à son tour divise l'ensemble de tous les noms en des domaines différents où la même partie d'un nom peut être réutilisée, p. ex. ripe.net, mais est entièrement différente de ripe.org. Mais, plus important, ces domaines peuvent être gérés entièrement indépendamment. L'administrateur des noms «net» n'a pas besoin de connaître quoi que ce soit sur les noms «org». Le domaine org est indépendant du domaine net. En raison de la structure hiérarchique, les administrateurs de sousdomaines au sein d'un domaine peuvent également agir de façon indépendante, p. ex. isoc.org n'a pas besoin de coordonner quoique ce soit avec nanog.org ni même savoir qu'il existe. Un dernier exemple Donc, encore une fois, voici ce qui se passe lorsqu'un serveur mandataire qui vient juste de démarrer reçoit une requête pour l'adresse Après son démarrage, le serveur a obtenu une liste de serveurs de noms racine et leurs adresses. Lorsque la requête lui parvient, il ne trouvera pas la réponse pour dans le cache, ni l'adresse d'un serveur de noms autoritaire pour isoc.org, ni l'adresse d'un serveur de noms autoritaire pour «org». N'ayant pas d'autre choix, il va alors demander à un serveur racine l'adresse de ; le serveur racine va lui répondre avec un renvoi contenant la liste de tous les serveurs de noms autoritaires pour «org». Notre serveur mandataire enverra sa requête pour à l'un de ces serveurs et recevra un second renvoi avec la liste de tous les serveurs de noms autoritaires pour isoc.org. Lorsqu'il envoie la requête à l'un d'entre eux, il recevra la réponse. Tout ceci se passe généralement en moins d'une seconde. 5

6 À partir de là, le serveur mandataire peut répondre à la même requête encore et encore à partir de son cache sans avoir à poser la question à un autre serveur. Il peut également envoyer une requête pour quelquechose.isoc.org directement à un serveur isoc.org et envoyer une question pour un autre nom se terminant par.org directement à un serveur de noms autoritaire pour «org». Ce n'est que lorsqu'il reçoit une requête pour un nom se terminant par autre chose que.org qu'il devra de nouveau interroger un serveur racine. Le cache va rapidement contenir des listes de serveurs de noms autoritaires pour tous les domaines habituels, particulièrement pour les TLD habituels ; généralement, notre serveur mandataire n'aura pas besoin de redemander cette information pendant plusieurs jours. Cette conception assure que seule une minuscule fraction de toutes les requêtes devront être traitées par les serveurs racine ou par les serveurs de noms autoritaires pour les TLD. 6

7 Gestion du changement Qu'en est-il du cas où l'information sur les serveurs de noms autoritaires est mise à jour mais que les serveurs mandataires dans le monde entier détiennent encore des informations périmées et éventuellement incorrectes dans leur cache? C'est alors que la durée de vie (Time To Live - TTL) du DNS entre en jeu. Chaque partie de l'information DNS qui peut être mise en cache séparément est associée à une durée de vie. Une fois que cette durée prend fin, l'information dans le cache doit être éliminée et doit être obtenue de nouveau d'un serveur de noms autoritaire si besoin est. Le TTL n'est pas configuré localement dans le serveur mandataire mais il est installé dans le serveur de noms autoritaire et transmis avec les informations mêmes. Ainsi, l'administrateur d'un domaine peut contrôler le temps qu'il faut pour que tout changement soit propagé sur l'internet. En choisissant les valeurs soigneusement, on peut établir le compromis entre la possibilité de modifier les choses rapidement d'une part et minimiser les ressources de calculs et de réseautage nécessaires aux serveurs de noms d'autre part. Si une information particulière ne doit pas changer dans un avenir proche, on peut avoir un TTL élevé tandis que les informations que l'on sait changer rapidement peuvent être transmises avec un TTL bas. Il est de pratique courante de réduire le TTL transmis avec une information qui doit changer afin que ce changement soit rapidement visible sur tout l'internet ; une fois le changement effectué, le TTL est alors augmenté de nouveau. Ceci met fin à notre présentation du DNS pour les non-spécialistes. Nous espérons que vous l'avez appréciée et que vous avez acquis des connaissances de base sur l'un des fondements de l'internet d'aujourd'hui. Peut-être serez-vous intéressé par des d'explications pour les nonspécialistes informés sur d'autres sujets connexes. Nous sommes actuellement en train de préparer un briefing semblable sur la façon dont le système de serveurs de noms racine DNS est en train d'évoluer. 7

8 Couverture étendue de l'internet Society Des articles approfondis, papiers, liens et autres ressources sur une variété de sujets sont disponibles sur le site ISOC à : RFC d'ietf pertinents Les RFC de base décrivant le DNS sont : 1034 Domain names - concepts and facilities (Noms de domaines - concepts et installations) 1035 Domain names - implementation and specification. (Noms de domaines - implémentation et spécification). Ils ont été mis à jour et étendus par de nombreux autres RFC y compris notamment : RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308, RFC2535, RFC2845 et RFC3425. À propos de l auteur Daniel Karrenberg est actuellement expert scientifique en chef auprès du CCR de RIPE. Ses intérêts comprennent les mesures de l'internet, le développement de DNS et l'évolution de ce que les autres appellent souvent la «gouvernance Internet». Dans les années 1990, M. Karrenberg a mené la mise en place du CCR de RIPE, le premier des registres régional de l'internet. Il a aidé à élaborer la politique de distribution d'espace des adresses Internet, en transférant à la fois le développement de politiques et l'implémentation à la région. Il a également amené le second serveur de noms racine DNS en Europe en Internet Society Galerie Jean-Malbuisson 15 CH-1204 Genève, Suisse Tél. : Fax : Wiehle Ave. Suite 201 Reston, VA 20190, USA Tel : Fax : info@isoc.org Au cours des années 1980, M. Karrenberg a aidé à l'élaboration de EUnet et a mené les efforts de sa transition aux protocoles Internet, faisant de EUnet le premier prestataire de services paneuropéen et en amenant des connexions Internet à de nombreux endroits en Europe et au-delà. Remerciements La Série de briefings des membres ISOC est rendue possible par l'assistance généreuse des Sponsors du Platinum Program de l'isoc : Afilias, APNIC, ARIN, Microsoft, Qualys, Ripe NCC, et SIDA. Pour en savoir plus sur le Platinum Sponsorship Program : 8