Le système des noms de domaine Internet

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. www.isoc.org 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 email à [email protected]. 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
www.internetsociety.org
rapidement comme réponse :
ripe.net. 1800 IN MX 100 postman.ripe.net.
ripe.net. 1800 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
« 193.0.0.199 ».
postman.ripe.net. 172800 IN A 193.0.0.199
À 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 email à 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
www.internetsociety.org
2
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 www.ripe.net, 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 www.ripe.net lorsque vous cliquez sur l'hyperlien de ce site, la
situation est différente. Le navigateur paraîtrait bloqué en attendant que le nom www.ripe.net 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.
www.internetsociety.org
3
ripe.net.
ripe.net.
ripe.net.
ripe.net.
ripe.net.
172800 IN NS ns.ripe.net.
172800 IN NS ns2.nic.fr.
172800 IN NS sunic.sunet.se.
172800 IN NS auth03.ns.uu.net.
172800 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
www.internetsociety.org
4
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 www.isoc.org. 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 www.isoc.org 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 www.isoc.org ; 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 www.isoc.org à 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.
www.internetsociety.org
5
À 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.
www.internetsociety.org
6
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.
www.internetsociety.org
7
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 à : www.isoc.org/internet/issues
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 1997.
Internet Society
Galerie Jean-Malbuisson 15
CH-1204 Genève, Suisse
Tél. : +41 22 807 1444
Fax : +41 22 807 1445
http://www.internetsociety.org
1775 Wiehle Ave. Suite 201
Reston, VA 20190, USA
Tel : +1 703 439 2120
Fax : +1 703 326 9881
Email : [email protected]
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 :
http://www.isoc.org/isoc/
http://www.isoc.org/isoc/membership/platinum.shtml
www.internetsociety.org
8