La résolution de noms DNS

Auteur & Source : Christian Caleca

Tous les internautes vous le diront, l’URL est le gouvernail de la navigation sur le Net.

  • URL : Uniform Resource Locator /C’est la méthode d’accès à un document distant. Un lien hypertexte avec une syntaxe de la forme : <Type de connexion>://<FQDN>/[<sous-répertoire>]/.../<nom du document>. Le RFC 1034 définit les concepts de ce système ;
  • FQDN : Full Qualified Domain Name. Le nom complet d’un hôte, sur l’internet, c’est-à-dire de la machine jusqu’au domaine, en passant par les sous-domaines.

Les serveurs DNS

Ils sont en place pour permettre la résolution de de FQDN en adresses IP (et réciproquement, si nécessaire). En utilisation courante, nous exploitons un serveur DNS « récursif » dont l’adresse IP est généralement fournie par DHCP ou RADIUS, suivant le cas. Ces serveurs ne gèrent pas obligatoirement de zones particulières, mais savent effectuer les recherches nécessaires dans une architecture arborescente que nous allons voir en détail, pour résoudre n’importe quel nom d’hôte.

Cette architecture arborescente est construite au niveau mondial et nous verrons que c’est une petite merveille d’organisation.

Objectifs de ce chapitred

L’objectif avoué est double :

  • fournir aux internautes « non spécialistes » les informations de base nécessaires à la compréhension de la résolution des noms ;
  • donner des informations approfondies sur les mécanismes utilisés à ceux qui souhaitent comprendre plus en profondeur le fonctionnement de DNS.

 

Notions de base

Découverte du serveur DNS utilisé

Donc, notre fournisseur d’accès nous propose une ou plusieurs adresses de serveurs DNS récursifs, et notre système va les récupérer lors de sa configuration IP. Pour connaitre ces adresses, il faut savoir retrouver sa configuration. La façon de faire varie suivant le système d’exploitation utilisé.

Le clicodrome Windows propose quelques chemins plus ou moins détournés. Le plus simple étant sans doute d’utiliser la commande nslookup dans une invite de commandes :

Nous sommes ici dans le cas d’une machine sous MS Windows, connectée à une FreeBox en mode pont ethernet (nous n’exploitons pas les fonctions de routage). Il est également possible de récupérer l’information avec la commande :

Pour les distributions Debian GNU/Linux et dérivées, l’information se trouve généralement dans le fichier /etc/resolv.conf :

Test de résolution

Windows XP propose la commande nslookup, qui permet d’effectuer une résolution manuellement. Exemple :

Ça fonctionne, et le Réponse ne faisant pas autorité est à se mettre sous le coude, nous comprendrons plus tard ce que cela veut dire.

Dans les systèmes GNU/Linux, la commande nslookup n’est plus maintenue. Les outils à retenir sont host et dig.

Quel que soit le service que nous utilisons sur un réseau, navigateur web, client de messagerie, IRC, dès lors que nous identifions le serveur interrogé par son nom, le système devra effectuer une résolution de ce nom, de manière à trouver l’adresse IP correspondante, et exploitera les services du serveur DNS, comme nous l’avons fait avec nslookup ou host.

Analyse d’un FQDN

Prenons un exemple un peu compliqué, comme www.education.gouv.fr ; en toute rigueur, il serait plus correct d’écrire www.education.gouv.fr. (avec un point final, subtile différence).

FQDN

  • la partie la plus à gauche représente toujours un hôte ;
  • la partie la plus à droite représente toujours un domaine générique (TLD) ;
  • entre les deux, les éventuels sous-domaines et le domaine déposé de l’entité concernée.

Ainsi, un serveur (un hôte), ici www appartiendrait à un sous-domaine (education) du domaine gouv, lui-même étant un élément du domaine générique fr (la réalité n’est hélas pas si simple, comme l’avenir va le montrer). Notons qu’il serait plus judicieux de parler d’un nœud ; en effet, un hôte peut disposer de plusieurs interfaces réseau et donc disposer de plusieurs adresses IP.

Nous avons donc une structure arborescente dont l’origine est le fameux point final, que l’on omet généralement, mais qui existe bel et bien et qui représente la racine de l’arbre. Nous pouvons d’ailleurs utiliser la commande host comme ceci :

Tiens, voilà autre chose…

www.education.gouv.fr ne serait pas un « vrai nom », mais simplement un synonyme de front.webedu.men.aw.atosorigin.com ? Encore une remarque à se mettre sous le coude. En effet, DNS prévoit qu’un hôte (un nœud) puisse s’appeler de diverses manières, parfois très différentes comme c’est le cas ici. L’éclaircissement viendra sans doute dans la suite de ce chapitre.

Pourquoi « serveur récursif » ?

Dans la suite de ce chapitre, nous allons voir d’un peu plus près comment un serveur DNS est structuré et comment l’architecture arborescente d’un FQDN est en fait l’image d’une arborescence de serveurs DNS spécialisés.

A priori, un serveur DNS récursif n’a par lui-même aucune réponse, du moins aucune réponse « qui fait autorité ». en revanche il sait exactement rechercher qui et dans quel ordre il faut interroger pour obtenir une réponse « qui fait autorité ». Comme en informatique, la paresse et la mémoire sont deux qualités fondamentales, notre serveur DNS récursif va conserver dans sa mémoire pendant « un certain temps » les résultats de recherche qu’il a obtenus et s’en servira en priorité, pour avoir moins de travail. Nous étudierons tout ceci plus loin, mais cette fonctionnalité explique déjà la réponse « ne faisant pas autorité » vue plus haut. En effet, lorsqu’un serveur DNS sert une réponse issue de son cache, il signale de cette manière qu’elle ne vient pas d’un serveur de référence.

 

Notions avancées

Considérations générales

Par la pratique, nous savons que la partie la plus à droite d’un FQDN est régie par des usages stricts. En effet, cette partie représente un « Top Level Domain », Domaine de premier niveau en français. Il en existe un certain nombre, ils sont définis par l’ICANN (Internet Corporation for Assigned Names and Numbers). Un article bien documenté sur Wikipédia vous donnera plus de détails.

A l’intérieur de chaque TLD, il est possible pour toute entreprise, association, personne morale ou physique, d’enregistrer un nom de domaine. Il suffit d’en faire la demande auprès d’un « registar », bureau d’enregistrement en français. Voir encore Wikipédia pour plus de détails. Le registar vérifiera l’unicité du domaine demandé, les éventuelles conditions d’obtention et se chargera des démarches pour l’enregistrement du domaine. Le cout de l’opération varie beaucoup en fonction du registar choisi.

Nous allons voir l’influence qu’a cette opération sur la structure du DNS.

La structure de DNS

DNS

Root-Servers

Nous avons au départ une série de serveurs DNS appelés root-servers. Nous en trouvons la liste et leur implantation dans le monde sur le site root-servers.org.

Ces serveurs ne sont pas récursifs, ne savent pas résoudre les FQDN, mais savent dire quels serveurs sont spécialisés dans les divers TLDs.

Serveurs TLD

Ces serveurs DNS ne sont pas non plus récursifs, mais pour un TLD donné, savent dire quels sont les serveurs DNS qui gèrent un domaine appartenant à ce TLD.

C’est à ce niveau que le registar intervient techniquement. Une fois le nom de domaine enregistré, le demandeur doit fournir l’adresse d’au moins un serveur DNS qui saura résoudre les noms dans le domaine en question et ce DNS doit être enregistré sur les serveurs du TLD choisi.

Manipulations

Mais une petite expérience vaut mieux qu’un long discours. Nous allons utiliser notre outil host pour chercher à résoudre le FQDN www.education.gouv.fr, non plus en posant la question à notre serveur DNS récursif, mais en partant de la source, à savoir un root-server : 192.58.128.30, en utilisant la commande comme ceci :

host -v www.education.gouv.fr 192.58.128.30

  • le -v indique que l’on veut des détails (verbose) ;
  • l’adresse IP en dernier argument indique quel serveur DNS nous voulons interroger.
J-root-servers.net ne répond pas directement, comme nous pouvions nous en douter. En revanche, il nous envoie la liste des serveurs DNS compétants dans le TLD fr. Reposons donc la question au premier de la liste : a.nic.fr :
Cette réponse nous apprend deux choses :

  • gouv.fr est un « domaine sectoriel», géré par l’afnic, et donc directement par les serveurs .NIC.FR et il en va de même pour des « domaines descriptifs définis dans le .fr ;
  • pour résoudre des noms dans le domaine education.gouv.fr, il faut poser la question à ns4.atos.net ou à ns3.atos.net.

Malheureusement, nous ne disposons pas cette fois-ci des « Additionnal information » et n’avons pas l’adresse IP de ces serveurs. Il nous reste à repartir du début avec une nouvelle requête:

A peine plus avancés, interrogeons alors a.gtld-servers.net :

Nous n’avons jamais été aussi proches de la solution finale. Une dernière question à ns4.atos.net dont nous connaissons désormais l’adresse IP :

Et voilà le travail. Nous pouvons constater à quel point il peut être fastidieux et nous nous félicitons de disposer d’un bon gros serveur DNS récursif, qui fait tout ce travail à notre place. Car c’est exactement de cette manière qu’il s’y prend pour nous obtenir la réponse.

Les renseignements qu’il glane en effectuant cette recherche, il va les garder en mémoire et s’en resservira pour d’éventuelles résolutions futures. Nous verrons que pour cette raison, les serveurs « qui font autorité » indiquent une durée de validité pour les informations qu’ils donnent. Ainsi, les serveurs récursifs devront rafraichir le contenu de leur cache en fonction de dette durée de validité.

 

Construire un serveur DNS

Pourquoi faire ?

  • pour comprendre mieux comment ça fonctionne ;
  • pour disposer d’une solution de secours si le(s) serveur(s) DNS de notre fournisseur d’accès montre(nt) des signes de faiblesse ;
  • pour se créer un petit intranet sympa, même avec un nom de domaine « en bois » qui ne sera fonctionnel que sur notre LAN.

Les raisons sont-elles suffisantes ? Oui, alors allons-y. Nous avons bien un vieux PC qui traine dans un coin et qui ne demande qu’à reprendre du service. Nous y installons une Debian (Lenny dans ce qui suit), sans aucune fioriture, le strict minimum, quoi. Avec bind9 et quelques outils de base, nous ne dépasserons pas les 800 Mo sur le disque et 256 Mo de RAM pourront faire l’affaire, si notre réseau local ne dépasse pas 100 postes…

Bon gros avertissement

Ce que nous allons faire ici est destiné à l’usage exclusif de notre LAN. Aucune considération de sécurité ne sera abordée. Si le principe reste le même pour la mise en place d’un serveur DNS public, il faudra prendre en compte tous les risques d’agression et ils sont nombreux.

Qu’avons-nous ajouté sur notre machine ? Le très célèbre serveur DNS de chez ISC, nommé bind, dans sa version 9 et la commande host.

Un simple cache

En l’état, notre bind est fonctionnel, c’est un serveur DNS récursif qui sait par lui-même répondre à toutes les demandes de résolution de FQDN de l’internet. La preuve ?

L’emploi de l’option -v rend la réponse un peu indigeste, mais assez instructive.

Nous apprenons que www.altavista.fr. n’est qu’un alias de rc.yahoo.com., lui-même alias de rc.fy.b.yahoo.com. et que son adresse IP est 206.190.60.37.

En prime, nous apprenons que le domaine fy.b.yahoo.com. est géré par les serveurs DNS yf1.yahoo.com. et yf2.yahoo.com., que www.altavista.fr. ne dispose pas d’adresse IP v6, la réponse à la question ;rc.fy.b.yahoo.com. IN AAAA aurait eu une réponse et enfin, que le SOA pour ce domaine est yf1.yahoo.com.. C’est quoi un SOA ? Rappelez-moi d’en parler plus loin dans ce chapitre si jamais j’oubliais.

Toutes ces informations, c’est notre bind à nous qui les a trouvées en se débrouillant tout seul, et en 961 millisecondes seulement ! Nous n’aurions pas fait mieux.

Bien sûr nous pouvons lui poser une question plus simple (sans l’option -v) pour un nœud qui n’a rien à voir :

C’est plus lisible, il y a moins d’informations. Remarquez qu’un seul nom dispose ici de plusieurs adresses IP. C’est du « round-robin » (tourniquet en français). A quoi ça sert ? Rappelez-moi d’en parler plus loin dans ce chapitre si jamais j’oubliais…

Bref, notre bind sait parfaitement effectuer pour nous toute résolution de FQDN, nous pouvons désormais nous passer des serveurs DNS récursifs de notre fournisseur d’accès, à l’exception des clients d’Orange™ qui devront prendre quelques précautions et là encore, nous verrons pourquoi plus tard.

Par quel prodige ?

Notre installation de bind9 a produit une configuration par défaut, minimaliste, qui permet au serveur de fonctionner en mode récursif. Sans entrer dans tous les détails, allons y voir de plus près.

Tout se trouve (sur Debian) dans le répertoire /etc/bind.

Nous n’en avons pas parlé jusqu’ici, mais il faut tout de même en dire quelques mots, de la résolution inverse, celle qui consiste à retrouver un nom d’hôte à partir de son adresse IP. Ce service est peu utilisé par le particulier (entendez par là l’internaute en général). Il l’est cependant parfois par des services sur l’internet, comme par exemple SMTP, pour tenter de lutter contre le spam. Pour cette raison, nous n’en dirons pas plus sur la question.

Voyons sans plus tarder le contenu de named.conf qui, de toute évidence, constitue le fichier de configuration principal :

Déjà, nous constatons que ce fichier fait lui-même appel à deux autres fichiers de configuration, named.conf.options et named.conf.local. Nous aurons à modifier au moins l’un d’entre eux. En revanche, named.conf ne devrait (sur Debian) jamais être modifié, sauf par les mises à jour futures de la distribution.

A part ceci, nous observons des déclarations de zones, presques toutes destinées à la résolution inverse, à l’exception de celle qui sont surlignées en vert.

La zone « localhost »

Pas bien utile en général, elle permet de résoudre localhost :

Le fichier db.local a une structure que nous aurons besoin de détailler plus tard. Nous y apprenons que localhost dispose des adresses 127.0.0.1 en IPv4 et ::1 en IPv6, ce que nous savions probablement déjà.

La zone « . »

Plus intéressant est le fichier db.root :

Il contient en effet toutes les informations sur les root-servers, sans quoi, notre bind n’aurait rien pu faire. Notez que le ; est un signe de commentaire.

Le contenu de ce fichier évolue peu dans le temps et les mises à jour de la distribution suffisent normalement à le maintenir dans un état satisfaisant. Notez que certains (mais peu encore) des root-servers disposent d’une adresse IPv6.

Créer une zone

Tout ceci est bien, mais nous voudrions maintenant créer une zone pour notre intranet, avec un nom de domaine « en bois » comme par exemple maison.mrs. Le TLD n’existe pas, le domaine maison.mrs ne peut donc exister sur l’internet, mais il peut parfaitement fonctionner sur notre LAN.

Pour ce faire, il nous faut tout de même entrer un peu plus dans le détail des informations que peut donner un serveur DNS.

$TTL

Indique en secondes la durée de vie de l’information fournie. Les serveurs DNS récursifs conserveront en cache les informations récoltées pendant la durée indiquée dans ce paramètre. 0 devrait indiquer que les valeurs ne doivent pas être conservées en cache (utile pour les « dyn DNS » mais c’est une autre histoire).

SOA

Start Of Authority. Si nous avons plusieurs serveurs DNS qui servent la même zone, nous avons vu l’exemple pour yahoo.com qui en a deux, mais il pourrait y en avoir plus, il y en a un qui est le serveur « maitre », les autres n’étant que des « escalves », c’est à dire de simples répliquas. L’administrateur met à jour le maitre, qui notifiera ses esclaves (l’informaticien a une tendance à la paresse). Le champ SOA indique donc quel est le serveur « maitre ».

Nous pouvons d’ailleurs, au moyen de la commande host savoir rapidement toutes ces choses :

Tiens, il y a bien plus de deux Name Servers pour le domaine Yahoo.com, finalement… Mais tous n’ont pas forcément besoin d’être référencés sur les serveurs du TLD com, deux suffisent.

Mais quel est dans cette liste le serveur « maitre » ?

C’est ns1.yahoo.com. et nous disposons également d’autres informations, que nous allons retrouver lors de la construction de notre zone « maison ». Nous avons l’assurance que ce serveur fournira toujours la bonne information (sauf erreur de l’administrateur).

Comme nous allons le voir, le symbole @ n’a pas ici la signification habituelle at. Aussi, l’adresse e-mail du responsable de la zone est marquée : hostmaster.yahoo-inc.com.. Si nous avons une remarque à faire au responsable de la zone, nous adresserons le message à hostmaster@yahoo-inc.com.

Serial

Numéro de série qu’il faut incrémenter à chaque modification de la zone. Il est d’usage de le construire à partir de la date de modification. Ainsi, dans l’exemple précédent, nous pouvons imaginer que le serveur a été mis à jour le 29 janvier 2009, peut être à 6h GMT, ou alors ce serait la sixième modification opérée ce jour. Cette façon de faire est une recommandation, mais pas une obligation. Un simple incrément suffit. Ce numéro de série permet aux serveurs « esclaves » de savoir s’il y a eu ou non une modification de la zone depuis leur dernière synchronisation.

Refresh

Indique en seconde le temps au bout duquel les serveurs « esclaves », aussi appelés secondaires, devront demander à rafraichir leur données pour cette zone. 3600 secondes dans l’exemple, soit une heure.

Retry

Indique en secondes au bout de combien de temps un serveur esclave doit ré-essayer de se synchroniser si la tentative a échoué après le temps refresh. Ici toutes les 300 secondes, soit toutes les 5 minutes.

Expire

Si toutes les tentatives de synchronisation échouent, indique le temps (en secondes) au bout duquel les serveurs secondaires devront considérer qu’ils ne savent plus répondre aux requêtes concernant cette zone. Ici 1814400 secondes, soit 21 jours ! Mieux vaut donner une réponse peut-être fausse que de ne pas en donner du tout ?

Negative Cache TTL

Paramètre dont la signification est assez floue. Pour bind9, indique le temps pendant lequel les caches (DNS récursifs) conserverait l’information NXDOMAIN, « le domaine n’existe pas », lorsqu’un incident s’est produit.

NS, A, AAAA, CNAME et les autres

Le champ NS (Name Server) indique le nom d’un serveur de noms. Pour une zone donnée, s’il y a plusieurs serveurs de noms, il y aura plusieurs champs NS.

Le champ A (Address) fait correspondre un nom à une adresse IPv4, alors que le champ AAAA fera correspondre un nom à une adresse IPv6.

Le champ CNAME (Common Name) fait correspondre un alias à un « vrai nom ». Le « vrai nom » doit disposer par ailleurs d’un champ A, dans la même zone ou dans une autre, sur le même serveur ou sur un autre (nous en avons vu un exemple avec www.education.gouv.fr).

Il existe encore d’autres champs comme MX (Mail eXchanger), utile pour le protocole SMTP ou TXT, (utile surtout, hélas, pour « tunnelliser » n’importe quoi dans du protocole DNS, mais c’est une autre affaire).

Le symbole « @ »

Dans un fichier de configuration de zone, ce symbole représente exactement le nom de domaine de la zone. Par exemple, lorsque nous allons créer notre zone maison.mrs, écrire :

Nous pourrons écrire :

La zone maison.mrs

Nous en savons assez pour créer notre zone « maison ». Notre serveur va s’appeler debvirt.maison.mrs et dispose de l’adresse IP 192.168.0.254 :

Créons d’abord dans /etc/bind/ un fichier nommé par exemple : db.maison.mrs qui contiendrait ceci :

Ceci devrait permettre de répondre aux requêtes de type NS pour le domaine maison.mrs, de répondre aussi aux requêtes de type A pour debvirt.maison.mrs et pour test1.maison.mrs, constater aussi que les alias fonctionnent dans et hors du domaine.

Il nous faut maintenant indiquer à bind que cette zone existe. Nous allons le faire dans le fichier /etc/bind/named.conf.local :

Enfin, nous redémarrons bind avec un /etc/init.d/bind9 restart et nous contrôlons

Tout va bien, notre serveur DNS fonctionne parfaitement.

Conclusion

Encore une fois, cette configuration ne tient compte d’aucune considération sécuritaire. Cependant, nous avons un service récursif pour les résolutions sur l’internet et qui pourra gérer les noms dans notre intranet.

Note pour Orange™

De longue date, ce petit problème existe. De nombreux clients utilisent les services de smtp.wanadoo.fr pour envoyer leurs e-mails. Faisons avec notre beau bind une résolution de smtp.wanadoo.fr :

Voyons maintenant depuis une connexion Orange™, qui utilise les serveurs DNS renseignés par la connexion PPPoE :

Ce ne sont pas les mêmes… Pourquoi ?

Il faut le demander aux administrateurs de wanadoo.fr. Toujours est-il que votre vaillant Firefox (ou équivalent), si vous êtes usagers de smtp.wanadoo.fr, ne parviendra pas à poster vos messages, la résolution faite par notre cache personnel ne donnant pas les bons serveurs. La solution est de créer sur notre bind une zone wanadoo.fr de type « forward » et d’y indiquer les adresses IP des serveurs DNS fournis par la connexion Orange™. La documentation de bind indique comment réaliser cette opération. Cette documentation complète se trouve sur le site d’ISC (124 pages en anglais, pour la version 9.4, fournie avec Lenny) dont la lecture est indispensable si l’on souhaite réaliser un serveur public ou simplement découvrir toutes les possibilités de l’outil.

psst ! le round-robin ?…

Comme nous l’avons vu, il arrive parfois qu’à un FQDN corresponde plusieurs adresses IP (parfois nombreuses, comme dans le cas de smtp.wanadoo.fr). Reprenons l’exemple plus simple de www.google.fr, en posant trois fois de suite la même question à notre serveur :

Nous observons une permutation circulaire dans l’ordre des réponses (tourniquet). Comme l’application demandeuse prendra la première réponse servie, si trois clients de notre serveur veulent accéder tour à tour à www.google.fr, ils utiliseront chacun une adresse IP différente et donc probablement aboutiront à un serveur différent. Ce système est très souvent utilisé pour répartir simplement la charge sur plusieurs hôtes.

 

Un peu d’espionnage

Pour les amateurs de sniff (de réseaux), voici ce que l’on peut capturer avec un wireshark lorsque notre serveur DNS récursif effectue lorsqu’il cherche à résoudre www.education.gouv.fr alors qu’il vient juste de démarrer et que son cache est vide. Je vous laisse la joie d’analyser ceci par vous-même. Vous y découvrirez la suite de questions posées aux divers serveurs non récursifs, pour obtenir la réponse finale :

 

Share

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *